[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: RFR: JDK-8057556: JDP should better handle non-active interfaces

Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will be false and we will throw to exit the while loop). Is this intended? Thanks! /peter > On 4 sep 2014, at 17:59, Yasumasa Suenaga wrote: > > Hi all, > > Thank you so much, Dmitry! > > I've cre

[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

Re: test paths in repo

On Sep 4, 2014, at 9:55 PM, John Rose wrote: > David Chase and I just noticed files like this in the JDK: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/ > > The package for the test code is "org.openjdk.tests.java.util.stream

[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: RFR: JDK-8057556: JDP should better handle non-active interfaces

Hi Peter, I fixed it and created new webrev. http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.1/ Could you review it again? Thanks, Yasumasa (2014/09/05 17:20), Peter Allwin wrote: Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will b

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.

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) 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 (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) 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 (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 (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

On 09/05/2014 12:31 PM, Paul Sandoz wrote: 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. *@SuppressWarnings("LocalVariableHidesMemberVariable")* AFAIK, this is not a

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

[9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong methods

Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251 webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/ discussion:http://mail.openjdk.j

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

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:09 AM, Vladimir Ivanov >> wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8057654 >>> >> +1 >> >> Paul. >

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 (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

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 8055251: Re-examine Integer.parseInt and Long.parseLong methods

On 05/09/2014 14:03, Claes Redestad wrote: Hi, I'm requesting reviews and a sponsor for these changes to the recently added parse methods (8041972), suggested during discussions on net-dev: bug: https://bugs.openjdk.java.net/browse/JDK-8055251 webrev: http://cr.openjdk.java.net/~redestad/805525

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 (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

[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: Impact of code difference in Collection#contains() worth improving?

On Fri, Aug 29, 2014 at 7:53 PM, Guy Steele wrote: > > But I cannot resist recalling that one of the earliest pieces of software > in the implementation of EMACS (back when the implementation language was > TECO, a text-editing language) was a routine that, when it loaded TECO > macros from a fil

[8u40] RFR 6642881: Improve performance of Class.getClassLoader()

Summary: Add classLoader to java/lang/Class instance for fast access This is a backport request for 8u40. This change has been in the jdk9 code for 3 months without any problems. The JDK changes hg imported cleanly. The Hotspot change needed a hand merge for create_mirror call in klass.cpp

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: RFR (JAXP) 8056202: Xerces Update: Catalog Resolver

Hi Joe, This seems OK Best, Lance On Aug 28, 2014, at 10:46 PM, huizhe wang wrote: > Hi, > > This is an update to Xerces' Catalog Resolver implementation. The changes > were mostly performance related, for example the changes to the normalizeURI > method in Catalog.java to avoid creating new

Re: RFR (JAXP) 8056202: Xerces Update: Catalog Resolver

Thanks Lance! Joe On 9/5/2014 1:44 PM, Lance Andersen wrote: Hi Joe, This seems OK Best, Lance On Aug 28, 2014, at 10:46 PM, huizhe wang > wrote: Hi, This is an update to Xerces' Catalog Resolver implementation. The changes were mostly performance related,

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: Impact of code difference in Collection#contains() worth improving?

On Aug 30, 2014, at 7:17 AM, Ulf Zibis wrote: > Am 30.08.2014 um 01:33 schrieb John Rose: >> On Aug 29, 2014, at 1:05 PM, Ulf Zibis > > wrote: >> >>> Thanks for explaining this, but a very little nit: the immediate (I.e. -1) >>> uses additional 32/64 bits in code whi

Re: Impact of code difference in Collection#contains() worth improving?

On Aug 30, 2014, at 10:58 AM, Doug Lea wrote: > In the present case, I'm with Martin about short-circuiting > this with a simple approximate answer: Rather than flip a coin > choosing between solutions A and B, pick the one with smaller bytecode. > This has a decent enough correlation with actual