Request for review 8007320: NPG: move method annotations
Jiangli Zhou
jiangli.zhou at oracle.com
Fri Feb 1 12:11:29 PST 2013
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 oracle.com
> <mailto:jiangli.zhou at oracle.com>> 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:
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-January/007807.html
> https://blogs.oracle.com/jrose/resource/hotspot/streamBundle.patch.zip
>
> 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.
Thanks!
Jiangli
>
> — John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130201/6debeae6/attachment.html
More information about the hotspot-runtime-dev
mailing list