Understanding Name and Name.Table

[Ron Shapiro]

>
> I have a prototype of a Name.Table implementation that stores Names as
> Strings instead of their UTF-8 byte[]. This seems to address the
> performance concerns from my previous thread (it saves 1.2s/build on some
> of our larger annotation processing builds at Google) without affecting the
> performance of internal javac (i.e. non-annotation processing). There
> should be no less overhead than the current Name implementations as it only
> needs to store a single field for the String, besides for the UTF-8/UTF-16
> distinction.
>
> What are the space comparisons? It is certainly the case that Strings are
> managed more efficiently in the JVM these days, and interned strings are
> handled better as well.  Your number of 1.2s doesn't mean much without more
> context that "our larger annotation processing builds."  What percent is
> that of the overall build time, and/or total time in Name/Name.Table.
>
 The Name.Table implementation is now one HashMap instead of one array of
bytes. Each Name implementation has an String field, an int for the index
in the table, and a lazily evaluated byte-array for the modified UTF-8
bytes. I could see if removing that would be beneficial or not.
SharedNameTable.Name has a pointer to the next name, the int index, and
another int for the length. UnsahredNameTable has the same byte array and
index as my prototype, but no String, and the table has it's own hash table.

An alternative that I raised previously is to keep the (Un)SharedNameTable
structure, but to add a lazily-evaluated String to each Name implementation.

Do you have a good tool to measure actual memory increases for runs of the
compiler?

I'm coming from the perspective that as long as memory growth is ~linear
and not huge, it's always worthwhile for a boost in time.

As for timings, I re-ran things and I'm seeing a 1.5s improvement for a
65.4s compilation.

Maurizio - I think there was probably a misunderstanding - I'm not doing
anything related to String.intern(). Agreed about HashMap > String.intern
at least in this case
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190422/0c08172d/attachment.html>