compressed oops and 64-bit header words

[Y Srinivas Ramakrishna]

Answering my own question, given my relative ignorance of the
current scheme ...

> 
> > The mark word can also contain a forwarding pointer used during GC, 
> so 
> > 
> > can't be 32 bits.
> 
> What about the lock record / stack pointer when the object is locked?

I suppose one could (a) either allocate the lock records in the heap and
compress them in the same manner, or (b) allocate them in a special
lock record area and compress the pointers as an offset, and
(c) for the stacks, somehow ensure sufficient alignment of all thread
stacks and thus be able to compress stack pointers as well.

> Would that also be a factor precluding compression to 32 bits even if 
> GC were to 
> compress and decompress forwarding pointers at some cost (in time
> and representable heap size, because of the need for the forwarding bit
> even in the compressed case).

I guess that it would boil down to the measured tradeoff between the memory
traffic savings from the compression versus the dynamic cost of decompression.

-- ramki