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

Frederic Parain fparain at openjdk.org
Thu Mar 9 20:51:38 UTC 2023


On Wed, 8 Mar 2023 15:46:12 GMT, Coleen Phillimore <coleenp 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.
>
> src/hotspot/share/classfile/classFileParser.cpp line 1491:
> 
>> 1489:   _temp_field_info = new GrowableArray<FieldInfo>(total_fields);
>> 1490: 
>> 1491:   ResourceMark rm(THREAD);
> 
> Is the ResourceMark ok here or should it go before allocating _temp_field_info ?

_temp_field_info must survive after ClassFileParser::parse_fields() has returned, so definitively after the allocation of _temp_field_info. That being said, I don't see any reason to have a ResourceMark here, probably a remain of some debugging/tracing code. I'll remove it.

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

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


More information about the serviceability-dev mailing list