[squeak-dev] [Vm-dev] Re: [Pharo-dev] Nuking VM ImageSegment support (was Re: Daily Commit Log; System-bf.916)

Bert Freudenberg bert at freudenbergs.de
Tue Jul 4 12:01:52 UTC 2017

On Mon, Jul 3, 2017 at 11:43 PM, Eliot Miranda <eliot.miranda at gmail.com>

> Hi Bert, Hi Tim,
> On Thu, Sep 15, 2016 at 2:55 PM, <commits at source.squeak.org> wrote:
>> [snip]
>>> http://lists.squeakfoundation.org/pipermail/packages/2016-Se
>>> ptember/068930.html
>>> Name: System-bf.916
>>> Ancestors: System-bf.915
>>> Replace VM-level ImageSegment loading with a Smalltalk implementation
>>> for old (interpreter-era) projects.
>>> Also removes support for writing segments.
>>> This overrides the Spur support introduced in System-eem.758.
> I am currently putting back the ImageSegment support for saving projects
> and loading native segments produced in this way.

​Why?​ I thought we agreed that ImageSegments are not a great idea as a
file format, for their lack of compatibility. Serialization speed isn't an
issue anymore thanks to your fast jit.

What ImageSegments *are* good at is for splitting up an image into segments
that do not have to be in memory at the same time - but in that case they
would not be an independent entity but be considered part of one particular
image. And for that we need only very few methods (that I removed too,
see storeSegment).

  I''ve added subclasses of ImageSegment called NativeImageSegment and
> LegacyImageSegment.   I have a few questions.
> 1. I'm curious about the ImageSegment>>scanFrom: method:
> !ImageSegment methodsFor: 'fileIn/Out' stamp: 'RAA 6/22/2000 17:49'!
> scanFrom: aStream
>     "Move source code from a fileIn to the changes file for classes in an
> ImageSegment.  Do not compile the methods.  They already came in via the
> image segment.  After the ImageSegment in the file, !!ImageSegment new!!
> captures control, and scanFrom: is called."
>     | val chunk |
>     [aStream atEnd] whileFalse:
>         [aStream skipSeparators.
>         val := (aStream peekFor: $!!)
>             ifTrue: ["Move (aStream nextChunk), find the method or class
>                         comment, and install the file location bytes"
>                     (Compiler evaluate: aStream nextChunk logged: false)
>                         scanFromNoCompile: aStream forSegment: self]
>             ifFalse: [chunk := aStream nextChunk.
>                     aStream checkForPreamble: chunk.
>                     Compiler evaluate: chunk logged: true].
>         aStream skipStyleChunk].
>     "regular fileIn will close the file"
>     ^ val! !
> I don't see this in the new (legacy, System-bf.916) image segment loading
> code.  Do Etoys projects not include source code and hence its irrelevant?

​They do, but the code path to load them does not go through this method.

The question boils down to whether this should be a method on ImageSegment,
> and hence inherited by both NativeImageSegment and LegacyImageSegment, or
> just NativeImageSegment.  Also, I don't see how this method attaches
> sources to the methods brought in.  Is it in fact useless and hence that's
> why you've left it out?  If so, would it not be useful to add code that
> does update the source pointers in loaded methods correctly?

The ImageSegment nowadays only stores uniclasses as objects. Other changes
to the system are simply filed in, and not included in the segment. This
method appears to be unused. I tried to trim everything not strictly
need​ed for project loading

2. Should I pull in the Etoys extensions deleted in EToys-bf.234?
>  (ImageSegment>>(classOrganizersBeRoots:,rehashDictionaries:,rehashMethodDictionaries:)?
> I'm guessing they'll be needed for native loading.

​: is still there, not sure if we need the others.​

> 3. Same for the SMBase extension ImageSegment>>writeForExportOn:.  I
> guess this should come back in too.

​SqueakMap uses ImageSegments, yes. No idea if it's a good idea to write a
new native segment.​

4.  Where should I look for tests that may have been removed?

​There are no tests, unfortunately ...

The way I was testing is taking a project written by Etoys (from
squeakland.org) and dropping it into a trunk image. Before your changes
this did work, more or less: If you revert to System-pre.956 and
make allocateMethodContext: and allocateBlockContext: simply return nil,
you can load old projects again. These contexts aren't needed anyways for
Etoys projects (if we needed them I'd recreate by recompiling).

I'm attaching a simple project that I just tested with this.

- Bert -​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170704/55332472/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cars.001.pr
Type: application/x-squeak-project
Size: 70546 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170704/55332472/attachment-0001.bin>

More information about the Squeak-dev mailing list