Smalltalk › Squeak › Squeak VM

[OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

David T Lewis

[OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

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]

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Tobias Pape

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

> On 20.02.2020, at 17:50, Fabio Niephaus <[hidden email]> 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

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by David T Lewis

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by David T Lewis

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by David T Lewis

And why not in the ini file?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

timrowledge

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by David T Lewis

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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DNC: Do Not Collect $200

timrowledge

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by David T Lewis

> On 2020-02-20, at 9:42 AM, Jakob Reschke <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RDRI: Rotate Disk Right Immediate

David T. Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by timrowledge

On Thu, Feb 20, 2020 at 09:51:04AM -0800, tim Rowledge wrote:

>
> 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 <[hidden email]> 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.
>

All of these schemes are inherently unmaintainable over time and across
any non-trivial mix of VMs and images.

The solution is simple: Don't do that.

We have a perfectly good mechanism for supporting optional interactions
with the VM. Named primitives are designed to do this. They work very
well, with no need for (human) management oversight. A primitive either
works or it doesn't, and if it doesn't work then fine, the VM does not
support whatever you were trying to tell it to do. Simple, easy, bulletproof,
and no management oversight required.

Dave

Tobias Pape

Re: [OpenSmalltalk/opensmalltalk-vm] Store key Spur GC parameters in image header (#477)

In reply to this post by David T Lewis

> On 20.02.2020, at 18:12, Eliot Miranda <[hidden email]> 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