RFR: 8004643 Reduce javac space overhead introduced with compiler support for repeating annotations
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Jun 4 09:13:57 PDT 2013
Hi Jon,
the patch is fine in th short term - this is a list of issues I think we
should work on to alleviate the pain in this area:
*) There's an annoying split between symbol annos and type annos; we
have twice the methods we need - I think some work should be done to
consolidate existing APIs onto a more stable version where stuff like this:
public boolean hasAnnotations() {
+ return (annotations != null && !annotations.isEmpty());
+ }
+
+ public boolean hasTypeAnnotations() {
+ return (annotations != null && !annotations.isTypesEmpty());
+ }
Is replaced by this:
public boolean hasAnnotations(AnnoKind kind) { ... }
*) I think all methods that modify annotations should not be exposed
through Symbol API
*) This should be done via a Symbol flag
- annotationsPendingCompletion
In other words, I would keep the Symbol API light by providing:
*) a way for getting symbol/type annos
*) a way to tell as to whether annotation completion has already
happened (i.e. will the above method yield meaningful answer?)
Everything else should be done through a separate class (Annotations),
pretty much like we do now, by accessing symbol's metadata and playing
with it. I also would remove any back pointer from Annotations to Symbol
(if any).
Maurizio
On 01/06/13 03:14, Jonathan Gibbons wrote:
> More from the javac janitation crew, cleaning up the odds and ends.
>
> This is a relatively simple fix for the space overhead introduced by
> allocating an Annotations object for every Symbol. The fix is to hide
> the Annotations object behind methods in Symbol (which also cleans up
> the client code a bunch) and to lazily allocate the Annotations object
> if and only if it is needed. If the reference to the Annotations
> object is null, that means "no annotations on this symbol". (I tried
> using an immutable empty object, but it caused more clutter than it
> saved.)
>
> Most notably, Annotations is not itself changed by this changeset.
>
> The savings on a JDK build are significant, going from every Symbol
> having an Annotations object, to < 1% of Symbols needing an
> Annotations object ... from 4,024,455 to just 35,272. In the table
> below, each row is a separate javac compilation in the JDK build. The
> left hand block of numbers comes from a recent build of TL; the right
> hand block of numbers comes from a build of TL with the patch applied.
> There may be more optimizations possible, by further improving the
> checks on whether a new Annotations object is required.
>
> There's a couple of related minor cleanups here as well. Going
> forward, it would be nice to clean up the method names on Annotations
> and the wrapper methods on Symbol. There's an inconsistent set of
> names using fragments like {(empty), Raw, Declaration, Type} x
> {Attributes, Annotations}. Once we can decide on a better set of
> names, we can do a separate "renaming only" changeset for that.
>
> The webrev is available at
> http://cr.openjdk.java.net/~jjg/8004643/webrev.00/ It is against
> tl/langtools.
>
> -- Jon
>
>
>
>
>
> OLD
>
>
> NEW
>
>
>
> Symbols Annotations %
> Symbols Annotations %
>
>
> 269,144 269,144 100.00%
> 269,191 1,817 0.67%
>
>
> 4,463 4,463 100.00%
> 4,463 32 0.72%
>
>
> 39,845 39,845 100.00%
> 39,845 40 0.10%
>
>
> 2,276 2,276 100.00%
> 2,276 7 0.31%
>
>
> 224,546 224,546 100.00%
> 224,546 182 0.08%
>
>
> 356,137 356,137 100.00%
> 356,137 343 0.10%
>
>
> 8,610 8,610 100.00%
> 8,610 37 0.43%
>
>
> 428,097 428,097 100.00%
> 428,097 4,884 1.14%
>
>
> 49,031 49,031 100.00%
> 49,031 253 0.52%
>
>
> 1,338 1,338 100.00%
> 1,338 4 0.30%
>
>
> 2,016,962 2,016,962 100.00%
> 2,017,279 9,824 0.49%
>
>
> 2,642 2,642 100.00%
> 3,944 110 2.79%
>
>
> 3,937 3,937 100.00%
> 2,642 78 2.95%
>
>
> 3,944 3,944 100.00%
> 3,937 112 2.84%
>
>
> 4,015 4,015 100.00%
> 4,015 101 2.52%
>
>
> 5,361 5,361 100.00%
> 4,462 120 2.69%
>
>
> 4,779 4,779 100.00%
> 5,361 139 2.59%
>
>
> 3,855 3,855 100.00%
> 4,281 88 2.06%
>
>
> 4,281 4,281 100.00%
> 4,779 135 2.82%
>
>
> 4,462 4,462 100.00%
> 4,447 107 2.41%
>
>
> 4,546 4,546 100.00%
> 4,546 102 2.24%
>
>
> 5,795 5,795 100.00%
> 3,855 28 0.73%
>
>
> 4,447 4,447 100.00%
> 5,795 144 2.48%
>
>
> 5,176 5,176 100.00%
> 6,496 117 1.80%
>
>
> 6,496 6,496 100.00%
> 5,176 144 2.78%
>
>
> 6,056 6,056 100.00%
> 6,056 118 1.95%
>
>
> 5,759 5,759 100.00%
> 5,759 112 1.94%
>
>
> 4,926 4,926 100.00%
> 4,926 106 2.15%
>
>
> 1,025 1,025 100.00%
> 6,468 136 2.10%
>
>
> 3,697 3,697 100.00%
> 4,185 43 1.03%
>
>
> 6,468 6,468 100.00%
> 7,804 139 1.78%
>
>
> 4,185 4,185 100.00%
> 3,697 40 1.08%
>
>
> 7,809 7,809 100.00%
> 1,025 12 1.17%
>
>
> 8,878 8,878 100.00%
> 8,878 170 1.91%
>
>
> 7,804 7,804 100.00%
> 7,809 173 2.22%
>
>
> 1,029 1,029 100.00%
> 10,420 164 1.57%
>
>
> 1,403 1,403 100.00%
> 8,011 183 2.28%
>
>
> 10,420 10,420 100.00%
> 10,024 227 2.26%
>
>
> 8,011 8,011 100.00%
> 11,303 190 1.68%
>
>
> 10,024 10,024 100.00%
> 12,225 231 1.89%
>
>
> 11,303 11,303 100.00%
> 1,029 12 1.17%
>
>
> 12,225 12,225 100.00%
> 1,403 28 2.00%
>
>
> 15,827 15,827 100.00%
> 15,827 173 1.09%
>
>
> 12,642 12,642 100.00%
> 12,686 166 1.31%
>
>
> 124,653 124,653 100.00%
> 124,654 2,824 2.27%
>
>
> 39,797 39,797 100.00%
> 39,797 691 1.74%
>
>
> 255,866 255,866 100.00%
> 255,910 10,386 4.06%
>
> TOTAL 4,023,992 4,023,992 100.00%
> 4,024,445 35,272 0.88%
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20130604/a44a481f/attachment-0001.html
More information about the type-annotations-dev
mailing list