Store key Spur GC parameters in image header

[eliotmiranda]

It would be convenient if the Spur headroom growth size, shrinking ratio, and heap growth ratio for full GCs/old space were stored in the image header as “desired” values, alongside new space, code zone, and stack zone sizes.

[this request from Cyril Ferlicot]

[fniephaus]

Just wondering: why waste precious space in the image header if we could have some sort of VM configuration object in the specialObjectsArray?

[OpenSmalltalk-Bot]

On 20.02.2020, at 17:50, Fabio Niephaus ***@***.***> wrote: Just wondering: why waste precious space in the image header if we could have some sort of VM configuration object in the specialObjectsArray?

Also, stuff like the Class table or other Specialities may be better if stored/accessible explicitly rather than incidental.

…

-t

[eliotmiranda]

Hi Fabio,

two issues here.  One is that I don’t think space is precious anymore.  I *think* the vm stores the image header size in the first or second 32-bit word, and to the header is effectively stretchy.  I will check. The other issue is that anything in the specialObjectsArray is available only after the image is loaded, which implies adding a post-load configuration stage.  Currently all the size config is done before the image loads.

[eliotmiranda]

Hi Tobias,

I very much want to keep the class table, free lists, finalization queue, mark stack etc hidden.  These are very much implementation dependent, and revealing them to the image as objects creates the potential god coupling to the implementation.  Just as the vm hides the existence of JIT code, stack frames, and other implementation details, hidden from the Smalltalk programmer, so should it hide that it uses a lass table, etc.  this gives freedom for us to improve the implementation by using a better representation of someone comes up with one.

We can still observe these structures through vmParameterAt:, clumsy though if may be, because we can carefully control access. Even so, these parameters are inconvenient to work with. Just look at the number of changes/reinterpretations/new parameters between v3 and Spur.

So my vote/design principle is to keep these implementation details encapsulated as much as possible in the vm.

[j4yk]

And why not in the ini file?

[OpenSmalltalk-Bot]

Just to be completist (and possibly completely ridiculous) I'll mention an alternative option; - store the desired values in the image - make it possible to change the assorted zone sizes at runtime I totally understand that the work to do that may be absurd verging into DaDa. The (faintly) plausible advantage would be runtime tuning as a system grows, allowing adaptive strategies etc, etc, {insert buzzword here}

On 2020-02-20, at 8:14 AM, Eliot Miranda ***@***.***> wrote: It would be convenient if the Spur headroom growth size, shrinking ratio, and heap growth ratio for full GCs/old space were stored in the image header as “desired” values, alongside new space, code zone, and stack zone sizes.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DNC: Do Not Collect $200

[OpenSmalltalk-Bot]

On 2020-02-20, at 9:42 AM, Jakob Reschke ***@***.***> wrote: And why not in the ini file?

As far as I remember only the Window VM uses any such file. Obviously the could be changed if we really want but an important consideration is that the memory size and some other parameters are very much tied to a particular image rather than generally valid. For example, setting the eden/newspace sizes to suit a large commercial data-wrangling image wouldn't be very helpful to a Scratch image... tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RDRI: Rotate Disk Right Immediate

[OpenSmalltalk-Bot]

On 20.02.2020, at 18:12, Eliot Miranda ***@***.***> wrote: Hi Tobias, I very much want to keep the class table, free lists, finalization queue, mark stack etc hidden.

Yeah, but without that it's not easy to get the Class for SmallFloat64 on RSqueak, for example. One has to dig around the undocumented class table to find it. Even more so, the object headers point into the class table, so what is the contract image/vm in the first place?

These are very much implementation dependent, and revealing them to the image as objects creates the potential god coupling to the implementation. Just as the vm hides the existence of JIT code, stack frames, and other implementation details, hidden from the Smalltalk programmer, so should it hide that it uses a lass table, etc. this gives freedom for us to improve the implementation by using a better representation of someone comes up with one. We can still observe these structures through vmParameterAt:, clumsy though if may be, because we can carefully control access. Even so, these parameters are inconvenient to work with. Just look at the number of changes/reinterpretations/new parameters between v3 and Spur. So my vote/design principle is to keep these implementation details encapsulated as much as possible in the vm.

True dat. However, we have to make sure to be able to execute an image without any hidden knowledge, even on non-osvm :)

…

-t