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

Jiangli Zhou jiangli.zhou at oracle.com
Tue Dec 11 17:38:16 PST 2012


Hi John,

Thanks! Following are some more questions.

I see CompressedStream uses UNSIGNED5 coding of Pack200. I tried to 
google around for the UNSIGNED5 coding compression rate, but without 
much luck. If you have any info on that, please share. I was trying to 
find some usage examples in the VM code, but there seems no usage of 
CompressedStream (except the sa agent java code). Do you have any pointer?

Thanks,
Jiangli

On 12/11/2012 05:02 PM, John Rose wrote:
> 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/5096beea/attachment-0001.html 


More information about the hotspot-runtime-dev mailing list