Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Remi, Just curious - was that C1 compiler output? I recall Tom Rodriguez mentioning a while ago (while this same topic was discussed on another thread) that C2 is more aggressive about inlining, and doesn't have a hard stop at 35 bytes. Thanks Sent from my phone On Sep 5, 2014 4:39 PM, "Remi For

Re: [9] Review request : JDK-8057707: TEST library enhancement: copy sun.hotspot.whitebox classes from hotspot repo and enhance lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java

These test are for core-libs feature, but we want to test that unused lambda forms are garbage collected using WhiteBox.fullGC() method. There are three tests that use one common class, only one of them uses whitebox api. So it is hard to move one of tests to hotspot repo. - Konstantin --

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/05/2014 04:07 PM, Morris Meyer wrote: Remi, That assert in a static method could be pulled out to a static block. Regarding the asserts in the LambdaForms code, my feeling is that in code that is still in the process of being refactored, that they are critical to maintain integrity. A

Re: [9] Review request : JDK-8057707: TEST library enhancement: copy sun.hotspot.whitebox classes from hotspot repo and enhance lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java

On 05/09/2014 18:57, Konstantin Shefov wrote: Hello, Please review the change in testlibrary https://bugs.openjdk.java.net/browse/JDK-8057707 This change is needed for new tests for the feature "Lambda Form Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703 Webrev of the

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On Sep 5, 2014, at 7:07 AM, Morris Meyer wrote: > That assert in a static method could be pulled out to a static block. > > Regarding the asserts in the LambdaForms code, my feeling is that in code > that is still in the process of being refactored, that they are critical to > maintain integri

[9] Review request : JDK-8057719: Develop new tests for LambdaForm Reduction and Caching feature

Hello, Please review the new tests for the feature "Lambda Form Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703 JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719 Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/ These tests also depend on testlib

[9] Review request : JDK-8057707: TEST library enhancement: copy sun.hotspot.whitebox classes from hotspot repo and enhance lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java

Hello, Please review the change in testlibrary https://bugs.openjdk.java.net/browse/JDK-8057707 This change is needed for new tests for the feature "Lambda Form Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703 Webrev of the testlibrary change: http://cr.openjdk.java.ne

Re: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles

On Jul 16, 2014, at 1:50 AM, Paul Sandoz wrote: > Why not make the second parameter be "DirectMethodHandle mh" ? Good suggestion; thanks. Makes the restrictReceiver logic less magic. — John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://

Re: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks

>> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057656 854 if (!canConvert(returnType(), newType.returnType())) 855 return false; 856 Class[] srcTypes = newType.ptypes; 857 Class[] dstTypes = ptype

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Remi, That assert in a static method could be pulled out to a static block. Regarding the asserts in the LambdaForms code, my feeling is that in code that is still in the process of being refactored, that they are critical to maintain integrity. After the dust settles, creating a debugging s

Re: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles

On Sep 5, 2014, at 3:15 PM, Vladimir Ivanov wrote: >> >> Looks good, just one comment. >> >> MethodHandles.restrictReceiver >> >> This method has: >> >> 1578 private MethodHandle restrictReceiver(MemberName method, >> MethodHandle mh, Class caller) throws IllegalAccessException { >>

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

Paul, Remi, thanks for review. Renamed type -> mtype & removed @SuppressWarnings. Updated webrev in place. Best regards, Vladimir Ivanov On 9/5/14, 5:13 PM, Paul Sandoz wrote: On Sep 5, 2014, at 2:30 PM, Remi Forax wrote: On 09/05/2014 12:31 PM, Paul Sandoz wrote: On Sep 5, 2014, at 10:

Re: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method handles

http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8050173 Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses. Also, some cleanups: * rewrote MH.viewAsType on top of MH.copyWith; * extended M

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Totally agree on that bytecode based metrics are evil. On 05 Sep 2014, at 14:32, Thomas Wuerthinger wrote: > This is why Graal’s inlining heuristics are not based on the number of > bytecodes, but the complexity of the compiler graph after applying > canonicalisation. Adding asserts to the by

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Paul, Peter, Morris, thanks for review. Best regards, Vladimir Ivanov On 9/5/14, 3:51 PM, Paul Sandoz wrote: On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov wrote: Paul, thanks for review. Generally looks good (re: Peter's observation of continue/break). - LambdaFormEditor 61 privat

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

This is why Graal’s inlining heuristics are not based on the number of bytecodes, but the complexity of the compiler graph after applying canonicalisation. Adding asserts to the bytecodes should not influence peak performance when they are disabled. Same for expressing the same logic with a dif

Re: Truffle and mlvm

On 09/05/2014 11:41 AM, Ali Ebrahimi wrote: Hi, On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax > wrote: I think that in term of concepts there is a kind of convergence between the couples Graal/Truffle and c2/java.lang.invoke. The force of Graal is to be ab

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov wrote: > Paul, thanks for review. > >> Generally looks good (re: Peter's observation of continue/break). >> >> - LambdaFormEditor >> >> 61 private static final class Transform { >> 62 final long packedBytes; >> 63 final by

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

To the style rant, I mean. On 05 Sep 2014, at 13:40, Marcus Lagergren wrote: > +1 > > On 05 Sep 2014, at 12:46, Aleksey Shipilev > wrote: > >> On 09/05/2014 12:09 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ >>> https://bugs.openjdk.java.net/browse/J

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

+1 On 05 Sep 2014, at 12:46, Aleksey Shipilev wrote: > On 09/05/2014 12:09 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8057654 > > Random style rant of the week, not particularly about this concrete > patch. C

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Paul, thanks for review. Generally looks good (re: Peter's observation of continue/break). - LambdaFormEditor 61 private static final class Transform { 62 final long packedBytes; 63 final byte[] fullBytes; 64 final LambdaForm result; // result of transf

Re: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks

On Sep 5, 2014, at 10:23 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057656 > 854 if (!canConvert(returnType(), newType.returnType())) 855 return false; 856 Class[] srcTypes = n

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

On 09/05/2014 12:09 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057654 Random style rant of the week, not particularly about this concrete patch. Can we please try to systematically use more readable/robust/secure

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

On Sep 5, 2014, at 10:09 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057654 > +1 Paul. signature.asc Description: Message signed with OpenPGP using GPGMail ___ m

[9] RFR (S): 8057657: Annotate LambdaForm parameters with types

http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057657 Add ability to annotate LambdaForm parameters with their types. Type info could be useful during LambdaForm compilation to produce better bytecode. Testing: jdk/java/lang/invoke, jdk/java/u

Re: Truffle and mlvm

Hi, On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax wrote: > I think that in term of concepts there is a kind of convergence between > the couples Graal/Truffle and c2/java.lang.invoke. > > The force of Graal is to be able to do partial evaluation directed user > code or by annotations, for me, Hot

Re: Truffle and mlvm

I think that in term of concepts there is a kind of convergence between the couples Graal/Truffle and c2/java.lang.invoke. The force of Graal is to be able to do partial evaluation directed user code or by annotations, for me, Hotspot is moving in that direction too, it already has special ann

[9] RFR (S) 8057656: Improve MethodType.isCastableTo() & MethodType.isConvertibleTo() checks

http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057656 There are some corner cases which MT.isCastableTo() & MT.isConvertibleTo() don't treat right (e.g. int->String converstion of return type in MT.isCastableTo()). Testing: jdk/java/lang/invo

[9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057654 The idea is to separate construction logic and different checks performed before/during method handle construction. For example: move checks from MHs.foldArguments into MHs.foldArgumentChec

Re: Defining anonymous classes

On 08/14/2014 12:52 PM, Florian Weimer wrote: Is there an end-user accessible way of defining anonymous classes (by which I mean classes which are kept alive only by explicit references or their instances, and not their class loader)? Searching for the term "anonymous classes" isn't particula

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/03/2014 07:46 PM, John Rose wrote: On Sep 3, 2014, at 10:35 AM, Mark Roos wrote: From Morris All that assert laden code is nice to see. I just finished watching a video from Doug Lea where he mentioned that having asserts can inhibit inlining due to the additional byte code