RFR: JDK-8212186: JVMTI lacks a few GC barriers/hooks

[Per Liden]

On 10/17/2018 07:10 PM, Roman Kennke wrote:
> 
>> Hi Roman,
>>
>> Looks fantastic.
> 
> Thanks!
> 
>> BTW, out of curiosity, how do you do the heap walk - scanning or tracing?
> 
> Tracing. Scanning would require to carry around complete marking info
> (to be able to avoid holes of dead objects with recycled Klass*), which
> we don't.

So that makes me wonder why you needed JDK-8211955 (GC abstraction for 
LAB reserve) and why you insert filler objects at all? Am I missing 
something?

cheers,
Per

> 
> Roman
> 
>> Thanks,
>> /Erik
>>
>>> On 17 Oct 2018, at 11:48, Roman Kennke <rkennke at redhat.com> wrote:
>>>
>>> Erik recently pointed out that  JvmtiTagHashmapEntry::equals() is
>>> lacking on obj-equals-barrier, and that JvmtiTagHashmap::hash() better
>>> does ::resolve() the object to a stable value before casting it to a raw
>>> address.
>>>
>>> This lead us to do some more JVMTI testing and we found that we have a
>>> little inconsistency with reporting object size too: the VMObjectAlloc
>>> callback now reports a different size that GetObjectSize(). This is also
>>> fixed by this proposed change:
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8212186
>>> Webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8212186/webrev.00/
>>>
>>> Testing: hotspot/tier1, nsk/jvmti with Shenandoah
>>>
>>> Ok?
>>>
>>> Roman
>>>
>