Exploring Time-Space trade-offs for "synchronized" in Lilliput

[Gil Tene]

> On Nov 8, 2021, at 2:54 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Nov 8, 2021, at 2:44 PM, Roman Kennke <rkennke at redhat.com <mailto:rkennke at redhat.com>> wrote:
>> 
>> Indeed! This is a good suggestion! But doesn't this make size-based heap-parsing a bit more complicated? Given an object O in heap, how to find the next object after O?
> 
> A bit more, and a bit less as Gil said (since you don’t compute the object size).
> I tend to think putting the extension before is better than after, but there are
> pros and cons.
> 
> (a) the extension field is probably on an off-aligned word just before the header,
> so if you check alignment bits you won’t be fooled.

Once Liliput is done, we'll probably be tempted to reduce alignment ot one word. [can still do miniumum object size of 2 words, but with no alignment requirement]. If that happens, alignment won't be a hint any more...

> Also (b) you might consider
> using a tag bit or two, as with header tag bits today, to make the extension word
> look different from a bonafide header.

Yup. That;'s what we do in Zing/Prime.