RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v4]

Chris Plummer cjplummer at openjdk.org
Tue Mar 14 02:03:32 UTC 2023


On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this change re-implementing the FieldInfo data structure.
>> 
>> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency.
>> 
>> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information).
>> 
>> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818
>> 
>> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM.
>> 
>> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format.
>> 
>> Tested with mach5, tier 1 to 7.
>> 
>> Thank you.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes includes and style

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 108:

> 106:     CLASS_STATE_INITIALIZATION_ERROR = db.lookupIntConstant("InstanceKlass::initialization_error").intValue();
> 107:     // We need a new fieldsCache each time we attach.
> 108:     fieldsCache = new HashMap<Address, Field[]>();

This should probably be a WeakHashMap. I tried it and it seems to work (or at least didn't cause any problems). However, when doing a heap dump I didn't notice the table being any smaller on exit when it was made weak, even though there were numerous GC's while dumping the heap.

The <key> is the Address of the hotspot InstanceKlass instance, and this Address is referenced by the SA InstanceKlass mirror. So theoretically when the reference to the mirror goes way, then the cache entry can be cleared.

-------------

PR: https://git.openjdk.org/jdk/pull/12855


More information about the serviceability-dev mailing list