ctweb/asm/ClassWriter.java#l556
[2] http://parrt.cs.usfca.edu/doc/impl-parsers-in-java.pdf
- Mail original -
De: "Claes Redestad"
À: "Remi Forax" , core-libs-dev@openjdk.java.net, "Paul Sandoz"
Envoyé: Mardi 11 Avril 2017 10:37:45
Objet: Re: [10] RFR: 8178384: R
;
> 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 co
Thanks! Pushed.
/Claes
On 04/11/2017 11:16 AM, Vladimir Ivanov wrote:
Reviewed.
Best regards,
Vladimir Ivanov
Reviewed.
Best regards,
Vladimir Ivanov
On 4/11/17 12:06 PM, Claes Redestad wrote:
On 04/10/2017 05:20 PM, Claes Redestad wrote:
On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
Looks good.
Thanks for reviewing!
One small suggestion [1]
Sure, updated in-place.
Taking a second look a
On 04/10/2017 05:20 PM, Claes Redestad wrote:
On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
Looks good.
Thanks for reviewing!
One small suggestion [1]
Sure, updated in-place.
Taking a second look at these constants, it turned out that a few of
them were unused, but since they
weren
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
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 Sa
+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 wrote:
>
> Hi,
>
On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
Looks good.
Thanks for reviewing!
One small suggestion [1]
Sure, updated in-place.
/Claes
Best regards,
Vladimir Ivanov
[1] diff --git
a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
b/src/java.base/share/classes/
Looks good.
One small suggestion [1]
Best regards,
Vladimir Ivanov
[1] diff --git
a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.j
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://
11 matches
Mail list logo