Request for review 8007320: NPG: move method annotations

Coleen Phillimore coleen.phillimore at
Mon Feb 4 16:48:41 PST 2013

On 2/1/2013 3:11 PM, Jiangli Zhou wrote:
> Hi John,
> On 02/01/2013 11:36 AM, John Rose wrote:
>> On Jan 31, 2013, at 4:02 PM, Jiangli Zhou <jiangli.zhou at 
>> <mailto:jiangli.zhou at>> wrote:
>>> I wonder if the AnnotationArray pointers could be eliminated by 
>>> embedding the raw annotation data in ConstMethod directly. The 
>>> ConstMethod::_flags could still be kept as 8-bit, with one bit to 
>>> indicate if the method has any type of the annotations.
>> Using a bitmask is a good step.  We should package up this sort of 
>> trick so that it can be widely used in the JVM.  (See below.)
>> Beyond that, squishing 80%+ of all numbers down to a single byte 
>> would be the real pay-off.  That's what compressed streams do for 
>> debug information, and they should be used routinely for class 
>> metadata also.
>> There's no reason our metadata has to be so full of null bytes.  A 
>> large percentage of u2 and u4 words have nulls.  Down with entropy!
>> (Beyond that, making things sharable across processes, and/or using 
>> zip, would stack on more 2x-5x improvements.  Those two techniques 
>> amount to global and local duplicate removal.)
>> Check out this prototype (previously posted) for bundling together 
>> bytestreams in metadata:
>> The stream-bundle approach would allow "null-heavy" data like 
>> untransformed annotations to be stored as-is.  It would also 
>> encourage the use of more compact formats.
> Yes! Using a bitmask is even better than using 1-byte for each type 
> inside the stream. I think the definitely utilize the stream-bundle 
> approach.

We should talk about this as an improved technique for bundling 
metadata.  I did read through the code (and have it in this repository) 
but I think it's a bigger project to adapt it than what I've done.

> Thanks!
> Jiangli
>> — John

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the hotspot-runtime-dev mailing list