[10] RFR: 8178384: Reduce work in java.lang.invoke initializers

[forax at univ-mlv.fr]

Hi Claes,
yes !

We use something equivalent to "FOO".toCharArray() at several place in ASM because there is no constant pool constant arrays [1].

Terence Parr also mentions that issue at the JVM Summit 2009 [2].

Rémi
[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/645c0d3e3977/src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java#l556 
[2] http://parrt.cs.usfca.edu/doc/impl-parsers-in-java.pdf


----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, core-libs-dev at openjdk.java.net, "Paul Sandoz" <paul.sandoz at oracle.com>
> Envoyé: Mardi 11 Avril 2017 10:37:45
> Objet: Re: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers

> Sounds like you want https://bugs.openjdk.java.net/browse/JDK-8061402 -
> which was originally filed back in 2002 but was closed since it got
> filed on the wrong component or something... ¯\_(ツ)_/¯
> 
> There's still a number of char[] foo = "FOO".toCharArray() in the JDK
> since this allows for a more compact representation in bytecode (but is
> likely a bit slower during startup, especially since compact strings).
> 
> /Claes
> 
> On 04/10/2017 06:32 PM, Remi Forax wrote:
>> Currently playing with a pattern matching representation for Amber, if
>> think we need a form of array constant that does not require a
>> bootstrap method.
>> Afaik, an array of any existing constants does not need a Java code to
>> construct itself.
>>
>> Rémi
>>
>>
>> On April 10, 2017 6:18:07 PM GMT+02:00, Paul Sandoz
>> <paul.sandoz at oracle.com> wrote:
>>
>>     +1
>>
>>     These named functions really wanna be LDC’ed but i suspect using constant
>>     dynamic + representation in source (when available) might result in it’s own
>>     bootstrap issues, still it would be interesting to try when available.
>>
>>     Paul.
>>
>>         On 10 Apr 2017, at 07:09, Claes Redestad
>>         <claes.redestad at oracle.com> wrote: Hi, profiling initializers
>>         in java.lang.invoke shows we're still doing various things
>>         during class initialization which could be done lazily or not
>>         at all. The proposed patch reduce bytecode executed, memory
>>         churn and retained heap footprint when initializing
>>         java.lang.invoke: Webrev:
>>         http://cr.openjdk.java.net/~redestad/8178384/jdk.01
>>         <http://cr.openjdk.java.net/%7Eredestad/8178384/jdk.01>/ Bug:
>>         https://bugs.openjdk.java.net/browse/JDK-8178384 Testing:
>>         java.lang.invoke jtreg tests, sanity performance testing
>>         Thanks! /Claes
>>
>>
>>
>>
>> --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.