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

[Gil Tene]

> On Nov 8, 2021, at 2:44 PM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> 
> Hi Gil,
> 
>> Roman, FWIW, in Zing (now called Prime) we use a similar optional hash-code word, but we place the hashcode in a pre-header word, rather than with an appended word. It fits in basically the same place (in a gap between objects, and can occupy an alignment gap if one exists), but is easier/faster to address. Putting it before the header eliminates the need to know the object size to get to the hashcode.
> 
> 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?

Yup, but there are multiple ways to deal with the "I moved here from the previous object+size. How do I know if I'm at the header or pre-header?].

- one is to use the encoding the values in header and preheader words such that they will always distinguishable [such that if you "nove forward to" the preheader word, you'd be able to tell it is not a header word and move forward by 1 [1 is good if you only do one preheader word, or incrementally until you get to one if you do variable preheader word lengths, but that's a whole other subject…]. E.g. you can sacrifice a bit to disntinguish them, but there are cheaper things too [sacrifice some partial value range, but not 1/2 of the whole range].

- Another other is to look in the live bits (in collectors that have those), as the live bit will be set for the header word.

- And there are probably many others.

> 
> Cheers,
> Roman
>