Design question: why not reuse the CMS slots in mark word?

[Aleksey Shipilev]

Most of the tools I saw (and supported one of them [1]) walk the heap
from Java by polling the actual field offsets. You have to detect/adjust
for the different header size anyway, if you expect your tool to work
with 32-bit, 64-bit, 64-bit with COOPs, 64-bit with COOPs but not
compressed classes, etc.

In fact, many of those tools would applaud having the forwarding pointer
as the part of the instance, because that would accurately estimate the
heap occupation. As of now, forwarding pointers are invisible for
instance inspection. In pathological cases, like in
-XX:ObjectAlignmentInBytes=16, a simple Object would take *twice* more
storage than Instrumentation API or (Unsafe) instance inspection would
tell. Good luck wrapping your head around post-mortem heap dumps after
OOMEs!

Therefore, I see no logistical problem in cramming another word in the
instance header.

Thanks,
-Aleksey

[1] http://openjdk.java.net/projects/code-tools/jol/

On 09/20/2016 02:15 PM, Roman Kennke wrote:
> There's a well defined way to access the heap and objects, it's called
> JVMTI and JNI. They give you access to anything that such tools would
> ever need, I think. Those are under our control.
> 
> Do you really think there are tools out there that do something more
> esotheric like directly accessing memory to inspect objects (I want to
> know them..)? It sounds to me like they already subscribed to a world
> of unnecessary pain. Why should I care to make their world less
> painful? :-D ;-) :-P
> 
> Roman
> 
> Am Dienstag, den 20.09.2016, 07:43 -0400 schrieb Christine Flood:
>> I wouldn't.
>>
>> There are a bazillion third party heap walking tools that assume they
>> know the object layout.  
>> Even if you got it working inside of Hotspot, the villagers would
>> come for you with pitchforks and flaming torches.
>>
>>
>>
>> Christine
>>
>>
>> ----- Original Message -----
>>>
>>> From: "Roman Kennke" <rkennke at redhat.com>
>>> To: "Christine Flood" <chf at redhat.com>, "Aleksey Shipilev" <shade at r
>>> edhat.com>
>>> Cc: shenandoah-dev at openjdk.java.net
>>> Sent: Tuesday, September 20, 2016 7:37:27 AM
>>> Subject: Re: Design question: why not reuse the CMS slots in mark
>>> word?
>>>
>>> Am Dienstag, den 20.09.2016, 07:28 -0400 schrieb Christine Flood:
>>>>
>>>> Here's some recent work on the cost of barriers in GC.
>>>>
>>>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.231.3040
>>>> &rep
>>>> =rep1&type=pdf
>>>>
>>>> You can see that a conditional read barrier is three times as
>>>> expensive as a non-conditional read barrier.  Roman didn't
>>>> believe me
>>>> and insisted on testing it for himself and found the same result
>>>> empirically ;-)
>>>
>>> Yep :-)
>>>
>>> Notice that this also precludes any form of side-table based
>>> lookup.
>>>
>>> All that said, I would love to see the brooks ptr 'inlined' in the
>>> regular object layout. It may not actually be *that* complex
>>> assuming
>>> all code nicely respects the various base-offsets of object layout
>>> (and
>>> they must, right?) My idea would be to insert the brooks ptr right
>>> before the object/array fields start (i.e. after the klass*). This
>>> puts
>>> it 2 words nearer to them and thus make it more likely to warm um
>>> cache
>>> for following field accesses. Plus, we'd loose less space with
>>> compressed oops because we could squeeze a compressed brooks ptr
>>> into
>>> the unused 32bits of compressed klass* for regular objects (non-
>>> arrays), and otherwise benefit from alignment.
>>>
>>> I think I'll spend a day or two exploring that idea a little more.
>>>
>>> Roman
>>>
>>>>
>>>>
>>>>
>>>> Christine
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>>
>>>>> From: "Aleksey Shipilev" <shade at redhat.com>
>>>>> To: "Christine Flood" <chf at redhat.com>
>>>>> Cc: shenandoah-dev at openjdk.java.net
>>>>> Sent: Tuesday, September 20, 2016 4:53:36 AM
>>>>> Subject: Re: Design question: why not reuse the CMS slots in
>>>>> mark
>>>>> word?
>>>>>
>>>>> On 09/19/2016 11:00 PM, Christine Flood wrote:
>>>>>>
>>>>>>
>>>>>> The theory was to make the read barrier as efficient as
>>>>>> possible.
>>>>>> It's always just a single read of a fixed offset.  If we
>>>>>> tried to
>>>>>> reuse the mark word we'd have to deal with locked objects and
>>>>>> hash
>>>>>> codes and all that nonsense potentially making read barriers
>>>>>> much
>>>>>> more expensive.
>>>>>>
>>>>>> If you have a protocol that uses the mark word and doesn't
>>>>>> introduce
>>>>>> extra overhead in the common case (a conditional in a read
>>>>>> barrier
>>>>>> would be deadly) I'd love to hear it.
>>>>>
>>>>> Okay, that makes sense, thanks.
>>>>>
>>>>> Is this a hunch about the read barriers cost, or we actually
>>>>> tried
>>>>> more
>>>>> complicated read barriers? Trying to understand if potentially
>>>>> worth
>>>>> investigating, or this road was taken already.
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>
>>>>>
>>>