Hi all,

I am new to the list, so I couldn’t answer directly to Minifying Woes (or at least didn’t know how to).

I identified 75 VM intern objects in Tom’s (tobe) image, by loading it in the simulator and setting a halt after loading the image.

With the following code:

| collection |

collection := OrderedCollection new.

self allOldSpaceEntitiesDo: [:obj | (((self classIndexOf: obj) < self lastClassIndexPun) and: (self isImmediate: obj) not) ifTrue: [ collection add: obj] ].

(collection sorted: [:a :b | (self bytesInBody: a) > (self bytesInBody: b)]) collect: [:ea | ea hex -> (self bytesInBody: ea)]

I get the following 75 objects:

1. A free chunk after all other objects. Can be ignored for the sake of minimising image size
2. Remembered set -> 1048592 byte
3. hiddenRootsObj -> 32848 byte
4 - 61. Pages of the mark and weakling stack -> respectively 32752 byte
62 - 74. arrays of the class table -> respectively 8208 byte
75. specialObjectsOop -> 520 byte

As far as I can judge the stack pages and remembered set could be removed from the image to minimize it further.

If I understand correctly the StackPages could be removed by using the SpurImagePreener. The remembered set

Could be removed in the SpurImagePreener too (when the VM initialises the memory it initialises a new remembered set too, if it is nil).

After a quick read of the SpurImagePreener I didn’t see that the remembered set gets removed.

When I tried using the preener it resulted in an unusable image (both simulator and compiled VM couldn’t load it).

I tried both:

SpurImagePreener new

preenImage: '/Users/tombraun/Desktop/Squeak6.0-22104-64bit copy.image'

SpurImagePreener new

writeDefaultHeader: true;

savedWindowSize: 1@1;

preenImage: '/Users/tombraun/Desktop/Squeak6.0-22104-64bit copy.image'

Could be a me problem, as I did some changes to the memory management in my VMMaker image, although this shouldn’t influence

the preener….

On this note @Eliot: why the decision to make the object stacks and the remembered set VM managed objects instead of allocating them

separately?

1. We don’t need to keep them in a snapshot. All object stacks are empty after GC and as we flushed the new space pre snapshot

The remembered set shouldn't need to be persisted too.

2. During GC we simply mark all stack pages and keep them alive. When we at least

freed empty pages (after a limit, to prevent the running VM from having to allocate too many pages every GC?) I would see the value.

What did I overlook or does it simply have historical reasons?

Best,

Tom (WoC)