Master Thesis on Shenandoah

[Roman Kennke]

Am 08.11.2017 um 19:07 schrieb Dominik Inführ:
> On Wed, Nov 8, 2017 at 4:33 PM, Roman Kennke <rkennke at redhat.com 
> <mailto:rkennke at redhat.com>> wrote:
>
>     Am 08.11.2017 um 16:14 schrieb Christine Flood:
>
>         Roman wrote:
>
>             "Yes. Then we might be lucky and squeeze it in a leftover
>         word from
>         alignment or squeeze it into the gap left by the compressed
>         Klass* (for
>         non-arrays) or such."
>
>         At the cost of a significantly more expensive read barrier. 
>         My guess is
>         that it would add a minimum of a shift and an add.
>
>     No. Well, kinda. We would compress the fwd ptr just like any other
>     oop, at the same cost.
>     The Klass* leaves 32bit gap, but only for instances, not for
>     arrays. This means we'd have to conditionally generate different
>     barriers depending on our knowledge of the object: 1. for
>     instances, read fwdptr from klass gap 2. for arrays, read fwdptr
>     from elsewhere 3. for unknown generate conditional read-barrier to
>     figure it out at runtime (I expect this to be rare). 
>
>
> What's the reason that the fwdptr can't be on the same offset for 
> non-arrays and arrays? At least the shift+add could be done in one 
> instruction on x64 (with lea - but only for object alignment 8) and 
> aarch64 (add with lsl).
I was pondering the idea to squeeze the fwd ptr into the so-called 
Klass-gap. This is 32 unused bits when the Klass* is compressed. It's 
only available for non-arrays, because for arrays, the array-length is 
squeezed into those 32bits.
>
>     All in all, I doubt it's worth the troubles.
>
>
> I suppose you mean the whole project?
Eh, no. I mean special-casing code generation for reading the fwd ptr 
from different offsets for instances vs arrays. :-)


Roman