> Do you have a description of the format of the image ?
It is just three parts. A header (save.c describes it), the OOP table
(whose base address is stored in the header), and the object data
(pointers are relative to the same OOP table base address stored in
the header). A few objects have fixed OOP table indices and from
there all the globals and symbols are recovered (see dict.c,
init_runtime_objects_on_image_load).
The OOP table data is copied from the image file into the new table
(gst uses the same address as when the snapshot was saved if it is
available). Instead, the object data is mmaped MAP_PRIVATE (i.e. with
copy-on-write), so that the object pointers in the OOP table are left
pointing directly into mmaped object data (*). There is a slow path
that allocates memory for the objects and copies the contents, and it
is used if the OOP table base address changes compared to when the
snapshot was made.
(*) until an OOP table entry is freed or #become:'d
The saving is entirely in save.c. The loading is partly in save.c,
partly in dict.c (the aforementioned routine), partly in sym.c (called
by init_runtime_objects_on_image_load). Most of the complication in
save.c is to support mixed-endian loading. This is complicated
because in gst byte objects can have fixed (pointer) instance
variables. So you first have to load the data, switch endianness for
non-byte objects (including classes), and do another pass to switch
endianness again for byte objects. All this code however is usually
not run.
Paolo
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Locked
