Request for review: 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing

[John Rose]

On Dec 10, 2012, at 3:30 PM, Jiangli Zhou wrote:

> Hi John,
> 
> Thanks a lot for looking at the change again and the field compressing suggestion! I've looked into the FieldInfo array and optimized the memory usage for the generic signature index slot earlier this year. I haven't played with any compression technique. Thanks for the suggestion, definitely worth to look into. I have one question maybe you have quick answer to it. Does C1 or C2 heavily relying on fast accessing to the FieldInfo array?

A couple of other bits...

I sketched more of a compact design during Alexsey's review:

On Dec 11, 2012, at 3:21 PM, John Rose wrote:

> On Dec 11, 2012, at 5:06 AM, Aleksey Shipilev wrote:
> 
>>> ...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".
>> 
>> 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.
>> 
>> This is probably a little dodgy when compared against sparse
>> representation, but I feel uncomfortable rebuilding entire field
>> attribute mechanics in the course of @Contended work.
> 
> 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.


In general, I think we should make more systematic use of CompressedStream for storing metadata that is not directly accessed by the interpreter or compiled code.

Also, I did a quick and dirty "printf" based test for average field-info array size.  It suggests that about 30% of the classes have one or more fields, and that of those classes, the average array length is 36 (u2) elements.  This is pretty small potatoes, but it's of similar magnitude to the other bit-packing changes to InstanceKlass, so maybe it's worth while.  I definitely think using CompressedStream in more places is worthwhile, if we want to pack our metadata down tighter, and at the same time move toward 32-bit clean representations.

Thanks,
— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121211/e3203517/attachment.html