P4
Hotspot classloaders have an intricate code working with field attributes, which is error-prone, and employing all sorts of tricks to fit to reduce the memory footprint, and also arguably ineffective. Pending changes for JDK-8003985 (@Contended) and @Stable annotation support further exacerbate the issue.
The exchange between John Rose and Aleksey Shipilev:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-December/007546.html
John: "It's good that you are packing the data into the field info array without adding new elements. In the near future we are likely to add more sparse attributes to fields, which will require packing even more information into that limited space. With that in mind, I would prefer to see us using a sparse representation sooner rather than later, but that change can wait. (In particular, the 'initval_index' is almost always zero, and should go away.) The bottom line, for now, is that your solution for cramming in contended bits will probably need to be reworked with the next sparse field annotation (probably @Stable). The rework could use something like your tagging scheme (which is clever) but have the exceptional tag value mean "I have extended attributes specified in N additional words of data".
Aleksey: "I think we have a little bit of mis-design about FieldInfo here. What allows me to piggyback on FieldInfo is that we clearly have the classload-scope (CS) metadata info for fields, and runtime-scope (RS)
metadata info. That allows us to mangle CS data during the classload, knowing for sure we substitute that with RS after classload finishes."
John: "It's totally dodgy. It makes some sense if you are aiming at an in-memory copy of the classfile AST, but is not friendly to the JVM which is actually using the data. If I were rewriting it, I would try to use a temporary FieldInfo structure with a simple but non-dense layout, and a packing phase which would put the necessary field metadata into a dense streamable form, in an array<u1>, using CompressedStream. The FieldStream would unpack each successive field descriptor into the FieldInfo structure. By using CompressedStream, the data structure would be 32-bit clean, leading to various other advantages."
The exchange between John Rose and Aleksey Shipilev:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-December/007546.html
John: "It's good that you are packing the data into the field info array without adding new elements. In the near future we are likely to add more sparse attributes to fields, which will require packing even more information into that limited space. With that in mind, I would prefer to see us using a sparse representation sooner rather than later, but that change can wait. (In particular, the 'initval_index' is almost always zero, and should go away.) The bottom line, for now, is that your solution for cramming in contended bits will probably need to be reworked with the next sparse field annotation (probably @Stable). The rework could use something like your tagging scheme (which is clever) but have the exceptional tag value mean "I have extended attributes specified in N additional words of data".
Aleksey: "I think we have a little bit of mis-design about FieldInfo here. What allows me to piggyback on FieldInfo is that we clearly have the classload-scope (CS) metadata info for fields, and runtime-scope (RS)
metadata info. That allows us to mangle CS data during the classload, knowing for sure we substitute that with RS after classload finishes."
John: "It's totally dodgy. It makes some sense if you are aiming at an in-memory copy of the classfile AST, but is not friendly to the JVM which is actually using the data. If I were rewriting it, I would try to use a temporary FieldInfo structure with a simple but non-dense layout, and a packing phase which would put the necessary field metadata into a dense streamable form, in an array<u1>, using CompressedStream. The FieldStream would unpack each successive field descriptor into the FieldInfo structure. By using CompressedStream, the data structure would be 32-bit clean, leading to various other advantages."