Reducing class pointer size useful?

Thomas Stüfe thomas.stuefe at gmail.com
Tue Sep 14 05:31:16 UTC 2021


Hi John,

thanks a lot for the concise recap. I think I understand now after yours
and Romans mail where we stand.

I hope that my proposal - if it works, and if I have not missed something -
would be a good first step toward shrinking the class pointer. Its
advantage is that it would not require deep changes. Neither splitting the
Klass nor dissecting classes into near and far ones would be required. It
may not be the best proposal memory-wise, but it would allow us to
experiment with smaller class pointers and refine the encoding process
later.

Thanks, Thomas


On Sat, Sep 11, 2021 at 3:31 AM John Rose <john.r.rose at oracle.com> wrote:

> On Sep 10, 2021, at 4:11 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
>
> Would it be of use for Lilliput to shrink the class pointer size beyond 32
> bit? I did not closely follow the discussions. Therefore I am not sure
> where the current thinking goes.
>
>
> Such things are on the table I think.
>
> There are two parameters here:  Number of
> bits |ki| in the klass-ID, and size in bytes |ks|
> (usually power of 2) of a klass struct.
>
> Both |ki| and |ks| can be freely varied, I think,
> as a design and optimization parameter.
>
> 1. *Not all* klasses need to be addressed using the
> klass-ID of size |ki|; put another way, the first
> 2^|ki| glasses are privileged to have a compact
> object header representation while other may
> require more bits (an extension field in the
> object layout).
>
> 2. *Not all* of the bytes of a klass need to be
> represented in the |ks| bytes.  You can add
> a level of indirection, and it won’t hurt much
> as long as all the stuff JVM need fastest access
> to is in the first |ks| bytes.
>
> The second insight leads also to the concept
> of “near klass” vs “far klass”, and opens the
> conversation about having *several* near klasses
> for one far klass.  In some designs, that allows
> you to subdivide refine a system of classes
> into a system of classes and “species”, where
> several species can share on class.
>
>
>


More information about the lilliput-dev mailing list