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

Roman Kennke rkennke at redhat.com
Wed Oct 17 17:10:57 UTC 2018


> 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.

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
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20181017/96cf8de9/signature.asc>


More information about the hotspot-gc-dev mailing list