The updated webrev looks good.
Thanks,
Sean
On 4/7/17 8:39 PM, Weijun Wang wrote:
Webrev updated at
http://cr.openjdk.java.net/~weijun/8177969/webrev.02/
Changes since webrev.01:
1. Comments.
2. Another enhancement when I am writing comments. Since we can be sure
that a path has no ".." b
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://
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
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/
Hi,
another startup optimization for java.lang.invoke, this one collecting a
set of small fixes I've been wanting to get done for a while, including:
- no need to generate the signature strings in
BoundMethodHandle.makeCbmhCtor
- trusted MethodType lookups could be promoted without constructi
+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,
>
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
Hi,
Looks good.
LambdaForm.java
--
851 MethodType invokerType = methodType();
852 assert(vmentry == null ||
vmentry.getMethodType().basicType().equals(invokerType));
…
1183 assert(checkArgumentTypes(arguments, methodType()));
…
1201 assert(check
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html
The patch is trivial:
diff --git a/src/jdk.xml.bind/share/legal/relaxngdatatype.md
b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
--- a/src/jdk.xml.bind/share/legal/relaxngdatatype.md
+++ b/src/jdk.xml.bind
Hi,
On 2017-04-10 18:48, Paul Sandoz wrote:
Hi,
Looks good.
Thanks!
LambdaForm.java
--
851 MethodType invokerType = methodType();
852 assert(vmentry == null ||
vmentry.getMethodType().basicType().equals(invokerType));
This one was accidentally removed, will put it
> On 10 Apr 2017, at 10:31, Claes Redestad wrote:
>
> Hi,
>
>
> On 2017-04-10 18:48, Paul Sandoz wrote:
>> Hi,
>>
>> Looks good.
>
> Thanks!
>
>>
>> LambdaForm.java
>> --
>>
>> 851 MethodType invokerType = methodType();
>> 852 assert(vmentry == null ||
>> vmentry.getMet
On 2017-04-10 19:41, Paul Sandoz wrote:
On 10 Apr 2017, at 10:31, Claes Redestad wrote:
Don't expect too much! These two add up to about ~60k fewer bytecode executed
to bootstrap j.l.invoke
and run a trivial lambda, which is about 13% of the total and shows up as
around or somewhat less than
On 10/04/2017 18:22, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html
This looks okay to me.
-Alan
I think so. Will fix before push.
Mandy
> On Apr 10, 2017, at 11:03 AM, joe darcy wrote:
>
> Hello,
>
> Would it be better for the for the URL
>
> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)
>
> to use "tip"
>
> (http://hg.openj
Hello,
Would it be better for the for the URL
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)
to use "tip"
(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.crypto.ec/share/native/libsunec/impl)
Cheers,
-Joe
On 4/10/2017 10
Hi Claes,
There is no need to backport it to 8 & 9. 8 & 9 uses default
implementation, which is free from such tree corruption issue.
On 04/06/2017 03:45 AM, Claes Redestad wrote:
Hi Sergey,
this looks good to me*, but I can't help wonder if the modCount
checking is something that should b
On 2017-04-10 20:43, Sergey Kuksenko wrote:
Hi Claes,
There is no need to backport it to 8 & 9. 8 & 9 uses default
implementation, which is free from such tree corruption issue.
Ah, I misread the situation then, sorry for the noise.
/Claes
+1, looks good.
Thanks, Roger
On 4/10/2017 10:08 AM, Sean Mullan wrote:
The updated webrev looks good.
Thanks,
Sean
On 4/7/17 8:39 PM, Weijun Wang wrote:
Webrev updated at
http://cr.openjdk.java.net/~weijun/8177969/webrev.02/
Changes since webrev.01:
1. Comments.
2. Another enhancemen
Non-thread-pool changes committed while we wait for thread-pool CCC.
http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
> 8 lines changed: 0 ins; 2 del; 6 mod;
Hi all,
could you please review this tiny fix which clean up testlibary?
ProcessTools::createJavaProcessBuilder methods can not throw any checked
exceptions, but were declared with 'throw
Please review this test-only change.
tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java
This test fails intermittently on Windows platform in the final cleanup
step, @AfterClass, in which test tries to delete all dirs and files it
created. Though it’s okay to leave this cleanup work to
21 matches
Mail list logo
