Master Thesis on Shenandoah

[Dominik Inführ]

On Wed, Nov 8, 2017 at 7:13 PM, Roman Kennke <rkennke at redhat.com> wrote:

> 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> 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.
>

Ah okay...

>
>
>> 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. :-)
>

Oh... :D

So I guess the next step is to start with the implementation...


>
>
> Roman
>