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

[Claes Redestad]

Yes, I've seen some of these dirty hacks in the ASM code, as they show 
up here and there in
my startup graphs when I add some lambdas to the mix[1]... ;-)

I hadn't considered the 64K bytecode per method limitation, which means 
you couldn't even
generate a fraction of that number of elements in an array statically in 
a single method, so in
those cases the "FOO".toCharArray() hack makes more sense.

I think constant pool arrays could be a welcome bonus if it can be 
shaken out of the other
things we're doing for amber and valhalla...

Thanks!

/Claes

[1] Since Compact Strings the cost of String.charAt-loops and 
String.toCharArray has jumped
somewhat during startup, but will of course get compiled away and most 
often outperform
after warmup.

On 2017-04-11 20:20, forax at univ-mlv.fr wrote:
> 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.