From timo.kinnunen at gmail.com Sun Nov 1 00:01:57 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Sun, 1 Nov 2015 01:01:57 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> Message-ID: <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> Hi, Regarding ? I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. ? How does changing the type from ?T? to ?? extends T? aid the method caller in any way? If the caller has a Function like this: Function, String> funct; but they wished they could have walk use T=CharSequence instead, then they can simply assign the value returned from walk to a CharSequence variable: String result = sw.walk(funct, i -> i); CharSequence chars = result; Isn?t ?? extends T? pointless here? Sent from Mail for Windows 10 From: Mandy Chung Sent: Saturday, October 31, 2015 23:59 To: Remi Forax Cc: core-libs-dev at openjdk.java.net Subject: Re: Proposed API for JEP 259: Stack-Walking API > On Oct 31, 2015, at 11:29 AM, Remi Forax wrote: > > Hi Mandy, > I've crawled the code and the documentation again. > > In the doc and in the code, a lambda with one parameter doesn't require parenthesis around the parameter, > (s) -> s.doSomething() > should be > s -> s.doSomething(). > Oh right. (It didn?t look right to me but didn?t pay attention to it). > > In the doc of StackWalker, > in the first example, the local variable 'frame' should be named ?callerClass' > Fixed > > In the doc of getCallerClass(), > the first example do a skip(2) which i believe is not necessary anymore, It has to skip two frames. Use the second example, the stack looks like this: StackWalk::getCallerClass Util::getResourceBundle Foo::init : : > also instead of Optional.orElse, orElseGet is better because it avoids to evaluate > Thread.currentThread().getClass() if not necessary. > > So the example should be: > walk(s -> s.map(StackFrame::getDeclaringClass) > .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); > This would return Util.class instead of Foo.class > In the second example, the field walker should be declared 'final?. Sure. Fixed. > > And as i said earlier, the signature of walk() is: > T walk(Function, ? extends T> function, IntUnaryOperator batchSizeMapper) > I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. But for the function?s input argument, can you help me understand why it should take "? super Stream?? Is it useful to have function accepting supertype of Stream rather than Stream? VM should be the only source producing this StackFrame stream. On the other hand, I wonder if the stream argument should be Stream that may allow future implementation change. T walk(Function, ? extends T> function, ?) Mandy From misterm at gmail.com Sun Nov 1 00:12:30 2015 From: misterm at gmail.com (Michael Nascimento) Date: Sat, 31 Oct 2015 17:12:30 -0700 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Vitaly, Exactly, I was just trying to point out the method signature seems broken anyway. Regards, Michael On 31 Oct 2015 11:59, "Vitaly Davidovich" wrote: > This would require Supplier>, not Supplier Optional>. > > sent from my phone > On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote: > >> If this instance is an Optional , passing an >> Optional will fail to compile. >> >> Regards, >> Michael >> On 31 Oct 2015 11:21, "Stefan Zobel" wrote: >> >> > 2015-10-31 19:11 GMT+01:00 Remi Forax : >> > >> > > Hi all, hi Paul, >> > > >> > > I've just seen that Optional.or is declared as >> > > public Optional or(Supplier> supplier) { >> > > instead of >> > > public Optional or(Supplier> supplier) { >> > > >> > > regards, >> > > R?mi >> > > >> > >> > >> > I don't get it. Optional is final anyway. Can you explain? >> > >> > Thanks, >> > Stefan >> > >> > From mandy.chung at oracle.com Sun Nov 1 04:36:21 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 31 Oct 2015 21:36:21 -0700 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> Message-ID: In fact, T walk(Function, T> function, ?) - without ? extends T change, You can do: Function, String> funct; CharSequence chars = sw.walk(funct, i -> i); I think it?s right to declare the return type of the function is "? extends T?. Mandy > On Oct 31, 2015, at 5:01 PM, Timo Kinnunen wrote: > > Hi, > > Regarding ? > I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. > ? > > How does changing the type from ?T? to ?? extends T? aid the method caller in any way? If the caller has a Function like this: > > Function, String> funct; > > but they wished they could have walk use T=CharSequence instead, then they can simply assign the value returned from walk to a CharSequence variable: > > String result = sw.walk(funct, i -> i); > CharSequence chars = result; > > > Isn?t ?? extends T? pointless here? > > > > > > Sent from Mail for Windows 10 > > > > From: Mandy Chung > Sent: Saturday, October 31, 2015 23:59 > To: Remi Forax > Cc: core-libs-dev at openjdk.java.net > Subject: Re: Proposed API for JEP 259: Stack-Walking API > > > > > On Oct 31, 2015, at 11:29 AM, Remi Forax wrote: > > > > Hi Mandy, > > I've crawled the code and the documentation again. > > > > In the doc and in the code, a lambda with one parameter doesn't require parenthesis around the parameter, > > (s) -> s.doSomething() > > should be > > s -> s.doSomething(). > > > > Oh right. (It didn?t look right to me but didn?t pay attention to it). > > > > > In the doc of StackWalker, > > in the first example, the local variable 'frame' should be named ?callerClass' > > > > Fixed > > > > In the doc of getCallerClass(), > > the first example do a skip(2) which i believe is not necessary anymore, > > It has to skip two frames. Use the second example, the stack looks like this: > > StackWalk::getCallerClass > Util::getResourceBundle > Foo::init > : > : > > > also instead of Optional.orElse, orElseGet is better because it avoids to evaluate > > Thread.currentThread().getClass() if not necessary. > > > > So the example should be: > > walk(s -> s.map(StackFrame::getDeclaringClass) > > .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); > > > > This would return Util.class instead of Foo.class > > > In the second example, the field walker should be declared 'final?. > > Sure. Fixed. > > > > > And as i said earlier, the signature of walk() is: > > T walk(Function, ? extends T> function, IntUnaryOperator batchSizeMapper) > > > > I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. > > But for the function?s input argument, can you help me understand why it should take "? super Stream?? Is it useful to have function accepting supertype of Stream rather than Stream? VM should be the only source producing this StackFrame stream. > > On the other hand, I wonder if the stream argument should be Stream that may allow future implementation change. > > T walk(Function, ? extends T> function, ?) > > Mandy From jeroen at sumatra.nl Sun Nov 1 06:05:29 2015 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sun, 1 Nov 2015 06:05:29 +0000 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: Message-ID: <0a160afad2984d24b14619505281889f@mane.sumatrasoftware.com> Hi Mandy, I like the API shape and this capability is very much needed. Thanks! It does bring something related to mind and that is that the current Java ecosystem is already very dependent on accurate stack frames (i.e. not removing them when inlining) and with this API this will probably only become worse. So it might be worth considering making this a hard spec requirement. Regards, Jeroen > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Mandy Chung > Sent: Friday, October 30, 2015 20:05 > To: core-libs-dev > Subject: Proposed API for JEP 259: Stack-Walking API > > JEP 259: http://openjdk.java.net/jeps/259 > > Javadoc for the proposed StackWalker API: > > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker > .html > > A simple way to walk the stack: > > StackWalker walker = new > StackWalker(StackWalker.Option.CLASS_REFERENCE); > walker.walk((s) -> s.filter(f -> > interestingClasses.contains(f.getDeclaringClass())).findFirst()); > > The current usage of sun.reflect.Reflection.getCallerClass(int depth) > can be replaced with this StackWalker API. > > Any feedback on the proposed API is appreciated. > > Mandy > > P.S. webrev of the current implementation: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ > > > > > > From timo.kinnunen at gmail.com Sun Nov 1 10:11:13 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Sun, 1 Nov 2015 11:11:13 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> Message-ID: <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> I?m not quite sure I follow you, so my apologies if I misunderstood you. What I?m trying to point out is that changing the type from ?T? to ?? extends T? doesn?t add any expressiveness in this method. These two signatures are both equally expressive for users of this API: public T walk(Function, T> function) public T walk(Function, ? extends T> function) Maybe this is easier to see if we give a name to our wildcard type: public T walk(Function, ? extends T> function) public T walk(Function, R> function) Clearly these two are equivalent, we just now have a real name for ?? extends T? is, it is ?R?. For a user who is calling this method, what is gained by having it return the potentially less specific type ?T? that could be some super type of ?R? and not have it just return the type ?R?? The implementation of walk doesn?t need them, it can be done without bringing in extra types from R?s type the hierarchy. I don?t think there is any gain. For all types where A extends B, B extends C, the method taking A and giving B to the user storing it to C gives a transformation A?B?C. For this case we have two transformation corresponding to the two alternative methods: In ? R walk(Function, R> function)?, R?R?T is available, because R extends T so R can be stored in T. In ? T walk(Function, R> f)?, R?T?T is available, because well, T is a T. Changing a single type parameter in an API from ?T? to ?? extends T? in a wrong place can have a dramatic effect on the quality of type inference results that the users receive when using the API. The affects functional programming style much, much more than it does a more procedural style. So I want to make it clear now that for most users a single additional wildcard in the API is not a disaster. For people doing more functional programming though, the effects can feel punishing as they have to add more casts, type arguments or extra local variables to make more types explicit --- which type inference would have otherwise inferred --- had the wildcard not been present. This is why I think it?s prudent that the expected benefits of adding any one new wildcard are stated clearly and in practical terms. These benefits can then be evaluated against the drawbacks, and an informed decision can be made. Which is why I would like to ask: - What are the expected benefits that arise from using a wildcard type in this method rather than a non-wildcard type, and - How will this manifest in practice in the code (i.e. what is one supposed to look for) to verify that the actual results match what we expected? TIA! Sent from Mail for Windows 10 From: Mandy Chung Sent: Sunday, November 1, 2015 05:36 To: Timo Kinnunen Cc: Remi Forax;core-libs-dev at openjdk.java.net Subject: Re: Proposed API for JEP 259: Stack-Walking API In fact, T walk(Function, T> function, ?) - without ? extends T change, You can do: Function, String> funct; CharSequence chars = sw.walk(funct, i -> i); I think it?s right to declare the return type of the function is "? extends T?. Mandy > On Oct 31, 2015, at 5:01 PM, Timo Kinnunen wrote: > > Hi, > > Regarding ? > I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. > ? > > How does changing the type from ?T? to ?? extends T? aid the method caller in any way? If the caller has a Function like this: > > Function, String> funct; > > but they wished they could have walk use T=CharSequence instead, then they can simply assign the value returned from walk to a CharSequence variable: > > String result = sw.walk(funct, i -> i); > CharSequence chars = result; > > > Isn?t ?? extends T? pointless here? > > > > > > Sent from Mail for Windows 10 > > > > From: Mandy Chung > Sent: Saturday, October 31, 2015 23:59 > To: Remi Forax > Cc: core-libs-dev at openjdk.java.net > Subject: Re: Proposed API for JEP 259: Stack-Walking API > > > > > On Oct 31, 2015, at 11:29 AM, Remi Forax wrote: > > > > Hi Mandy, > > I've crawled the code and the documentation again. > > > > In the doc and in the code, a lambda with one parameter doesn't require parenthesis around the parameter, > > (s) -> s.doSomething() > > should be > > s -> s.doSomething(). > > > > Oh right. (It didn?t look right to me but didn?t pay attention to it). > > > > > In the doc of StackWalker, > > in the first example, the local variable 'frame' should be named ?callerClass' > > > > Fixed > > > > In the doc of getCallerClass(), > > the first example do a skip(2) which i believe is not necessary anymore, > > It has to skip two frames. Use the second example, the stack looks like this: > > StackWalk::getCallerClass > Util::getResourceBundle > Foo::init > : > : > > > also instead of Optional.orElse, orElseGet is better because it avoids to evaluate > > Thread.currentThread().getClass() if not necessary. > > > > So the example should be: > > walk(s -> s.map(StackFrame::getDeclaringClass) > > .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); > > > > This would return Util.class instead of Foo.class > > > In the second example, the field walker should be declared 'final?. > > Sure. Fixed. > > > > > And as i said earlier, the signature of walk() is: > > T walk(Function, ? extends T> function, IntUnaryOperator batchSizeMapper) > > > > I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. > > But for the function?s input argument, can you help me understand why it should take "? super Stream?? Is it useful to have function accepting supertype of Stream rather than Stream? VM should be the only source producing this StackFrame stream. > > On the other hand, I wonder if the stream argument should be Stream that may allow future implementation change. > > T walk(Function, ? extends T> function, ?) > > Mandy From spliterator at gmail.com Sun Nov 1 12:31:02 2015 From: spliterator at gmail.com (Stefan Zobel) Date: Sun, 1 Nov 2015 13:31:02 +0100 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Message-ID: 2015-11-01 1:12 GMT+01:00 Michael Nascimento : > Hi Vitaly, > > Exactly, I was just trying to point out the method signature seems broken > anyway. > > Regards, > Michael Hi Michael, I don't think the signature is broken. An Optional is not a subtype of Optional. So even if the signature were public Optional or(Supplier> supplier) we'd have to upcast the result of supplier.get() to Optional which appears to be wrong from a type perspective. Regards, Stefan > > On 31 Oct 2015 11:59, "Vitaly Davidovich" wrote: >> >> This would require Supplier>, not Supplier> Optional>. >> >> sent from my phone >> >> On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote: >>> >>> If this instance is an Optional , passing an >>> Optional will fail to compile. >>> >>> Regards, >>> Michael >>> On 31 Oct 2015 11:21, "Stefan Zobel" wrote: >>> >>> > 2015-10-31 19:11 GMT+01:00 Remi Forax : >>> > >>> > > Hi all, hi Paul, >>> > > >>> > > I've just seen that Optional.or is declared as >>> > > public Optional or(Supplier> supplier) { >>> > > instead of >>> > > public Optional or(Supplier> supplier) { >>> > > >>> > > regards, >>> > > R?mi >>> > > >>> > >>> > >>> > I don't get it. Optional is final anyway. Can you explain? >>> > >>> > Thanks, >>> > Stefan From vitalyd at gmail.com Sun Nov 1 14:41:15 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sun, 1 Nov 2015 09:41:15 -0500 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Message-ID: One could argue that this is perfectly sound to do given Optional is readonly, we just can't express this variance cleanly in java (i.e. without upcast). sent from my phone On Nov 1, 2015 7:31 AM, "Stefan Zobel" wrote: > 2015-11-01 1:12 GMT+01:00 Michael Nascimento : > > Hi Vitaly, > > > > Exactly, I was just trying to point out the method signature seems broken > > anyway. > > > > Regards, > > Michael > > > Hi Michael, > > I don't think the signature is broken. > > An Optional is not a subtype of Optional. > So even if the signature were > > public Optional or(Supplier> supplier) > > we'd have to upcast the result of supplier.get() to Optional > which appears to be wrong from a type perspective. > > > Regards, > Stefan > > > > > > > On 31 Oct 2015 11:59, "Vitaly Davidovich" wrote: > >> > >> This would require Supplier>, not Supplier extends > >> Optional>. > >> > >> sent from my phone > >> > >> On Oct 31, 2015 2:49 PM, "Michael Nascimento" > wrote: > >>> > >>> If this instance is an Optional , passing an > >>> Optional will fail to compile. > >>> > >>> Regards, > >>> Michael > >>> On 31 Oct 2015 11:21, "Stefan Zobel" wrote: > >>> > >>> > 2015-10-31 19:11 GMT+01:00 Remi Forax : > >>> > > >>> > > Hi all, hi Paul, > >>> > > > >>> > > I've just seen that Optional.or is declared as > >>> > > public Optional or(Supplier> supplier) { > >>> > > instead of > >>> > > public Optional or(Supplier> supplier) { > >>> > > > >>> > > regards, > >>> > > R?mi > >>> > > > >>> > > >>> > > >>> > I don't get it. Optional is final anyway. Can you explain? > >>> > > >>> > Thanks, > >>> > Stefan > From spliterator at gmail.com Sun Nov 1 15:18:01 2015 From: spliterator at gmail.com (Stefan Zobel) Date: Sun, 1 Nov 2015 16:18:01 +0100 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Message-ID: 2015-11-01 15:41 GMT+01:00 Vitaly Davidovich : > One could argue that this is perfectly sound to do given Optional is > readonly, we just can't express this variance cleanly in java (i.e. without > upcast). > Sure, as in Scala's Option[+A]. I should have said "... from a **Java** type perspective ". Regards, Stefan > > On Nov 1, 2015 7:31 AM, "Stefan Zobel" wrote: >> >> 2015-11-01 1:12 GMT+01:00 Michael Nascimento : >> > Hi Vitaly, >> > >> > Exactly, I was just trying to point out the method signature seems >> > broken >> > anyway. >> > >> > Regards, >> > Michael >> >> >> Hi Michael, >> >> I don't think the signature is broken. >> >> An Optional is not a subtype of Optional. >> So even if the signature were >> >> public Optional or(Supplier> supplier) >> >> we'd have to upcast the result of supplier.get() to Optional >> which appears to be wrong from a type perspective. >> >> >> Regards, >> Stefan >> >> >> >> > >> > On 31 Oct 2015 11:59, "Vitaly Davidovich" wrote: >> >> >> >> This would require Supplier>, not Supplier> >> extends >> >> Optional>. >> >> >> >> sent from my phone >> >> >> >> On Oct 31, 2015 2:49 PM, "Michael Nascimento" >> >> wrote: >> >>> >> >>> If this instance is an Optional , passing an >> >>> Optional will fail to compile. >> >>> >> >>> Regards, >> >>> Michael >> >>> On 31 Oct 2015 11:21, "Stefan Zobel" wrote: >> >>> >> >>> > 2015-10-31 19:11 GMT+01:00 Remi Forax : >> >>> > >> >>> > > Hi all, hi Paul, >> >>> > > >> >>> > > I've just seen that Optional.or is declared as >> >>> > > public Optional or(Supplier> supplier) { >> >>> > > instead of >> >>> > > public Optional or(Supplier> supplier) >> >>> > > { >> >>> > > >> >>> > > regards, >> >>> > > R?mi >> >>> > > >> >>> > >> >>> > >> >>> > I don't get it. Optional is final anyway. Can you explain? >> >>> > >> >>> > Thanks, >> >>> > Stefan From spliterator at gmail.com Sun Nov 1 17:01:39 2015 From: spliterator at gmail.com (Stefan Zobel) Date: Sun, 1 Nov 2015 18:01:39 +0100 Subject: Optional.or() doesn't use a wildcard in its signature In-Reply-To: References: <1770652221.2547024.1446314919390.JavaMail.zimbra@u-pem.fr> <1960076570.2547169.1446315111675.JavaMail.zimbra@u-pem.fr> Message-ID: 2015-11-01 1:12 GMT+01:00 Michael Nascimento : > Hi Vitaly, > > Exactly, I was just trying to point out the method signature seems broken > anyway. > Rethinking it, I believe you are right. public Optional or(Supplier> supplier) would be more general and still be sound type-wise. There's a similar issue for Stream generate / iterate in the bugtracker https://bugs.openjdk.java.net/browse/JDK-8132097 Thanks, Stefan > On 31 Oct 2015 11:59, "Vitaly Davidovich" wrote: >> >> This would require Supplier>, not Supplier> Optional>. >> >> sent from my phone >> >> On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote: >>> >>> If this instance is an Optional , passing an >>> Optional will fail to compile. >>> >>> Regards, >>> Michael From Alan.Bateman at oracle.com Sun Nov 1 18:18:40 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Nov 2015 18:18:40 +0000 Subject: RFR: String Density/Compact String JEP 254 (update) In-Reply-To: <5633E16F.8090904@oracle.com> References: <56129786.1090402@oracle.com> <5633E16F.8090904@oracle.com> Message-ID: <56365780.8070607@oracle.com> On 30/10/2015 21:30, Xueming Shen wrote: > Hi, > > Thanks for the comments/suggestions. Here are the updated webrevs with > minor changes here > and there based on the feedback. I spent time going through the changes in jdk repo and it looks very good. One thing that isn't clear to me is why StringUTF16 needs a native method to test for big endian. Could it use Unsafe::isBigEndian or is there a non-obvious bootstrapping/initialization issue here? The additional test coverage looks quite good but I'm guessing many of these tests overlap with existing tests. Are you planning to leave them in the CompactStrings directory? I assume it would make more sense to move them up to the String directory. I was also wondering if more of the existing tests should be updated to run them both ways. In passing, SerializationUtils has a semi-colon at L47 that looks a bit odd. -Alan. From Alan.Bateman at oracle.com Sun Nov 1 18:25:36 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Nov 2015 18:25:36 +0000 Subject: [9] RFR 8141082: Add java/nio/Buffer/Basic.java to ProblemList.txt for 64-bit Linux In-Reply-To: <5633C758.8020408@oracle.com> References: <885137EA-CAD8-43F4-B398-6BEF70491694@oracle.com> <5633C758.8020408@oracle.com> Message-ID: <56365920.6020804@oracle.com> On 30/10/2015 19:39, joe darcy wrote: > Hi Brian, > > Looks fine. (I don't see existing uses of the exact clauses > "linux-amd64" and "linux-x64" in the problem list, but if you've > verified those clauses work as expected I think is is good to go back.) This is core functionality so if this test crashes then it's likely that the build is DOA. It might be better to focus on trying to diagnose the issue, in this case it sounds like the version of gcc used to create the JDK build is on the list of suspects. -Alan From xueming.shen at oracle.com Sun Nov 1 19:12:44 2015 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 1 Nov 2015 11:12:44 -0800 Subject: RFR: String Density/Compact String JEP 254 (update) In-Reply-To: <56365780.8070607@oracle.com> References: <56129786.1090402@oracle.com> <5633E16F.8090904@oracle.com> <56365780.8070607@oracle.com> Message-ID: <5636642C.9070902@oracle.com> On 11/1/15 10:18 AM, Alan Bateman wrote: > On 30/10/2015 21:30, Xueming Shen wrote: >> Hi, >> >> Thanks for the comments/suggestions. Here are the updated webrevs >> with minor changes here >> and there based on the feedback. > I spent time going through the changes in jdk repo and it looks very > good. > > One thing that isn't clear to me is why StringUTF16 needs a native > method to test for big endian. Could it use Unsafe::isBigEndian or is > there a non-obvious bootstrapping/initialization issue here? unsafe.putChar/getChar() were used in String (they are still being used in charset changes). http://cr.openjdk.java.net/~sherman/8054307/jdk.1030/src/java.base/share/classes/java/lang/StringUTF16.java.html However it triggered a vm failure in hotspot PIT, in which it appears the unsafe is not ready/loaded at certain circumstance. ...results/workDir/demo/jvmti/heapTracker/HeapTrackerTest/hs_err_pid12542.log So we are back to the old approach to go get the endian ourselves. > > The additional test coverage looks quite good but I'm guessing many of > these tests overlap with existing tests. Are you planning to leave > them in the CompactStrings directory? I assume it would make more > sense to move them up to the String directory. I was also wondering if > more of the existing tests should be updated to run them both ways. In > passing, SerializationUtils has a semi-colon at L47 that looks a bit odd. > Yes, it might be worth to take some time to re-organize the String tests. We can address it in a separate follow-up bug fix. Need take to the SQE team. Thanks, -Sherman From scolebourne at joda.org Sun Nov 1 21:46:21 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 1 Nov 2015 21:46:21 +0000 Subject: RFR 9: 8138963 : java.lang.Objects new method to default to non-null In-Reply-To: <5635249C.3050108@oracle.com> References: <5613D01F.3000107@Oracle.com> <91F25DF8-BC0F-44EB-A57D-A49FF7876DB9@oracle.com> <5617B184.7060803@oracle.com> <5617E141.7000503@Oracle.com> <50EAA3DD-46F5-4BF2-B010-333CEE7187A9@oracle.com> <5633BFF5.9090609@oracle.com> <5FDA255B-E3D7-4485-8C7C-6D98071D0A1F@oracle.com> <1317738244.2516893.1446290238651.JavaMail.zimbra@u-pem.fr> <1C154586-2033-4154-B75C-9125993D0AB9@oracle.com> <5635249C.3050108@oracle.com> Message-ID: On 31 October 2015 at 20:29, Roger Riggs wrote: > And, going back nearly to the beginning of the thread, some folks are > familiar with > > T firstNonNull(T, T) proposed from Guava. > > But since the exercise was turned into simplify: (x != null) ? x : > requireNonNull(y); > > My favorite at this point is to identify the thread as a failed attempt and > remove it. That would be a mistake. This is a classic simple method that the JDK should have (given that the Elvis operator was rejected). John's proposal is by far the best in the thread for consistency, even if it is long (and the long-ness mistake is the fault of the previous JDK release). Thus, we should have - T requireNonNull(T) - exists already - T requireNonNull(T,String) - exists already - T requireNonNull(T,Supplier) - exists already - T requireNonNullElse(T,T) - new I have no great need for either of these two, although I understand the rationale: - T requireNonNullElseGet(T,Supplier) - T requireNonNullElseThrow(T,Supplier) The "require is a precondition" debate is a red herring IMO. These methods easily make a set that check for null and "do something". "requireNonNullElse" requires that the first argument is non-null, just like the other three, its just that it does something softer if it is. Thus, I'd recommend adding "requireNonNullElse(T,T)" alone, and move on. Stephen From chris.hegarty at oracle.com Sun Nov 1 23:56:52 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 1 Nov 2015 23:56:52 +0000 Subject: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package Message-ID: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http://cr.openjdk.java.net/~chegar/8140687/00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138732 From david.holmes at oracle.com Mon Nov 2 00:54:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 Nov 2015 10:54:54 +1000 Subject: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package In-Reply-To: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> References: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> Message-ID: <5636B45E.3080208@oracle.com> Hi Chris, hotspot and jdk changes look fine to me. Thanks, David On 2/11/2015 9:56 AM, Chris Hegarty wrote: > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138732 > From chris.hegarty at oracle.com Mon Nov 2 01:39:30 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 2 Nov 2015 01:39:30 +0000 Subject: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package In-Reply-To: <5636B45E.3080208@oracle.com> References: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> <5636B45E.3080208@oracle.com> Message-ID: <9792D251-C531-4B08-9889-CFE922612A2A@oracle.com> > On 2 Nov 2015, at 12:54 a.m., David Holmes wrote: > > Hi Chris, > > hotspot and jdk changes look fine to me. Thanks for looking at this David. -Chris. > Thanks, > David > >> On 2/11/2015 9:56 AM, Chris Hegarty wrote: >> In line with the intended location for other VM annotations, >> see 8138732 [1], @sun.misc.Contended should be moved >> to the jdk.internal.vm.annotation package. >> >> http://cr.openjdk.java.net/~chegar/8140687/00/ >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8138732 >> From michael.haupt at oracle.com Mon Nov 2 08:12:46 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Mon, 2 Nov 2015 09:12:46 +0100 Subject: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev Message-ID: (Apologies for multiple posts with wrong subject lines.) > Dear all, > > cross-posted to jdk8u-dev and core-libs-dev. > > Please review this change. > Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 > Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00 > > This adds a missing test to 8u-dev that was not pushed along with the feature backport it belongs to. The backport was approved; see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html . > > Thanks, > > Michael From paul.sandoz at oracle.com Mon Nov 2 09:45:08 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Nov 2015 10:45:08 +0100 Subject: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package In-Reply-To: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> References: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> Message-ID: <62645084-68D2-4651-B79E-91677CA8FA2A@oracle.com> > On 2 Nov 2015, at 00:56, Chris Hegarty wrote: > > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ > +1 Paul. From paul.sandoz at oracle.com Mon Nov 2 09:45:30 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Nov 2015 10:45:30 +0100 Subject: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: References: Message-ID: > On 28 Oct 2015, at 20:55, Chris Hegarty wrote: > > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > +1 Paul. > This will be pushed to jdk9/dev once 8139891 makes its way from > hs-rt. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 From Alan.Bateman at oracle.com Mon Nov 2 10:22:23 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Nov 2015 10:22:23 +0000 Subject: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package In-Reply-To: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> References: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> Message-ID: <5637395F.50806@oracle.com> On 01/11/2015 23:56, Chris Hegarty wrote: > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8138732 Looks good. -Alan. From aleksey.shipilev at oracle.com Mon Nov 2 10:45:15 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 2 Nov 2015 13:45:15 +0300 Subject: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package In-Reply-To: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> References: <90229DBB-5D38-4334-96CD-20F6459B4ECA@oracle.com> Message-ID: <56373EBB.4040906@oracle.com> On 11/02/2015 02:56 AM, Chris Hegarty wrote: > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ Changes look good to me. But what's the compatibility story for JSR 166? With this move, we would be unable to bootclasspath JSR 166 JAR, since it references the "old" sun.misc.Contended? Thanks, -Aleksey From maurizio.cimadamore at oracle.com Mon Nov 2 12:26:18 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 2 Nov 2015 12:26:18 +0000 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> Message-ID: <5637566A.3000203@oracle.com> So, we have three potential signatures here: T walk(Function, T> function) //1 T walk(Function, ? extends T> function) //2 T walk(Function, R> function) //3 Under normal conditions (i.e. lambda parameter being passed to 'walk') I think all these signatures are fundamentally equivalent; (2) and (3) seem to have been designed for something like this: Number n = walk(s -> new Integer(1)); That is, the function returns something that is more specific w.r.t. what is expected in the return type of walk. But - in reality, if 'walk' returns an R that is a subtype of T (as in the third signature), then walk also returns a T (as R is a subtype of T), so the result value can be passed where a T is expected. The converse example: Integer n1 = walk(s -> (Number)null); Similarly fails on all three signatures. More generally, with all such signatures, T will always receive: * lower bound(s) (from the return value(s) of the lambda passed as a parameter to the 'walk' method) * one upper bound (from the target-type associated with the 'walk' call. Under such conditions, the upper bound will always be disregarded in favor of the lower bounds - meaning that instantiation of T will always be driven by what's inside the lambda. Signature (3) mentions different variables (R and T) but the end result is the same - as the bound says R extends T - meaning that lower bounds of R are propagated to T - leading to exactly the same situation. In other words, I don't think there are obvious examples in which the behavior of these three signatures will be significantly different - if the return type of 'walk' would have been a generic type such as List, the situation would have been completely different - with with a 'naked' T, I think the first signature is good enough, and the third is, in my opinion, making things harder than what they need to be. I think the second signature is not necessary, from a pure type-system perspective; but I guess one could make an argument for it, but purely in terms of consistency with other areas (after all, the second type-parameter of a Function is in a covariant position). I hope this helps. Maurizio On 01/11/15 10:11, Timo Kinnunen wrote: > I?m not quite sure I follow you, so my apologies if I misunderstood you. What I?m trying to point out is that changing the type from ?T? to ?? extends T? doesn?t add any expressiveness in this method. These two signatures are both equally expressive for users of this API: > > public T walk(Function, T> function) > public T walk(Function, ? extends T> function) > > Maybe this is easier to see if we give a name to our wildcard type: > > public T walk(Function, ? extends T> function) > public T walk(Function, R> function) > > Clearly these two are equivalent, we just now have a real name for ?? extends T? is, it is ?R?. For a user who is calling this method, what is gained by having it return the potentially less specific type ?T? that could be some super type of ?R? and not have it just return the type ?R?? The implementation of walk doesn?t need them, it can be done without bringing in extra types from R?s type the hierarchy. > > I don?t think there is any gain. For all types where A extends B, B extends C, the method taking A and giving B to the user storing it to C gives a transformation A?B?C. For this case we have two transformation corresponding to the two alternative methods: > > In ? R walk(Function, R> function)?, R?R?T is available, because R extends T so R can be stored in T. > In ? T walk(Function, R> f)?, R?T?T is available, because well, T is a T. > > Changing a single type parameter in an API from ?T? to ?? extends T? in a wrong place can have a dramatic effect on the quality of type inference results that the users receive when using the API. The affects functional programming style much, much more than it does a more procedural style. So I want to make it clear now that for most users a single additional wildcard in the API is not a disaster. For people doing more functional programming though, the effects can feel punishing as they have to add more casts, type arguments or extra local variables to make more types explicit --- which type inference would have otherwise inferred --- had the wildcard not been present. > > This is why I think it?s prudent that the expected benefits of adding any one new wildcard are stated clearly and in practical terms. These benefits can then be evaluated against the drawbacks, and an informed decision can be made. Which is why I would like to ask: > > - What are the expected benefits that arise from using a wildcard type in this method rather than a non-wildcard type, and > - How will this manifest in practice in the code (i.e. what is one supposed to look for) to verify that the actual results match what we expected? > > > TIA! > > > > > > > > Sent from Mail for Windows 10 > > > > From: Mandy Chung > Sent: Sunday, November 1, 2015 05:36 > To: Timo Kinnunen > Cc: Remi Forax;core-libs-dev at openjdk.java.net > Subject: Re: Proposed API for JEP 259: Stack-Walking API > > > In fact, T walk(Function, T> function, ?) - without ? extends T change, > > You can do: > Function, String> funct; > CharSequence chars = sw.walk(funct, i -> i); > > I think it?s right to declare the return type of the function is "? extends T?. > > Mandy > > >> On Oct 31, 2015, at 5:01 PM, Timo Kinnunen wrote: >> >> Hi, >> >> Regarding ? >> I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. >> ? >> >> How does changing the type from ?T? to ?? extends T? aid the method caller in any way? If the caller has a Function like this: >> >> Function, String> funct; >> >> but they wished they could have walk use T=CharSequence instead, then they can simply assign the value returned from walk to a CharSequence variable: >> >> String result = sw.walk(funct, i -> i); >> CharSequence chars = result; >> >> >> Isn?t ?? extends T? pointless here? >> >> >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: Mandy Chung >> Sent: Saturday, October 31, 2015 23:59 >> To: Remi Forax >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: Proposed API for JEP 259: Stack-Walking API >> >> >> >>> On Oct 31, 2015, at 11:29 AM, Remi Forax wrote: >>> >>> Hi Mandy, >>> I've crawled the code and the documentation again. >>> >>> In the doc and in the code, a lambda with one parameter doesn't require parenthesis around the parameter, >>> (s) -> s.doSomething() >>> should be >>> s -> s.doSomething(). >>> >> >> Oh right. (It didn?t look right to me but didn?t pay attention to it). >> >>> In the doc of StackWalker, >>> in the first example, the local variable 'frame' should be named ?callerClass' >>> >> >> Fixed >>> In the doc of getCallerClass(), >>> the first example do a skip(2) which i believe is not necessary anymore, >> >> It has to skip two frames. Use the second example, the stack looks like this: >> >> StackWalk::getCallerClass >> Util::getResourceBundle >> Foo::init >> : >> : >> >>> also instead of Optional.orElse, orElseGet is better because it avoids to evaluate >>> Thread.currentThread().getClass() if not necessary. >>> >>> So the example should be: >>> walk(s -> s.map(StackFrame::getDeclaringClass) >>> .findFirst()).orElseGet(() -> Thread.currentThread().getClass()); >>> >> >> This would return Util.class instead of Foo.class >> >>> In the second example, the field walker should be declared 'final?. >> >> Sure. Fixed. >> >>> And as i said earlier, the signature of walk() is: >>> T walk(Function, ? extends T> function, IntUnaryOperator batchSizeMapper) >>> >> >> I was pondering it and that?s why not changed in the last update. I agree with the upper bounded wildcard "? extends T? for the return type of the function. >> >> But for the function?s input argument, can you help me understand why it should take "? super Stream?? Is it useful to have function accepting supertype of Stream rather than Stream? VM should be the only source producing this StackFrame stream. >> >> On the other hand, I wonder if the stream argument should be Stream that may allow future implementation change. >> >> T walk(Function, ? extends T> function, ?) >> >> Mandy > > From paul.sandoz at oracle.com Mon Nov 2 12:44:24 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 Nov 2015 13:44:24 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5637566A.3000203@oracle.com> References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> Message-ID: <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> I agree with Maurizio, the first signature is good enough. One could argue that it might be better to apply PECS since it would encourage more consistent usage when it is actually required as all too often it?s easy to forget, and then too late to change. However, i don?t want to encourage the use of BaseStream since it was an unfortunate mistake that this made public. Paul. > On 2 Nov 2015, at 13:26, Maurizio Cimadamore wrote: > > So, we have three potential signatures here: > > T walk(Function, T> function) //1 > > T walk(Function, ? extends T> function) //2 > > T walk(Function, R> function) //3 > > > Under normal conditions (i.e. lambda parameter being passed to 'walk') I think all these signatures are fundamentally equivalent; (2) and (3) seem to have been designed for something like this: > > Number n = walk(s -> new Integer(1)); > > That is, the function returns something that is more specific w.r.t. what is expected in the return type of walk. But - in reality, if 'walk' returns an R that is a subtype of T (as in the third signature), then walk also returns a T (as R is a subtype of T), so the result value can be passed where a T is expected. > > The converse example: > > Integer n1 = walk(s -> (Number)null); > > Similarly fails on all three signatures. > > > More generally, with all such signatures, T will always receive: > > * lower bound(s) (from the return value(s) of the lambda passed as a parameter to the 'walk' method) > * one upper bound (from the target-type associated with the 'walk' call. > > Under such conditions, the upper bound will always be disregarded in favor of the lower bounds - meaning that instantiation of T will always be driven by what's inside the lambda. Signature (3) mentions different variables (R and T) but the end result is the same - as the bound says R extends T - meaning that lower bounds of R are propagated to T - leading to exactly the same situation. > > > In other words, I don't think there are obvious examples in which the behavior of these three signatures will be significantly different - if the return type of 'walk' would have been a generic type such as List, the situation would have been completely different - with with a 'naked' T, I think the first signature is good enough, and the third is, in my opinion, making things harder than what they need to be. > > I think the second signature is not necessary, from a pure type-system perspective; but I guess one could make an argument for it, but purely in terms of consistency with other areas (after all, the second type-parameter of a Function is in a covariant position). > > I hope this helps. > > Maurizio > From david.lloyd at redhat.com Mon Nov 2 12:46:16 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 2 Nov 2015 06:46:16 -0600 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5779E088-D59B-427F-83E9-3EB160386CD7@oracle.com> References: <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> <5633F14B.4080503@redhat.com> <5779E088-D59B-427F-83E9-3EB160386CD7@oracle.com> Message-ID: <56375B18.1010800@redhat.com> On 10/30/2015 11:24 PM, Mandy Chung wrote: >On Oct 30, 2015, at 3:38 PM, David M. Lloyd wrote: >> (that's what I was looking for before), or maybe even ToIntFunction where X is something that might inform the next batch size based on the work that has already been done - maybe even a Stream that consists only of the current batch? >> >> Or another idea: >> T walk(BiFunction, IntConsumer, T> function); >> >> where the IntConsumer can be called at any time to update a minimum number of remaining frames needed, which in turn can (with the knowledge of how many elements have been consumed by the stream) inform the next batch size. > > The stack walker won?t get the next batch until all frames of the current batch are consumed. I think the current walk methods would cover what this one does. There are other ideas to add other variants of the walk methods and short-cut for performance. I keep these ideas in mind and consider them once more feedback is collected. I think there are two problems with the current approach: 1. The function for getting the next batch size is not coupled to the function actually doing the work. I think it is just as likely (if not more so) that any information about the optimum number of frames to be gathered per batch can only be sensibly determined as a result of the current work being done. In this case, you'd have to do something odd like use a captured shared AtomicInteger or similar to pass information back and forth, which is not good. 2. The fact that frames are acquired in batches is an implementation detail. I do not believe it's a reasonable expectation of a user to know the optimum batch size; the API should not be exposing implementation details like this. On the other hand, the user might be reasonably expected to be able to inform the stack walker as to how many more frames are expected to be needed. The stack walker could easily use this information, even if it fetches in batches, by keeping a "remainingNeeded" counter of number of remaining frames expected to be used, which is decremented each time the stream returns an item, and read when a new batch is needed: it could (for example) use Math.min(10, remainingNeeded). -- - DML From david.lloyd at redhat.com Mon Nov 2 12:50:59 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 2 Nov 2015 06:50:59 -0600 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> Message-ID: <56375C33.3000106@redhat.com> I also agree - when an object type "passes through" a method, it's usually best to use an invariant type variable. On 11/02/2015 06:44 AM, Paul Sandoz wrote: > I agree with Maurizio, the first signature is good enough. > > One could argue that it might be better to apply PECS since it would encourage more consistent usage when it is actually required as all too often it?s easy to forget, and then too late to change. However, i don?t want to encourage the use of BaseStream since it was an unfortunate mistake that this made public. > > Paul. > >> On 2 Nov 2015, at 13:26, Maurizio Cimadamore wrote: >> >> So, we have three potential signatures here: >> >> T walk(Function, T> function) //1 >> >> T walk(Function, ? extends T> function) //2 >> >> T walk(Function, R> function) //3 >> >> >> Under normal conditions (i.e. lambda parameter being passed to 'walk') I think all these signatures are fundamentally equivalent; (2) and (3) seem to have been designed for something like this: >> >> Number n = walk(s -> new Integer(1)); >> >> That is, the function returns something that is more specific w.r.t. what is expected in the return type of walk. But - in reality, if 'walk' returns an R that is a subtype of T (as in the third signature), then walk also returns a T (as R is a subtype of T), so the result value can be passed where a T is expected. >> >> The converse example: >> >> Integer n1 = walk(s -> (Number)null); >> >> Similarly fails on all three signatures. >> >> >> More generally, with all such signatures, T will always receive: >> >> * lower bound(s) (from the return value(s) of the lambda passed as a parameter to the 'walk' method) >> * one upper bound (from the target-type associated with the 'walk' call. >> >> Under such conditions, the upper bound will always be disregarded in favor of the lower bounds - meaning that instantiation of T will always be driven by what's inside the lambda. Signature (3) mentions different variables (R and T) but the end result is the same - as the bound says R extends T - meaning that lower bounds of R are propagated to T - leading to exactly the same situation. >> >> >> In other words, I don't think there are obvious examples in which the behavior of these three signatures will be significantly different - if the return type of 'walk' would have been a generic type such as List, the situation would have been completely different - with with a 'naked' T, I think the first signature is good enough, and the third is, in my opinion, making things harder than what they need to be. >> >> I think the second signature is not necessary, from a pure type-system perspective; but I guess one could make an argument for it, but purely in terms of consistency with other areas (after all, the second type-parameter of a Function is in a covariant position). >> >> I hope this helps. >> >> Maurizio >> -- - DML From artem.smotrakov at oracle.com Mon Nov 2 13:30:39 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 2 Nov 2015 16:30:39 +0300 Subject: [9] RFR: 8140649: imageFile should use delete[] with new[] Message-ID: <5637657F.1060108@oracle.com> Hello, Please review this small fix for jdk9/dev repo. It updates imageFile.cpp to use delete[] operator together with new[]. It also adds a check to ImageLocation::set_data(u1*) method to prevent a possible null-dereference. Bug: https://bugs.openjdk.java.net/browse/JDK-8140649 Webrev: http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/ Artem From jaroslav.bachorik at oracle.com Mon Nov 2 13:32:51 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 2 Nov 2015 14:32:51 +0100 Subject: RFR 6425769: jmx remote bind address In-Reply-To: <1446460682.10865.20.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> Message-ID: <56376603.5050902@oracle.com> Adding core libs. On 2.11.2015 11:38, Severin Gehwolf wrote: > Hi, > > Here is a patch addressing JDK-6425769. The issue is that the JMX agent > binds to the wildcard address by default, preventing users to use > system properties for JMX agents on multi-homed hosts. Given a host > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's > impossible to start two JMX agents binding to fixed ports but to > different network interfaces, 192.168.0.1:{9111,9112} and > 192.168.0.2:{9111,9112} say. > > The JDK would bind to all local interfaces by default. In the above > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second > Java process would get a "Connection refused" error because another > process has already been bound to the specified JMX/RMI port pairs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/ > > Testing done: > jdk_jmx and jdk_management tests all pass after this change (no > regressions). There is also a new JTREG test which fails prior this > change and passes after. Updates to the diagnostic command have been > tested manually. > > I understand that, if approved, the JDK and hotspot changes should get > pushed together? Hotspot changes are fairly trivial since it's only a > doc-update for the new JDK property in the relevant diagnostic command. > > Could someone please review and sponsor this change? Please let me know > if there are questions. > > Thanks, > Severin > From jason_mehrens at hotmail.com Mon Nov 2 14:42:53 2015 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 2 Nov 2015 14:42:53 +0000 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: Message-ID: Mandy, Thread.dumpStack should generate the stacktrace elements then capture System.err into a local var and lock it while writing the output. That would be compatible with what was done before. Jason ________________________________________ From: core-libs-dev on behalf of Mandy Chung Sent: Friday, October 30, 2015 2:04 PM To: core-libs-dev Subject: Proposed API for JEP 259: Stack-Walking API JEP 259: http://openjdk.java.net/jeps/259 Javadoc for the proposed StackWalker API: http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html A simple way to walk the stack: StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); walker.walk((s) -> s.filter(f -> interestingClasses.contains(f.getDeclaringClass())).findFirst()); The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be replaced with this StackWalker API. Any feedback on the proposed API is appreciated. Mandy P.S. webrev of the current implementation: http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ From james.laskey at oracle.com Mon Nov 2 14:59:18 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 2 Nov 2015 10:59:18 -0400 Subject: [9] RFR: 8140649: imageFile should use delete[] with new[] In-Reply-To: <5637657F.1060108@oracle.com> References: <5637657F.1060108@oracle.com> Message-ID: +1 > On Nov 2, 2015, at 9:30 AM, Artem Smotrakov wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates imageFile.cpp to use delete[] operator together with new[]. It also adds a check to ImageLocation::set_data(u1*) method to prevent a possible null-dereference. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140649 > Webrev: http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/ > > Artem From jaroslav.bachorik at oracle.com Mon Nov 2 15:54:03 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 2 Nov 2015 16:54:03 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <56377F17.4050006@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> Message-ID: <5637871B.30705@oracle.com> Hi, On 2.11.2015 16:19, Daniel Fuchs wrote: > Hi Severin, > > Adding serviceability-dev at openjdk.java.net into the loop - that's > a better alias than hotspot-dev for this kind of changes - maybe > someone from serviceability-dev will offer to sponsor :-) > > I will let serviceability team members comment on the hotspot changes. > > ConnectorBootstrap.java > > I have one suggestion and one concern: > > Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) and > ssf (Server Socket Factory) variables rather than introduce the two > new variables rmiServerSocketFactory and rmiClientSocketFactory. > You might want to create a new boolean 'useSocketFactory' variable, > if that makes the code more readable. > > Concern: If I understand correctly how RMI socket factories work, > the client socket factory will be serialized and sent to the client > side. This is problematic for interoperability, as the class may not > present in the remote client - if the remote client is e.g. jdk 8. > > As far as I can see, your new DefaultClientSocketFactory doesn't do > anything useful - so I would suggest to simply get rid of it, and only > set the Server Socket Factory when SSL is not involved. > > Tests: > > Concerning the tests - we're trying to get rid of shell scripts > rather than introducing new ones :-) > Could the test be rewritten in pure java using the Process API? > > I believe there's even a test library that will let you do that > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > (see ProcessTools.java) > > Other: > > Also - I believe the new option should be documented in: > src/java.management/share/conf/management.properties I share Daniel's concerns. Also, the part of the changeset is related to javax.rmi.ssl - someone maintaining this library should also comment here. Also, the change is introducing new API (system property) and changing the existing one (adding SslRmiServerSocketFactory public constructors) so compatibility review process will have to be involved. -JB- > > best regards, > > -- daniel > > On 02/11/15 11:38, Severin Gehwolf wrote: > > Hi, > > > > Here is a patch addressing JDK-6425769. The issue is that the JMX agent > > binds to the wildcard address by default, preventing users to use > > system properties for JMX agents on multi-homed hosts. Given a host > > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's > > impossible to start two JMX agents binding to fixed ports but to > > different network interfaces, 192.168.0.1:{9111,9112} and > > 192.168.0.2:{9111,9112} say. > > > > The JDK would bind to all local interfaces by default. In the above > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the second > > Java process would get a "Connection refused" error because another > > process has already been bound to the specified JMX/RMI port pairs. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/00/ > > > > Testing done: > > jdk_jmx and jdk_management tests all pass after this change (no > > regressions). There is also a new JTREG test which fails prior this > > change and passes after. Updates to the diagnostic command have been > > tested manually. > > > > I understand that, if approved, the JDK and hotspot changes should get > > pushed together? Hotspot changes are fairly trivial since it's only a > > doc-update for the new JDK property in the relevant diagnostic command. > > > > Could someone please review and sponsor this change? Please let me know > > if there are questions. > > > > Thanks, > > Severin > > > From lance.andersen at oracle.com Mon Nov 2 17:37:48 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 2 Nov 2015 12:37:48 -0500 Subject: RFR 8136496 Connection.begin/endRequest Message-ID: <43937D2E-621B-4F5C-A323-0C7BE525AA64@oracle.com> Hi, Need a reviewer for 8136496. The CCC has been approved. The webrev can be found at http://cr.openjdk.java.net/~lancea/8136496/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Mon Nov 2 17:51:09 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 Nov 2015 09:51:09 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> References: <5633CC1E.1030603@redhat.com> <990258669.2446021.1446236810570.JavaMail.zimbra@u-pem.fr> <1440520184.2546899.1446314771503.JavaMail.zimbra@u-pem.fr> <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> Message-ID: Thanks for the feedback, Paul and Maurizio, that?s very helpful. I slightly opt for consistency with other areas and go with #2. Mandy > On Nov 2, 2015, at 4:44 AM, Paul Sandoz wrote: > > I agree with Maurizio, the first signature is good enough. > > One could argue that it might be better to apply PECS since it would encourage more consistent usage when it is actually required as all too often it?s easy to forget, and then too late to change. However, i don?t want to encourage the use of BaseStream since it was an unfortunate mistake that this made public. > > Paul. > >> On 2 Nov 2015, at 13:26, Maurizio Cimadamore wrote: >> >> So, we have three potential signatures here: >> >> T walk(Function, T> function) //1 >> >> T walk(Function, ? extends T> function) //2 >> >> T walk(Function, R> function) //3 >> >> >> Under normal conditions (i.e. lambda parameter being passed to 'walk') I think all these signatures are fundamentally equivalent; (2) and (3) seem to have been designed for something like this: >> >> Number n = walk(s -> new Integer(1)); >> >> That is, the function returns something that is more specific w.r.t. what is expected in the return type of walk. But - in reality, if 'walk' returns an R that is a subtype of T (as in the third signature), then walk also returns a T (as R is a subtype of T), so the result value can be passed where a T is expected. >> >> The converse example: >> >> Integer n1 = walk(s -> (Number)null); >> >> Similarly fails on all three signatures. >> >> >> More generally, with all such signatures, T will always receive: >> >> * lower bound(s) (from the return value(s) of the lambda passed as a parameter to the 'walk' method) >> * one upper bound (from the target-type associated with the 'walk' call. >> >> Under such conditions, the upper bound will always be disregarded in favor of the lower bounds - meaning that instantiation of T will always be driven by what's inside the lambda. Signature (3) mentions different variables (R and T) but the end result is the same - as the bound says R extends T - meaning that lower bounds of R are propagated to T - leading to exactly the same situation. >> >> >> In other words, I don't think there are obvious examples in which the behavior of these three signatures will be significantly different - if the return type of 'walk' would have been a generic type such as List, the situation would have been completely different - with with a 'naked' T, I think the first signature is good enough, and the third is, in my opinion, making things harder than what they need to be. >> >> I think the second signature is not necessary, from a pure type-system perspective; but I guess one could make an argument for it, but purely in terms of consistency with other areas (after all, the second type-parameter of a Function is in a covariant position). >> >> I hope this helps. >> >> Maurizio >> From mandy.chung at oracle.com Mon Nov 2 17:59:17 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 Nov 2015 09:59:17 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <0a160afad2984d24b14619505281889f@mane.sumatrasoftware.com> References: <0a160afad2984d24b14619505281889f@mane.sumatrasoftware.com> Message-ID: > On Oct 31, 2015, at 11:05 PM, Jeroen Frijters wrote: > > Hi Mandy, > > I like the API shape and this capability is very much needed. Thanks! > > It does bring something related to mind and that is that the current Java ecosystem is already very dependent on accurate stack frames (i.e. not removing them when inlining) and with this API this will probably only become worse. So it might be worth considering making this a hard spec requirement. > How does it make it worse? Would such a hard requirement prohibit any future optimization/performance improvement? Mandy > Regards, > Jeroen > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >> Behalf Of Mandy Chung >> Sent: Friday, October 30, 2015 20:05 >> To: core-libs-dev >> Subject: Proposed API for JEP 259: Stack-Walking API >> >> JEP 259: http://openjdk.java.net/jeps/259 >> >> Javadoc for the proposed StackWalker API: >> >> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker >> .html >> >> A simple way to walk the stack: >> >> StackWalker walker = new >> StackWalker(StackWalker.Option.CLASS_REFERENCE); >> walker.walk((s) -> s.filter(f -> >> interestingClasses.contains(f.getDeclaringClass())).findFirst()); >> >> The current usage of sun.reflect.Reflection.getCallerClass(int depth) >> can be replaced with this StackWalker API. >> >> Any feedback on the proposed API is appreciated. >> >> Mandy >> >> P.S. webrev of the current implementation: >> http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ >> >> >> >> >> >> > From sgehwolf at redhat.com Mon Nov 2 18:06:55 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Nov 2015 19:06:55 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <5637871B.30705@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> Message-ID: <1446487615.10865.57.camel@redhat.com> Hi, Thanks Jaroslav and Daniel for the reviews! Comments inline. On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > Hi, > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > Hi Severin, > > > > Adding serviceability-dev at openjdk.java.net into the loop - that's > > a better alias than hotspot-dev for this kind of changes - maybe > > someone from serviceability-dev will offer to sponsor :-) > > > > I will let serviceability team members comment on the hotspot > > changes. > > > > ConnectorBootstrap.java > > > > I have one suggestion and one concern: > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) > > and > > ssf??(Server Socket Factory) variables rather than introduce the > > two > > new variables rmiServerSocketFactory and rmiClientSocketFactory. > > You might want to create a new boolean 'useSocketFactory' variable, > > if that makes the code more readable. > > > > Concern: If I understand correctly how RMI socket factories work, > > the client socket factory will be serialized and sent to the client > > side. This is problematic for interoperability, as the class may > > not > > present in the remote client - if the remote client is e.g. jdk 8. > > > > As far as I can see, your new DefaultClientSocketFactory doesn't do > > anything useful - so I would suggest to simply get rid of it, and > > only > > set the Server Socket Factory when SSL is not involved. Thanks. Fixed in updated webrev. > > Tests: > > > > Concerning the tests - we're trying to get rid of shell scripts > > rather than introducing new ones :-) > > Could the test be rewritten in pure java using the Process API? > > > > I believe there's even a test library that will let you do that > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > (see ProcessTools.java) It'll take me a bit to rewrite the test in pure Java, but should be fine. This is not yet fixed in the updated webrev. > > Other: > > > > Also - I believe the new option should be documented in: > > src/java.management/share/conf/management.properties Docs have been updated in?src/java.management/share/conf/management.properties. > I share Daniel's concerns. Also, the part of the changeset is related > to javax.rmi.ssl - someone maintaining this library should also > comment here. > > Also, the change is introducing new API (system property) and > changing the existing one (adding SslRmiServerSocketFactory public > constructors) so compatibility review process will have to be > involved. OK. What exactly is there for me to do? I'm not familiar with this process. Note that the intent would be to get this backported to JDK 8. New webrev at: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ Thanks, Severin > -JB- > > > > best regards, > > > > -- daniel > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > Hi, > > > > > > Here is a patch addressing JDK-6425769. The issue is that the JMX > > > agent > > > binds to the wildcard address by default, preventing users to use > > > system properties for JMX agents on multi-homed hosts. Given a > > > host > > > with local network interfaces, 192.168.0.1 and 192.168.0.2 say, > > > it's > > > impossible to start two JMX agents binding to fixed ports but to > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > 192.168.0.2:{9111,9112} say. > > > > > > The JDK would bind to all local interfaces by default. In the > > > above > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that the > > > second > > > Java process would get a "Connection refused" error because > > > another > > > process has already been bound to the specified JMX/RMI port > > > pairs. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > > > 00/ > > > > > > Testing done: > > > jdk_jmx and jdk_management tests all pass after this change (no > > > regressions). There is also a new JTREG test which fails prior > > > this > > > change and passes after. Updates to the diagnostic command have > > > been > > > tested manually. > > > > > > I understand that, if approved, the JDK and hotspot changes > > > should get > > > pushed together? Hotspot changes are fairly trivial since it's > > > only a > > > doc-update for the new JDK property in the relevant diagnostic > > > command. > > > > > > Could someone please review and sponsor this change? Please let > > > me know > > > if there are questions. > > > > > > Thanks, > > > Severin > > > > > > From ioi.lam at oracle.com Mon Nov 2 18:36:28 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 02 Nov 2015 10:36:28 -0800 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5633C89E.5050503@oracle.com> References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com> Message-ID: <5637AD2C.5010001@oracle.com> On 10/30/15 12:44 PM, Coleen Phillimore wrote: > > Hi Ioi, > This is a manageable code change. > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html > > You forward declare Klass* but don't use it in this header file. > Also can you add a comment to #endif to say what it's endifing. ie. > // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP > Fixed. I also changed ClassListParser to a StackObj as you suggested in another e-mail to me. > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html > 33 TempNewSymbol class_name_symbol = SymbolTable::new_permanent_symbol(parser->current_class_name(), THREAD); > This doesn't make sense. If you want a permanent symbol, it doesn't > need to get un-reference counted with the TempNewSymbol destructor. I changed it to TempNewSymbol class_name_symbol = SymbolTable::new_symbol(parser->current_class_name(), THREAD); > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html > > + // Make sure we have an entry in the SystemDictionary on success I will actually remove this block of code in the next update to make things simpler. > This assert code is a copy of some code elsewhere. Can you make it a > function that they boh can call? > Can you also comment the raw #endif's to what they're endifing? > Will do. Thanks > Otherwise, this looks okay. > > Coleen > > > On 10/30/15 1:00 PM, Ioi Lam wrote: >> Please review the following fix: >> >> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ >> >> Bug: Clean up and refactor of class loading code for CDS >> >> https://bugs.openjdk.java.net/browse/JDK-8140802 >> >> Summary of fix: >> >> We need to clean up and refactor the class loading code in order >> to support CDS in JDK9 >> >> [1] Remove code that has been made obsolete by the module changes >> (such as supporting code used for meta-index file) >> [2] Add new whitebox API to be used by CDS-related tests. >> [3] Refactor the parsing of classlist files for future enhancements. >> [4] Add new APIs in the class loading code to support Oracle CDS >> enhancements. >> >> Tests: >> >> JPRT >> RBT - with same set of tests as hs-rt nightly >> >> Thanks >> - Ioi > From ioi.lam at oracle.com Mon Nov 2 18:50:38 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 02 Nov 2015 10:50:38 -0800 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <2DAFD29D-4F30-441E-934F-610F6D0A2C2E@oracle.com> References: <5633A24A.9070800@oracle.com> <2DAFD29D-4F30-441E-934F-610F6D0A2C2E@oracle.com> Message-ID: <5637B07E.4090509@oracle.com> On 10/30/15 1:23 PM, Jiangli Zhou wrote: > Hi Ioi, > > The change looks pretty clean. The new src/share/vm/classfile/systemDictionary_ext.hpp and src/share/vm/classfile/vmSymbols_ext.hpp do not have copyright header. Please add the copyright headers. Please also fix the copyright year for the modified files prior to pushing. I added the missing heads and fixed the copyright year for all modified files. > In src/share/vm/classfile/sharedPathsMiscInfo.hpp, is the new ?#include ?classify/classLoader.hpp? necessary? Yes, it's necessary for this part of the file static void trace_class_path(const char* msg, const char* name = NULL) { ClassLoader::trace_class_path(msg, name); } I am not sure why it wasn't detected by the C compiler before, but I did have a build failure when building without precompiled headers. Thanks - Ioi > I agree with the comments from Colleen and Karen regarding the usage of new_permanent_symbol() and TempNewSymbol in classLoaderExt.cpp. It doesn?t seem to be consistent. > > Thanks, > Jiangli > >> On Oct 30, 2015, at 10:00 AM, Ioi Lam wrote: >> >> Please review the following fix: >> >> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ >> >> Bug: Clean up and refactor of class loading code for CDS >> >> https://bugs.openjdk.java.net/browse/JDK-8140802 >> >> Summary of fix: >> >> We need to clean up and refactor the class loading code in order >> to support CDS in JDK9 >> >> [1] Remove code that has been made obsolete by the module changes >> (such as supporting code used for meta-index file) >> [2] Add new whitebox API to be used by CDS-related tests. >> [3] Refactor the parsing of classlist files for future enhancements. >> [4] Add new APIs in the class loading code to support Oracle CDS enhancements. >> >> Tests: >> >> JPRT >> RBT - with same set of tests as hs-rt nightly >> >> Thanks >> - Ioi From ioi.lam at oracle.com Mon Nov 2 18:57:43 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 02 Nov 2015 10:57:43 -0800 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5633D3A2.6050809@oracle.com> References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com> <5633D3A2.6050809@oracle.com> Message-ID: <5637B227.4050905@oracle.com> On 10/30/15 1:31 PM, Coleen Phillimore wrote: > > > On 10/30/15 4:18 PM, Karen Kinnear wrote: >> Coleen, >> >> Question for you below please ... >>> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore >>> wrote: >>> >>> >>> Hi Ioi, >>> This is a manageable code change. >>> >>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html >>> >>> >>> You forward declare Klass* but don't use it in this header file. >>> Also can you add a comment to #endif to say what it's endifing. ie. >>> // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP >>> >>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html >>> >>> >>> 33 TempNewSymbol class_name_symbol = >>> SymbolTable::new_permanent_symbol(parser->current_class_name(), >>> THREAD); >>> >>> This doesn't make sense. If you want a permanent symbol, it >>> doesn't need to get un-reference counted with the TempNewSymbol >>> destructor. >> Thank you for chiming in on this one - I wanted your opinion here. >> (this code used to be in MetaspaceShared:: >> preload_and_dump and I think was wrong there as well). >> My understanding is that it is a TempNewSymbol that he wants, so he >> should call SymbolTable::new_symbol. >> The code creates a (temporary) symbol for the name, and then calls >> SystemDictionary::resolve_or_null, which if it >> succeeds will walk through the classFileParser which will create a >> permanent symbol for the class name, >> via the symbol_alloc_batch handling. That would be consistent with >> the TempNewSymbol call in >> SystemDictionary::resolve_or_null as well as in parse_stream - all >> places dealing with the class name >> before doing classfile parsing. >> >> Does that make sense? > > Yes, this makes sense. The symbol shouldn't be permanent. Ioi can > test this by putting a strange long name in the classlist file and > make sure it doesn't make it out to the shared archive, since I think > -Xshare:dump cleans out the SymbolTable before dumping. > After changing to use new_symbol instead of new_permanent_symbol, I ran -Xshare:dump: $ java -Xshare:dump Preload Warning: Cannot find sun/text/normalizer/UnicodeMatcher ... total : 13063134 [100.0% of total] out of 27385856 bytes [47.7% used] $ strings images/jdk/lib/i386/hotspot/classes.jsa | grep sun/text/normalizer/UnicodeMatcher sun/text/normalizer/UnicodeMatcher So the unused symbols are not removed. Anyway, I have filed a separate issue for this: https://bugs.openjdk.java.net/browse/JDK-8141207 Thanks - Ioi > Coleen >> >> thanks, >> Karen >> >>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>> >>> >>> + // Make sure we have an entry in the SystemDictionary on success >>> >>> >>> This assert code is a copy of some code elsewhere. Can you make it >>> a function that they boh can call? >>> Can you also comment the raw #endif's to what they're endifing? >>> >>> Otherwise, this looks okay. >>> >>> Coleen >>> >>> >>> On 10/30/15 1:00 PM, Ioi Lam wrote: >>>> Please review the following fix: >>>> >>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ >>>> >>>> Bug: Clean up and refactor of class loading code for CDS >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8140802 >>>> >>>> Summary of fix: >>>> >>>> We need to clean up and refactor the class loading code in order >>>> to support CDS in JDK9 >>>> >>>> [1] Remove code that has been made obsolete by the module changes >>>> (such as supporting code used for meta-index file) >>>> [2] Add new whitebox API to be used by CDS-related tests. >>>> [3] Refactor the parsing of classlist files for future >>>> enhancements. >>>> [4] Add new APIs in the class loading code to support Oracle >>>> CDS enhancements. >>>> >>>> Tests: >>>> >>>> JPRT >>>> RBT - with same set of tests as hs-rt nightly >>>> >>>> Thanks >>>> - Ioi > From coleen.phillimore at oracle.com Mon Nov 2 19:01:15 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Nov 2015 14:01:15 -0500 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5637B227.4050905@oracle.com> References: <5633A24A.9070800@oracle.com> <5633C89E.5050503@oracle.com> <5633D3A2.6050809@oracle.com> <5637B227.4050905@oracle.com> Message-ID: <5637B2FB.9080301@oracle.com> On 11/2/15 1:57 PM, Ioi Lam wrote: > > > On 10/30/15 1:31 PM, Coleen Phillimore wrote: >> >> >> On 10/30/15 4:18 PM, Karen Kinnear wrote: >>> Coleen, >>> >>> Question for you below please ... >>>> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore >>>> wrote: >>>> >>>> >>>> Hi Ioi, >>>> This is a manageable code change. >>>> >>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html >>>> >>>> >>>> You forward declare Klass* but don't use it in this header file. >>>> Also can you add a comment to #endif to say what it's endifing. >>>> ie. // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP >>>> >>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html >>>> >>>> >>>> 33 TempNewSymbol class_name_symbol = >>>> SymbolTable::new_permanent_symbol(parser->current_class_name(), >>>> THREAD); >>>> >>>> This doesn't make sense. If you want a permanent symbol, it >>>> doesn't need to get un-reference counted with the TempNewSymbol >>>> destructor. >>> Thank you for chiming in on this one - I wanted your opinion here. >>> (this code used to be in MetaspaceShared:: >>> preload_and_dump and I think was wrong there as well). >>> My understanding is that it is a TempNewSymbol that he wants, so he >>> should call SymbolTable::new_symbol. >>> The code creates a (temporary) symbol for the name, and then calls >>> SystemDictionary::resolve_or_null, which if it >>> succeeds will walk through the classFileParser which will create a >>> permanent symbol for the class name, >>> via the symbol_alloc_batch handling. That would be consistent with >>> the TempNewSymbol call in >>> SystemDictionary::resolve_or_null as well as in parse_stream - all >>> places dealing with the class name >>> before doing classfile parsing. >>> >>> Does that make sense? >> >> Yes, this makes sense. The symbol shouldn't be permanent. Ioi can >> test this by putting a strange long name in the classlist file and >> make sure it doesn't make it out to the shared archive, since I think >> -Xshare:dump cleans out the SymbolTable before dumping. >> > After changing to use new_symbol instead of new_permanent_symbol, I > ran -Xshare:dump: > > $ java -Xshare:dump > Preload Warning: Cannot find sun/text/normalizer/UnicodeMatcher > ... > total : 13063134 [100.0% of total] out of 27385856 bytes [47.7% used] > > $ strings images/jdk/lib/i386/hotspot/classes.jsa | grep > sun/text/normalizer/UnicodeMatcher > sun/text/normalizer/UnicodeMatcher > > So the unused symbols are not removed. Anyway, I have filed a separate > issue for this: https://bugs.openjdk.java.net/browse/JDK-8141207 I just realized that the reason that it doesn't clean out unused symbols is that it would leave gaps in the Metaspace memory where they're stored, so there wouldn't be much point. Coleen > > Thanks > - Ioi > > >> Coleen >>> >>> thanks, >>> Karen >>> >>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html >>>> >>>> >>>> + // Make sure we have an entry in the SystemDictionary on success >>>> >>>> >>>> This assert code is a copy of some code elsewhere. Can you make it >>>> a function that they boh can call? >>>> Can you also comment the raw #endif's to what they're endifing? >>>> >>>> Otherwise, this looks okay. >>>> >>>> Coleen >>>> >>>> >>>> On 10/30/15 1:00 PM, Ioi Lam wrote: >>>>> Please review the following fix: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ >>>>> >>>>> Bug: Clean up and refactor of class loading code for CDS >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8140802 >>>>> >>>>> Summary of fix: >>>>> >>>>> We need to clean up and refactor the class loading code in order >>>>> to support CDS in JDK9 >>>>> >>>>> [1] Remove code that has been made obsolete by the module changes >>>>> (such as supporting code used for meta-index file) >>>>> [2] Add new whitebox API to be used by CDS-related tests. >>>>> [3] Refactor the parsing of classlist files for future >>>>> enhancements. >>>>> [4] Add new APIs in the class loading code to support Oracle >>>>> CDS enhancements. >>>>> >>>>> Tests: >>>>> >>>>> JPRT >>>>> RBT - with same set of tests as hs-rt nightly >>>>> >>>>> Thanks >>>>> - Ioi >> > From mandy.chung at oracle.com Mon Nov 2 19:53:05 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 Nov 2015 11:53:05 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <562687C8.1040106@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> Message-ID: <173536F2-C957-4454-97A6-F49FEBD2B156@oracle.com> > On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote: > > Updated Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ I?m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: 1. For an existing finalizer (say cleanup function), it will be replaced with Cleaner.create().phantomCleanable(this, this::cleanup); It may be useful to provide a sharable Cleaner instance that doesn?t go away. The primary use for this Cleaner API is to replace finalizers. I wonder it worths having a convenient method easier to relate to finalizer (say Cleaner.finalizable?) 2. Do you know any existing use of soft / weak references in the JDK can benefit from this automatic cleanup mechanism? The typical cache implementation using soft/weak references is to purge the entries when the cache is accessed and manages the reference queue without a background thread. I?m in two minds that it sounds sensible for this Cleaner API to extend for soft/weak references whereas I am not certain of the use cases. Anyone can share the known use cases that would be helpful. > > Updated Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ 57 final PhantomCleanable phantomCleanableList; 59 final WeakCleanable weakCleanableList; 61 final SoftCleanable softCleanableList; - is there any benefit of keeping separate list for each reference type? Each cleaner has one single ReferenceRueue and it seems that keeping one single Cleanable list could achieve similar performance in most cases while the implementation might be simplified. 111 thread.setPriority(Thread.MAX_PRIORITY); VM threads are near max priority. The reference handler thread is MAX_PRORITY whereas the finalizer thread is MAX_PRIORITY-2. I think the cleaner thread should not be of MAX_PRIORITY and also perhaps the caller may need a way to get the thread associated with a Cleaner so that users can set the priority if needed? Mandy From mandy.chung at oracle.com Tue Nov 3 03:38:45 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 Nov 2015 19:38:45 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: Message-ID: <415ADCA4-E15A-43B8-AD7C-2D79C5579F21@oracle.com> > On Nov 2, 2015, at 6:42 AM, Jason Mehrens wrote: > > Mandy, > > Thread.dumpStack should generate the stacktrace elements then capture System.err into a local var and lock it while writing the output. That would be compatible with what was done before. > Good catch. Will fix that. Thread.dumpStack can be further improved to avoid constructing StackTraceElement (that?s something for the future). Mandy > Jason > > ________________________________________ > From: core-libs-dev on behalf of Mandy Chung > Sent: Friday, October 30, 2015 2:04 PM > To: core-libs-dev > Subject: Proposed API for JEP 259: Stack-Walking API > > JEP 259: http://openjdk.java.net/jeps/259 > > Javadoc for the proposed StackWalker API: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > A simple way to walk the stack: > > StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); > walker.walk((s) -> s.filter(f -> interestingClasses.contains(f.getDeclaringClass())).findFirst()); > > The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be replaced with this StackWalker API. > > Any feedback on the proposed API is appreciated. > > Mandy > > P.S. webrev of the current implementation: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ > > > > > > > From ioi.lam at oracle.com Tue Nov 3 03:40:56 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 02 Nov 2015 19:40:56 -0800 Subject: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS In-Reply-To: <5633A24A.9070800@oracle.com> References: <5633A24A.9070800@oracle.com> Message-ID: <56382CC8.9070008@oracle.com> Hi, I have updated the webrev to include all the feedback from the past few days: Delta from the previous webrev http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/ Full changes http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02/ Change Log: + Various formatting and copyright + Change in SystemDictionary::resolve_from_stream to support new requirement in closed sources. Thanks Ioi On 10/30/15 10:00 AM, Ioi Lam wrote: > Please review the following fix: > > http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/ > > Bug: Clean up and refactor of class loading code for CDS > > https://bugs.openjdk.java.net/browse/JDK-8140802 > > Summary of fix: > > We need to clean up and refactor the class loading code in order > to support CDS in JDK9 > > [1] Remove code that has been made obsolete by the module changes > (such as supporting code used for meta-index file) > [2] Add new whitebox API to be used by CDS-related tests. > [3] Refactor the parsing of classlist files for future enhancements. > [4] Add new APIs in the class loading code to support Oracle CDS > enhancements. > > Tests: > > JPRT > RBT - with same set of tests as hs-rt nightly > > Thanks > - Ioi From magnus.ihse.bursie at oracle.com Tue Nov 3 10:29:22 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 Nov 2015 11:29:22 +0100 Subject: RFR: JDK-6512052 remove java-rmi.exe and java-rmi.cgi Message-ID: <56388C82.5010404@oracle.com> Here's an old bug from the Good Riddance Dept. The TLDR; version: The java-rmi launcher is broken and irrelevant, at the same time. And has been since JDK6 or so. Bug: https://bugs.openjdk.java.net/browse/JDK-6512052 WebRev: http://cr.openjdk.java.net/~ihse/JDK-6512052-remove-java-rmi-launcher/webrev.01 /Magnus From paul.sandoz at oracle.com Tue Nov 3 11:28:53 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 12:28:53 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: Message-ID: <84FCE25A-8EB4-48C8-8F3E-D0BDFBF3D86D@oracle.com> Hi Mandy, This is very nice work. Comments below, mostly minor stuff. PlatformLogger.java (and similar comments for duplicated code in LogRecord.java) ? 542 static final StackWalker stackWalker; Use capitals for static variable. 556 private boolean lookingForLogger = true; 557 /** Missing line-feed. 588 private String getCallerInfo() { 589 Optional frame = new CallerFinder().get(); 590 if (frame.isPresent()) { 591 StackWalker.StackFrame f = frame.get(); 592 return f.getClassName() + " " + f.getMethodName(); 593 } else { 594 return name; 595 } 596 } Consider using: return frame.map(f -> f.getClassName() + " " + f.getMethodName()).orElse(name); You might want to highlight that CallerFinder is a stateful predicate. LogRecord.java ? 642 // Skip all frames until we have found the first logger frame. 643 Optional frame = new CallerFinder().get(); 644 if (frame.isPresent()) { 645 StackWalker.StackFrame f = frame.get(); 646 setSourceClassName(f.getClassName()); 647 setSourceMethodName(f.getMethodName()); 648 } 649 // We haven't found a suitable frame, so just punt. This is 650 // OK as we are only committed to making a "best effort" here. 651 } Consider using: frame.ifPresent(f -> { setSourceClassName(f.getClassName()); setSourceMethodName(f.getMethodName()); }); LiveStackFrame ? 41 /** 42 * Return the monitors held by this stack frames. This method returns 43 * an empty array if no monitor is held by this stack frame. 44 * 45 * @return the monitors held by this stack frames 46 */ 47 public Object[] getMonitors(); s/this stack frames/stack frame Can the contents of the array be modified? 49 /** 50 * Gets the local variable array of this stack frame. 51 * 52 *

A single local variable can hold a value of type boolean, byte, char, 53 * short, int, float, reference or returnAddress. A pair of local varaibles 54 * can hold a value of type long or double. In other words, 55 * a value of type long or type double occupies two consecutive local 56 * variables. For a value of primitive type, the element in the 57 * local variable array is an {@link PrimitiveValue} object; 58 * otherwise, the element is an {@code Object}. 59 * 60 *

A value of type long or double will be represented by 61 * a {@code PrimitiveValue} object containing the value in the elements 62 * at index n and n+1 in the local variable array. 63 * 64 * @return the local variable array of this stack frame. 65 */ 66 public Object[] getLocals(); s/varaibles/variables (double slots are a PITA!) StackStream ? Suggest using something other than Stream in the name is this is really about Spliterator and traversal e.g. perhaps StackTraverser. Same for sub-types of StackStream. 494 @Override 495 public void forEachRemaining(Consumer action) { 496 throw new UnsupportedOperationException("Specialized StackWalker"); 497 } 498 499 @Override 500 public boolean tryAdvance(Consumer action) { 501 throw new UnsupportedOperationException("Specialized StackWalker"); 502 } Is this required? StackWalker ? 46 * The {@linkplain Stream#spliterator() spliterator} of the stream performs 47 * the stack frame traversal in an {@linkplain Spliterator#ORDERED ordered} manner. It?s probably best not to mention Spliterator. Suggest the stream reports stack frame elements in order, from the top most frame that represents the execution point at which the stack was generated to the bottom most frame... 64 *

Examples Use an @apiNote 82 public final class StackWalker { 83 /** 84 * A {@code StackFrame} object represent a method invocation returned by 85 * {@link StackWalker}. s/object represent/object represents 87 *

{@code StackFrame} objects returned by {@link StackWalker} may not implement 88 * the {@link #getDeclaringClass()} method 89 * depending on the requested {@linkplain Option stack walking options}. Rather than "may not implement? suggest something like: The getDeclaring class method may be unsupported as determined by the stack walking options of a stack walker. 118 * @throws UnsupportedOperationException if this {@code StackFrame} 119 * does not implement this method if this StackFrame does not support? as determined by ? 137 public String getFileName(); 138 /** Missing line-feed. 151 /** 152 * Returns true if the method containing the execution point 153 * represented by this stack frame is a native method. 154 * 155 * @return {@code true} if the method containing the execution point 156 * represented by this stack frame is a native method. 157 */ 158 public boolean isNativeMethod(); Consistently use {@code true} 160 /** 161 * Gets a {@code StackTraceElement} for this stack frame. 162 * 163 * @apiNote This method does not seem to be needed as user could simply 164 * use StackFrame methods directly. 165 * 166 * @return {@code StackTraceElement} for this stack frame. 167 * 168 * */ 169 public default StackTraceElement asStackTraceElement() { I guess that @apiNote is a TODO? Perhaps remove it if you think it is not needed, unless it is useful for compatibility reasons, it might be e.g. consider map(StackFrame::asStackTraceElement) 238 private final List options; Do you require the bound here? 241 /** 242 * Gets a {@code StackWalker} instance. 243 * 244 *

This {@code StackWalker} obtains the method name and the class name 245 * with all {@linkplain StackWalker.Option#SHOW_HIDDEN_FRAMES hidden frames} 246 * skipped. 247 */ 248 public StackWalker() { s/Gets/Creates Same for other constructor methods. 252 /** 253 * Gets a {@code StackWalker} instance with the given options specifying 254 * the stack frame information it can access. If no option is specified, this 255 * {@code StackWalker} obtains the method name and the class name 256 * with all {@linkplain StackWalker.Option#SHOW_HIDDEN_FRAMES hidden frames} 257 * skipped. If no options are given? It might be easier to state as if the options were {CLASS_REFERENCE, SHOW_REFLECT_FRAMES}, perhaps it depends if the default is someone under specified i.e. is it guaranteed that the option set will be the complement of the single set SHOW_HIDDEN_FRAMES? I guess any unrecognized options are ignored? 324 /** 325 * Applies the given function to the stream of {@code StackFrame}s 326 * for the current thread, traversing from the top of the stack, 327 * which is the method calling this method. 328 * 329 *

To find the first 10 calling frames, first skipping those frames whose 330 * declaring class belong to package {@code com.foo}: 331 *

332 * 
{@code List frames = new StackWalker().walk((s) ->}

} -> {

 333      *     s.dropWhile(f -> f.getClassName().startsWith("com.foo."))
 334      *      .limit(10)
 335      *      .collect(Collectors.toList()));
 336      *
337 * @apiNote The {@code Stream} object will be closed when 338 * this method returns. When a closed {@code Stream} object 339 * is reused, {@code IllegalStateException} will be thrown. Yay, dropWhile :-) Use an @apiNote for the example, the original note is i think normative. Probably need to mention that parallel execution will is effectively disabled and stream pipeline execution will only occur on the current thread. 402 @CallerSensitive 403 public T walk(Function, T> function, 404 Function batchSizeMapper) { Can you use IntUnaryOperator? 430 /** 431 * Gets the {@code Class} object of the caller invoking the method 432 * that calls this {@code getCallerClass} method. 433 * 434 *

This is equivalent to calling 435 *

436 * 
{@code walk((s) ->}

} -> {

 437      *     s.map(StackFrame::getDeclaringClass)
 438      *      .skip(2)
 439      *      .findFirst()).orElse(Thread.currentThread().getClass());
 440      *
441 * 442 *

For example, {@code Util::getResourceBundle} loads a resource bundle on behalf 443 * of the caller. It calls this {@code getCallerClass} method to find the method 444 * calling {@code Util::getResourceBundle} and use the caller's class loader to 445 * load the resource bundle. The caller class in this example is the {@code Foo} class. use @apiNote BatchSizeMapper ? As usual i always advice using testng and data providers, up to you. 105 return frameCount = stream 106 .map(f -> { 107 if (verbose) System.out.println(f); 108 return f; 109 }) You can use peek instead. GetCallerClassTest ? 105 class Test1 { 106 static void test() { 107 GetCallerClassTest.staticGetCallerClass(Test1.class); 108 GetCallerClassTest.reflectiveGetCallerClass(Test1.class); 109 } 110 } 111 112 class Test2 { 113 static void test() { 114 GetCallerClassTest.staticGetCallerClass(Test2.class); 115 GetCallerClassTest.reflectiveGetCallerClass(Test2.class); 116 } 117 } Duplicate tests? Suggest renaming tests because on failure it might easier to understand what failed. HiddenFrames ? 64 void walk() { 65 Arrays.stream(new int[]{0}) 66 .forEach(i -> walker.walk(s -> { 67 s.forEach(this::checkFrame); 68 return null; 69 })); Can you use Stream.of(0).forEach instead. Ran out of time :-) Paul. > On 30 Oct 2015, at 20:04, Mandy Chung wrote: > > JEP 259: http://openjdk.java.net/jeps/259 > > Javadoc for the proposed StackWalker API: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > A simple way to walk the stack: > > StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); > walker.walk((s) -> s.filter(f -> interestingClasses.contains(f.getDeclaringClass())).findFirst()); > > The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be replaced with this StackWalker API. > > Any feedback on the proposed API is appreciated. > > Mandy > > P.S. webrev of the current implementation: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ > > > > > > > From Alan.Bateman at oracle.com Tue Nov 3 11:32:33 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 11:32:33 +0000 Subject: RFR: JDK-6512052 remove java-rmi.exe and java-rmi.cgi In-Reply-To: <56388C82.5010404@oracle.com> References: <56388C82.5010404@oracle.com> Message-ID: <56389B51.2070804@oracle.com> On 03/11/2015 10:29, Magnus Ihse Bursie wrote: > Here's an old bug from the Good Riddance Dept. > > The TLDR; version: The java-rmi launcher is broken and irrelevant, at > the same time. And has been since JDK6 or so. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6512052 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-6512052-remove-java-rmi-launcher/webrev.01 I thought Stuart's alter ego had already removed this early in JDK 9, it seems not. The change looks good to me. -Alan From paul.sandoz at oracle.com Tue Nov 3 11:41:34 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 12:41:34 +0100 Subject: RFR 8136496 Connection.begin/endRequest In-Reply-To: <43937D2E-621B-4F5C-A323-0C7BE525AA64@oracle.com> References: <43937D2E-621B-4F5C-A323-0C7BE525AA64@oracle.com> Message-ID: <5F848E78-81B4-49A8-8F7B-1FCB19D14D52@oracle.com> > On 2 Nov 2015, at 18:37, Lance Andersen wrote: > > Hi, > > Need a reviewer for 8136496. The CCC has been approved. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8136496/webrev.00/ > Looks ok. Just a minor point: + * @implSpec + * The default implementation will be a no-op Suggest something like: The default implementation is a no-op or: The default implementation performs no action Paul. > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From peter.levart at gmail.com Tue Nov 3 12:45:42 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 3 Nov 2015 13:45:42 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: Message-ID: <5638AC76.4080603@gmail.com> Hi Mandy, Great API. One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: walk((s) -> s.map(StackFrame::getDeclaringClass) .skip(2) .findFirst()).orElse(Thread.currentThread().getClass()); ... the .orElse is presumably meant for the case when getCallerClass() is called directly from within Thread.run() method right? In that case Thread's implementation class is presented as the one doing the invocation of Thread.run(), which seems logical. But what about if getCallerClass() is called from a method that has been invoked from native code via JNI in a newly attached thread that was not started in Java (like the main method)? We will also get the Thread's implementation class as the caller. Is this still logical? What would it be if getCallerClass() returned just Optional> and was left to the user to decide what to do in corner cases when there is no Java caller? So returning java.lang.Class objects is safe now there is jigsaw to enforce isolation when doing reflection on them. It's great to see how things fall together nicely. Regards, Peter On 10/30/2015 08:04 PM, Mandy Chung wrote: > JEP 259:http://openjdk.java.net/jeps/259 > > Javadoc for the proposed StackWalker API: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html > > A simple way to walk the stack: > > StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); > walker.walk((s) -> s.filter(f -> interestingClasses.contains(f.getDeclaringClass())).findFirst()); > > The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be replaced with this StackWalker API. > > Any feedback on the proposed API is appreciated. > > Mandy > > P.S. webrev of the current implementation: > http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ > > > > > > > From paul.sandoz at oracle.com Tue Nov 3 12:58:46 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 13:58:46 +0100 Subject: RFR 9: 8138566: (Process) java.lang.Process.allChildren specification clarification In-Reply-To: <56340016.80701@oracle.com> References: <56340016.80701@oracle.com> Message-ID: <2F703D9C-5567-45AF-8AC2-8174CFBF03A0@oracle.com> > On 31 Oct 2015, at 00:41, Roger Riggs wrote: > > Please review and comment on 3 clarifications to ProcessHandle and Process. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ > > 8138566: (Process) java.lang.Process.allChildren specification clarification > - Rename the allChildren() method to descendants() - it is more descriptive and > less easily confused with the children method. > - The risk of renaming is method is minimal since it has been only available for a short time. > > 8140213: Process/ProcessHandle.onExit() spec need to be improved > - The timing of the completion of the CompletableFuture was too tightly specified. > With the isAlive method, it is possible to observe that the process has terminated > before the CF is completed. The CF is completed sometime after the process terminates. > > 8140250: (process) Process.info description is inaccurate > - The specification of the Process/ProcessHandle.info() method did not match > the implementation. On an OS (Windows) some information is available about > the process after it is no longer alive. > +1 Might be worth mentioning in a note that it may be observed that the process has terminated, via queries to isAlive, before the onExit CF has completed, but presumably never the other way around? (too weak for a happens-before relationship?). Paul. From paul.sandoz at oracle.com Tue Nov 3 13:19:55 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 14:19:55 +0100 Subject: RFR (XS): 8140683: Deduplicate Strings in UnixFileSystem canonical caches In-Reply-To: <5631299D.2050602@oracle.com> References: <5631299D.2050602@oracle.com> Message-ID: > On 28 Oct 2015, at 21:01, Claes Redestad wrote: > > Hi, > > while investigating startup and footprint for jigsaw, I found this unrelated oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate file paths determined to be equal when putting them into its internal cache. Also avoid some recalculation of paths determined to be canonical for no good reason and we're golden: > > webrev: http://cr.openjdk.java.net/~redestad/8140683/webrev.01 > bug: https://bugs.openjdk.java.net/browse/JDK-8140683 > I am not an expert in this area, but something does not feel right that you have modified things so the the key and value for a cache entry are the same. Why bother caching in that is the case? I am missing something obvious here? Paul. From daniel.fuchs at oracle.com Tue Nov 3 13:20:21 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 3 Nov 2015 14:20:21 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5638AC76.4080603@gmail.com> References: <5638AC76.4080603@gmail.com> Message-ID: <5638B495.5010004@oracle.com> Hi Peter, You also get Thread.currentThread().getClass() if you call StackWalker.getCallerClass() from main(). Because who is the caller of main()? cheers, -- daniel On 03/11/15 13:45, Peter Levart wrote: > Hi Mandy, > > Great API. > > One thing I noticed is method StackWalker.getCallerClass() which is > described as equivalent to the following: > > walk((s) -> s.map(StackFrame::getDeclaringClass) > .skip(2) > .findFirst()).orElse(Thread.currentThread().getClass()); > > ... the .orElse is presumably meant for the case when getCallerClass() > is called directly from within Thread.run() method right? In that case > Thread's implementation class is presented as the one doing the > invocation of Thread.run(), which seems logical. > > But what about if getCallerClass() is called from a method that has been > invoked from native code via JNI in a newly attached thread that was not > started in Java (like the main method)? We will also get the Thread's > implementation class as the caller. Is this still logical? > > What would it be if getCallerClass() returned just Optional> > and was left to the user to decide what to do in corner cases when there > is no Java caller? > > So returning java.lang.Class objects is safe now there is jigsaw to > enforce isolation when doing reflection on them. It's great to see how > things fall together nicely. > > Regards, Peter > > On 10/30/2015 08:04 PM, Mandy Chung wrote: >> JEP 259:http://openjdk.java.net/jeps/259 >> >> Javadoc for the proposed StackWalker API: >> >> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html >> >> >> A simple way to walk the stack: >> >> StackWalker walker = new >> StackWalker(StackWalker.Option.CLASS_REFERENCE); >> walker.walk((s) -> s.filter(f -> >> interestingClasses.contains(f.getDeclaringClass())).findFirst()); >> >> The current usage of sun.reflect.Reflection.getCallerClass(int depth) >> can be replaced with this StackWalker API. >> >> Any feedback on the proposed API is appreciated. >> >> Mandy >> >> P.S. webrev of the current implementation: >> http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ >> >> >> >> >> >> >> > From claes.redestad at oracle.com Tue Nov 3 13:30:35 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 03 Nov 2015 14:30:35 +0100 Subject: RFR (XS): 8140683: Deduplicate Strings in UnixFileSystem canonical caches In-Reply-To: References: <5631299D.2050602@oracle.com> Message-ID: <5638B6FB.7040000@oracle.com> On 2015-11-03 14:19, Paul Sandoz wrote: >> On 28 Oct 2015, at 21:01, Claes Redestad wrote: >> >> Hi, >> >> while investigating startup and footprint for jigsaw, I found this unrelated oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate file paths determined to be equal when putting them into its internal cache. Also avoid some recalculation of paths determined to be canonical for no good reason and we're golden: >> >> webrev: http://cr.openjdk.java.net/~redestad/8140683/webrev.01 >> bug: https://bugs.openjdk.java.net/browse/JDK-8140683 >> > I am not an expert in this area, but something does not feel right that you have modified things so the the key and value for a cache entry are the same. Why bother caching in that is the case? I am missing something obvious here? > > Paul. The caching is only done to avoid possibly expensive calls into canonicalize0, and I've not been able to construct a case where the key and the value aren't equal to begin with (in the second case it's an invariant since we already verified resDir.equals(dir), in the first case it follows from how parentOrNull is implemented), thus I'm convinced that this patch doesn't currently change semantics (there's even that primordial comment that the java.home prefix cache could just as easily be considered a set, but java.io.ExpiringCache is what it is). /Claes From Alan.Bateman at oracle.com Tue Nov 3 13:36:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 13:36:05 +0000 Subject: RFR (XS): 8140683: Deduplicate Strings in UnixFileSystem canonical caches In-Reply-To: References: <5631299D.2050602@oracle.com> Message-ID: <5638B845.70504@oracle.com> On 03/11/2015 13:19, Paul Sandoz wrote: > : > > I am not an expert in this area, but something does not feel right that you have modified things so the the key and value for a cache entry are the same. Why bother caching in that is the case? I am missing something obvious here? > > I mentioned to Claes off list that there are changes coming to FilePermission that will allow us to disable or just remove this cache. This cache has always been problematic so having it go away would be great. -Alan From peter.levart at gmail.com Tue Nov 3 13:58:22 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 3 Nov 2015 14:58:22 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <5627A699.102@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <56277C12.6040509@gmail.com> <56278180.6020402@gmail.com> <5627955A.30706@Oracle.com> <562799FA.5060702@oracle.com> <5627A50B.6020206@redhat.com> <5627A699.102@Oracle.com> Message-ID: <5638BD7E.4080209@gmail.com> Hi, Here's a demonstration that shows the "reachability" race: import java.lang.ref.ReferenceQueue; import java.lang.ref.WeakReference; /** * A demonstration of WeakReference initialization race */ public class WeakRace extends WeakReference { static volatile boolean pause; int value; public WeakRace(Object referent, ReferenceQueue q) { super(referent, q); init(); } private void init() { if (pause) try { Thread.sleep(500L); } catch (InterruptedException e) { throw new RuntimeException(e); } value = 123; } static void monitor(ReferenceQueue queue) { while (true) try { WeakRace wr = (WeakRace) queue.remove(); int value = wr.value; if (value == 0) { System.out.println("Got value: " + value); } } catch (InterruptedException e) { throw new RuntimeException(e); } } static void constructor(ReferenceQueue queue) { WeakRace[] wrs = new WeakRace[10000]; while (true) { for (int i = 0; i < wrs.length; i++) { wrs[i] = new WeakRace(new Object(), queue); } } } public static void main(String[] args) throws Exception { ReferenceQueue queue = new ReferenceQueue<>(); new Thread(() -> monitor(queue), "Monitor").start(); new Thread(() -> constructor(queue), "Constructor").start(); for (int i = 0; i < 30; i++) { Thread.sleep(1000L); WeakRace.pause = true; Thread.sleep(1L); System.gc(); WeakRace.pause = false; } } } Running this program nicely outputs: Got value: 0 Got value: 0 Got value: 0 Got value: 0 Got value: 0 Got value: 0 ... once per second. Adding referent.getClass() call after init() in WeakRace constructor "fixes" it, but I would rather use reachabilityFence() for that purpose to be more reliable. Regards, Peter On 10/21/2015 04:52 PM, Roger Riggs wrote: > Hi Andrew, > > So then is is correct to conclude that the gc does examine fields in > instances > still being constructed to determine reachability? > > How is that we have gone so long without needing reachabilityFence? > Or is it just because optimizers have taken so long to get a perfect > view of reference scope? > > Thanks, Roger > > > On 10/21/2015 10:45 AM, Andrew Haley wrote: >> On 10/21/2015 02:58 PM, Daniel Fuchs wrote: >>> I do hope that method parameters are not eagerly gc'ed before >>> the method returns >> They are -- that's what reachabilityFence() is for. I don't think >> that constructors have any special rules, and nor should they. >> >> Andrew. > From peter.levart at gmail.com Tue Nov 3 14:31:58 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 3 Nov 2015 15:31:58 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5638B495.5010004@oracle.com> References: <5638AC76.4080603@gmail.com> <5638B495.5010004@oracle.com> Message-ID: <5638C55E.2050606@gmail.com> On 11/03/2015 02:20 PM, Daniel Fuchs wrote: > Hi Peter, > > You also get Thread.currentThread().getClass() if you call > StackWalker.getCallerClass() from main(). > > Because who is the caller of main()? I would say there is no Java caller in that case and return Optional.empty(). No Java caller means there is no bytecode in a class doing the invocation, so there is no java.lang.Class to identify it. Subsituting that for Thread.currentThread().getClass() looses information. In the following example, one can not distinguish between two situations: public class StackWalkerDemo extends Thread { @Override public void run() { System.out.println("I was called from: " + new StackWalker(StackWalker.Option.CLASS_REFERENCE).getCallerClass()); } public static void main(String[] args) throws Exception { StackWalkerDemo demo = new StackWalkerDemo(); demo.run(); demo.start(); demo.join(); } } Prints: I was called from: class StackWalkerDemo I was called from: class StackWalkerDemo The 1st is clearly an invocation from the method in class StackWalkerDemo (main()), but the 2nd is not. Regards, Peter > > cheers, > > -- daniel > > On 03/11/15 13:45, Peter Levart wrote: >> Hi Mandy, >> >> Great API. >> >> One thing I noticed is method StackWalker.getCallerClass() which is >> described as equivalent to the following: >> >> walk((s) -> s.map(StackFrame::getDeclaringClass) >> .skip(2) >> .findFirst()).orElse(Thread.currentThread().getClass()); >> >> ... the .orElse is presumably meant for the case when getCallerClass() >> is called directly from within Thread.run() method right? In that case >> Thread's implementation class is presented as the one doing the >> invocation of Thread.run(), which seems logical. >> >> But what about if getCallerClass() is called from a method that has been >> invoked from native code via JNI in a newly attached thread that was not >> started in Java (like the main method)? We will also get the Thread's >> implementation class as the caller. Is this still logical? >> >> What would it be if getCallerClass() returned just Optional> >> and was left to the user to decide what to do in corner cases when there >> is no Java caller? >> >> So returning java.lang.Class objects is safe now there is jigsaw to >> enforce isolation when doing reflection on them. It's great to see how >> things fall together nicely. >> >> Regards, Peter >> >> On 10/30/2015 08:04 PM, Mandy Chung wrote: >>> JEP 259:http://openjdk.java.net/jeps/259 >>> >>> Javadoc for the proposed StackWalker API: >>> >>> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html >>> >>> >>> >>> A simple way to walk the stack: >>> >>> StackWalker walker = new >>> StackWalker(StackWalker.Option.CLASS_REFERENCE); >>> walker.walk((s) -> s.filter(f -> >>> interestingClasses.contains(f.getDeclaringClass())).findFirst()); >>> >>> The current usage of sun.reflect.Reflection.getCallerClass(int depth) >>> can be replaced with this StackWalker API. >>> >>> Any feedback on the proposed API is appreciated. >>> >>> Mandy >>> >>> P.S. webrev of the current implementation: >>> http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/ >>> >>> >>> >>> >>> >>> >>> >> > From jaroslav.bachorik at oracle.com Tue Nov 3 14:45:51 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 3 Nov 2015 15:45:51 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <1446487615.10865.57.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> Message-ID: <5638C89F.2090406@oracle.com> On 2.11.2015 19:06, Severin Gehwolf wrote: > Hi, > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > Hi, > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > >> Hi Severin, > >> > >> Adding serviceability-dev at openjdk.java.net into the loop - that's > >> a better alias than hotspot-dev for this kind of changes - maybe > >> someone from serviceability-dev will offer to sponsor :-) > >> > >> I will let serviceability team members comment on the hotspot > >> changes. > >> > >> ConnectorBootstrap.java > >> > >> I have one suggestion and one concern: > >> > >> Suggestion: I would suggest to reuse 'csf' (Client Socket Factory) > >> and > >> ssf (Server Socket Factory) variables rather than introduce the > >> two > >> new variables rmiServerSocketFactory and rmiClientSocketFactory. > >> You might want to create a new boolean 'useSocketFactory' variable, > >> if that makes the code more readable. > >> > >> Concern: If I understand correctly how RMI socket factories work, > >> the client socket factory will be serialized and sent to the client > >> side. This is problematic for interoperability, as the class may > >> not > >> present in the remote client - if the remote client is e.g. jdk 8. > >> > >> As far as I can see, your new DefaultClientSocketFactory doesn't do > >> anything useful - so I would suggest to simply get rid of it, and > >> only > >> set the Server Socket Factory when SSL is not involved. > > Thanks. Fixed in updated webrev. > > >> Tests: > >> > >> Concerning the tests - we're trying to get rid of shell scripts > >> rather than introducing new ones :-) > >> Could the test be rewritten in pure java using the Process API? > >> > >> I believe there's even a test library that will let you do that > >> easily jdk/test/lib/testlibrary/jdk/testlibrary/ > >> (see ProcessTools.java) > > It'll take me a bit to rewrite the test in pure Java, but should be > fine. This is not yet fixed in the updated webrev. > > >> Other: > >> > >> Also - I believe the new option should be documented in: > >> src/java.management/share/conf/management.properties > > Docs have been updated > in src/java.management/share/conf/management.properties. > > > I share Daniel's concerns. Also, the part of the changeset is related > > to javax.rmi.ssl - someone maintaining this library should also > > comment here. > > > > Also, the change is introducing new API (system property) and > > changing the existing one (adding SslRmiServerSocketFactory public > > constructors) so compatibility review process will have to be > > involved. > > OK. What exactly is there for me to do? I'm not familiar with this > process. Note that the intent would be to get this backported to JDK 8. Not much for you. But for the potential Oracle sponsor this means she will have to remember to go through some extra hoops before integrating your patch. -JB- > > New webrev at: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > Thanks, > Severin > > > -JB- > >> > >> best regards, > >> > >> -- daniel > >> > >> On 02/11/15 11:38, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Here is a patch addressing JDK-6425769. The issue is that the JMX > >>> agent > >>> binds to the wildcard address by default, preventing users to use > >>> system properties for JMX agents on multi-homed hosts. Given a > >>> host > >>> with local network interfaces, 192.168.0.1 and 192.168.0.2 say, > >>> it's > >>> impossible to start two JMX agents binding to fixed ports but to > >>> different network interfaces, 192.168.0.1:{9111,9112} and > >>> 192.168.0.2:{9111,9112} say. > >>> > >>> The JDK would bind to all local interfaces by default. In the > >>> above > >>> example to 192.168.0.1 *and* 192.168.0.2. The effect is that the > >>> second > >>> Java process would get a "Connection refused" error because > >>> another > >>> process has already been bound to the specified JMX/RMI port > >>> pairs. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > >>> 00/ > >>> > >>> Testing done: > >>> jdk_jmx and jdk_management tests all pass after this change (no > >>> regressions). There is also a new JTREG test which fails prior > >>> this > >>> change and passes after. Updates to the diagnostic command have > >>> been > >>> tested manually. > >>> > >>> I understand that, if approved, the JDK and hotspot changes > >>> should get > >>> pushed together? Hotspot changes are fairly trivial since it's > >>> only a > >>> doc-update for the new JDK property in the relevant diagnostic > >>> command. > >>> > >>> Could someone please review and sponsor this change? Please let > >>> me know > >>> if there are questions. > >>> > >>> Thanks, > >>> Severin > >>> > >> > > > From Roger.Riggs at Oracle.com Tue Nov 3 16:21:10 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 Nov 2015 11:21:10 -0500 Subject: RFR 9: 8138566: (Process) java.lang.Process.allChildren specification clarification In-Reply-To: <2F703D9C-5567-45AF-8AC2-8174CFBF03A0@oracle.com> References: <56340016.80701@oracle.com> <2F703D9C-5567-45AF-8AC2-8174CFBF03A0@oracle.com> Message-ID: <5638DEF6.20204@Oracle.com> Hi Paul, Thanks for the review. The webrev is updated in place: http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ I added an @apiNote to both onExit methods: * The process may be observed to have terminated with {@link #isAlive} * before the ComputableFuture is completed and dependent actions are invoked. It is not strong enough for happens-before due to multi-threading possibly under conditions where a thread might experience arbitrary delays in the implementation of isAlive. A minior update in ProcessUtil: the getAllChildren is renamed to getDescendants. Thanks, Roger On 11/3/2015 7:58 AM, Paul Sandoz wrote: >> On 31 Oct 2015, at 00:41, Roger Riggs wrote: >> >> Please review and comment on 3 clarifications to ProcessHandle and Process. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ >> >> 8138566: (Process) java.lang.Process.allChildren specification clarification >> - Rename the allChildren() method to descendants() - it is more descriptive and >> less easily confused with the children method. >> - The risk of renaming is method is minimal since it has been only available for a short time. >> >> 8140213: Process/ProcessHandle.onExit() spec need to be improved >> - The timing of the completion of the CompletableFuture was too tightly specified. >> With the isAlive method, it is possible to observe that the process has terminated >> before the CF is completed. The CF is completed sometime after the process terminates. >> >> 8140250: (process) Process.info description is inaccurate >> - The specification of the Process/ProcessHandle.info() method did not match >> the implementation. On an OS (Windows) some information is available about >> the process after it is no longer alive. >> > +1 > > Might be worth mentioning in a note that it may be observed that the process has terminated, via queries to isAlive, before the onExit CF has completed, but presumably never the other way around? (too weak for a happens-before relationship?). > > Paul. > From nadeesh.tv at oracle.com Tue Nov 3 16:26:28 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 03 Nov 2015 21:56:28 +0530 Subject: RFR:JDK-8138664- ZonedDateTime parse error for any date using 'GMT0' ZoneID Message-ID: <5638E034.70500@oracle.com> Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8138664 Issue- ZonedDateTime parse error for any date using 'GMT0' ZoneID Solution - Handled the GMT0 separately in the parsing method BugId - https://bugs.openjdk.java.net/browse/JDK-8138664 webrev - http://cr.openjdk.java.net/~ntv/8138664/webrev.00/ -- Thanks and Regards, Nadeesh TV -- Thanks and Regards, Nadeesh TV From steve.drach at oracle.com Tue Nov 3 17:11:50 2015 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 3 Nov 2015 09:11:50 -0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <562EFF8F.6070501@oracle.com> References: <561ED8BF.40901@oracle.com> <561F16C1.6090702@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> Message-ID: Please review the latest webrev that addresses the issue raised in Sherman?s comments below, with my comments interspersed in-line. The changes between this webrev and the last one are in the definition and use of the ismultiRelease() method and the introduction of a configuration lock, the boolean configured, that prevents setting the version after an entry has been read from the jar file. As a consequence of the configuration lock, I had to modify a couple tests and add a new one. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > On Oct 26, 2015, at 9:37 PM, Xueming Shen wrote: > > Hi Steve, > > I know I stared to sound like a broken record :-) But I would like to suggest the team one more > time to reconsider the current decision of using the "set" methods to change the configuration > setting/status of an existing JarFile to enable the multi-version support. > > public JarFile setVersioned(int version); > public JarFile setRuntimeVersioned(); We did reconsider it, more later. > > The main concern here is the current approach basically transfers the JarFile from a read-only/ > immutable object with consistent behavior (to entry inquiry) to a mutable container of entries > with possibility of inconsistent behavior. The newly introduced setVersioned/setRuntimeVersioned > really have no way to guarantee A expected result from the updated version-enabled getEntry() > method, as someone else might set an unexpected different "version" between your setting and > getting, or even worse, in the middle of your entries() invocation, for example, in which you get > part of your entries to version N and the rest to version M. We?ve introduced a configuration lock. One can change the versioning strategy as often as they wish before reading an entry. However if setVersioned() is called after an entry has been read, an IllegalStateException is thrown. > > So It might be desired to have the "versioned support" enabled in the constructor, so once you > get that version enabled JarFile, it stays that way for its lifetime with consistent result for the > entry inquiry, as the current API does. We can?t do it in the constructor because we need to read the manifest, and doing that in the constructor leads to a stack overflow for some instances, such as deploy, where JarFile is subclassed and the manifest is lazily read. Basically, the manifest is not available during construction. > > I do realize that there might be use case that the getEntry invoker might not have the access to > the creation of the corresponding jar file (such as the use scenario in that JarURLConnection?), so > you can't create a version-enabled JarFile at the very beginning via the constructor. But doesn't > this also make my concern more real. If you don't have the control of the lifetime of that JarFile, > you don't really have the control of who is setting or going to set the version of that mutable JarFile, > right? > > An alternative might be to have change the setVersioned/setRuntimeVersioned() to > > public jarFile getVersioned(int version); > public jarFile getRuntimeVersioned(); > > to return a new copy of the existing JarFile with the desired verisoning support. That?s a problem because we would then have two instances of JarFile, and we?d need to remember to close the underlying instance. An alternative is to use factory methods to create the versioned JarFile. That works, but we have to add about six of them to correspond to the current set of constructors. But the big problem here is, as you mention, the JarFile returned from JarURLConnection. From experiments it looks to me that the underlying cached JarFile is unlinked from the Unix filesystem and thus unavailable for replication. This code seems very OS dependent as well as potentially fragile since subclasses can implement the abstract getJarFile() method any way they wish. A configuration lock seems to be a good compromise. We can mutate the JarFile versioning strategy as much as we want until we read an entry, and then no more mutations are allowed. For what it is worth, I don?t see a real use case to set the versioning strategy more than once, even before an entry is read. I do that in the tests, but it?s difficult to imagine it anywhere else. The intention is to construct a JarFile and then immediately set the versioning strategy. > Yes, it might be > too heavy from performance perspective :-) and we might have to do some tricky stuff (it would > be easier if ZipJarFile is interface ...) to have a light wrapper class to delegate everything to the > real one. > > That said, I'm fine to be told "the pros and cons were considered, and this is the best for the > supported use scenario":-) Yes, that is the case. > In that case, it might deserve some wording in the spec notes to > prepare the developer the possible unexpected. > > Thanks, > Sherman > > > On 10/26/15 10:26 AM, Steve Drach wrote: >> Hi, >> >> We?ve published another webrev for review. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >> >> This one addresses the issues regarding CodeSigners, Certificates, verification, and other security issues raised in the last round, including whether third party verification is a supported use case. I also partially fixed a nitpick involving performance while searching for versioned entries, by putting in a cache for previously searched entries. And I found a way around the issue with windows being unable to delete jar files accessed through URL?s in one test. >> >> Steve >> >>> On Oct 21, 2015, at 12:54 AM, Wang Weijun wrote: >>> >>>> On Oct 21, 2015, at 3:17 PM, Xueming Shen wrote: >>>> >>>> We might want to bring in Max to take a look if what I said is really a supported use scenario. >>> I haven't read Steve's latest code change. I will read if you think it's necessary. >>> >>> First, I think we agree that the multi-release jar file feature is only making use of the existing jar file format and does not intend to introduce any change to its specification. This means a JarFile signed by one JDK release should be verified by another JDK release. >>> >>> Ok, the next question is, should it modify the JarFile API? I hope not, because the JarFile API is the single entry we access a JarFile when we want to sign or verify it. I hope there is a brand new API for a multi-versioned jar file, probably a child class of JarFile, so that no matter you call getJarEntry() or entries() on it, you always get the versioned one and the unrelated ones are completely invisible. >>> >>> If this is not OK, maybe we can rename the current JarFile to RawJarFile and name the new API JarFile. Signing and verification will work on RawJarFile. >>> >>> Not sure if it's easy. >>> >>> --Max >>> On Oct 21, 2015, at 12:17 AM, Xueming Shen wrote: >>> >>> Hi Steve, >>> >>> The reifiedEntry() approach probably can help the default JarVerifier work as expected, but if I read the >>> code correctly I doubt you can get the expected CodSigner[] and Certificatte[] result from a "versioned" >>> JarFileEntry, after having read all bytes from the input stream (obtained via jzf.getInputStream(JarFileEntry)), >>> as the JarEntry spec suggests,. As we are passing the "reified" entry into the VerifierStream alone, without >>> any reference to the original jar file entry. It seems impossible for the original jar file entry can trace back to >>> the corresponding certificates and code signers. This might be fixed by passing in the original entry together >>> into the JarVerifier, but I doubt we might have a bigger issue here. I suspect with this approach an external >>> verifier will have no easy way to verify the digit signature of the jar entry via java.security APIs. I would assume >>> this is doable right now with current JarFile APIs, via a JarFile object, a Manifest and a target JarEntry. The external >>> can get the signature via name -> manifest->attributes->signature (basically just consider to move the >>> JarVerifier and couple sun.security.util classes out and use it as user code)... but with this implementation >>> the name now is the root entry, but the bytes you can read from the stream is from the versioned one. >>> We might want to bring in Max to take a look if what I said is really a supported use scenario. I might be >>> wrong, not a security expert :-) >>> >>> Btw, for a "normal" JarEntry/ZipEntry (not a JarFileEntry), shouldn't the getInputStream(ze) simply return >>> the stream for the root entry? The current implementation of getJarEntry(ze) does not seem right, as it >>> returns a "versioned" JarFileEntry. I don't think you want to pass this one into VerifierStream directly, >>> right? Again, I think it might be desired (at least the spec is not updated to say anything about "version") >>> to simply return the input stream for the root entry. >>> >>> One more "nitpick". searchForVersionedEntry() now lookups the versioned candidate via super.getEntry() >>> from version to BASE_VERSION, if the version is the latest version 9, the base is 0, we are basically doing >>> this search for each non-versioned-entry inside this multi-release-jar file 9 times everytime when the entry >>> is asked. In worse case scenario, a multi-release-jar, with huge number of entries with a small portion are >>> versioned to 9, and you are iterating it via "entries". Each lookup might be cheap, but it might be worth >>> considering adding some optimization. >>> >>> Best, >>> Sherman > From alejandro.murillo at oracle.com Tue Nov 3 17:45:31 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 03 Nov 2015 10:45:31 -0700 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" Message-ID: <5638F2BB.8020203@oracle.com> Please review these changes: bug: https://bugs.openjdk.java.net/browse/JDK-8139986 Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ Background: These changes introduce a new system property named "jdk.debug" intended to identify the type of the build. The build system has already been modified (see [1]) to provide the build type through the "--with-debug-level" configure option, and to remove that info from the (new) version string and consequently from the "java.version" and "java.vm.version" system properties. Here, the configure debug level is used to initialize the value of the "jdk.debug" system property. There are also changes to adapt any code that relied on the value of those version properties to determine the build type. They were changed to use this new property. The Launcher output was also modified to look as follows: jdk.debug = (?*foo*? != ?release?) $java -version java version "9-ea" Java(TM) SE Runtime Environment (*foo *build 9-ea+88) Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, mixed mode) jdk.debug = ?release?: (no change) $java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+88) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) All this will be described and updated in the JEP-223 doc [2] shortly. [1] https://bugs.openjdk.java.net/browse/JDK-8139951 [2] http://openjdk.java.net/jeps/223 Thanks -- Alejandro From paul.sandoz at oracle.com Tue Nov 3 17:58:58 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 18:58:58 +0100 Subject: RFR: String Density/Compact String JEP 254 (update) In-Reply-To: <5633E16F.8090904@oracle.com> References: <56129786.1090402@oracle.com> <5633E16F.8090904@oracle.com> Message-ID: <72CAA66E-6C3C-4CEA-85B6-AF1884688D72@oracle.com> Hi, This is a significant body of impressive work, well done all who worked on it. String ? 148 * The instance field value is generally opaque to optimizing JIT 149 * compilers. Therefore, in performance-sensitive place, an explicit 150 * check of the static boolean {@code COMPACT_STRINGS} is done first 151 * before checking the {@code coder} field since the static boolean 152 * {@code COMPACT_STRINGS} would be constant folded away by an 153 * optimizing JIT compiler. The idioms for these cases are as follows. ... 172 * @implNote 173 * The actual value for this field is injected by JVM. The static 174 * initialization block is used to set the value here to communicate 175 * that this static final field is not statically foldable, and to 176 * avoid any possible circular dependency during vm initialization. 177 */ 178 static final boolean COMPACT_STRINGS; For those not so knowledgeable on matters the impl note may appear to contradict what is stated previously on constant folding. You might want to clarify that you don?t want the field to be directly initialized to a constant expression since usages are replaced at compile time with the value of the constant expression. I notice in some cases for comparisons of this string with another string, such as String.startsWith, when the coders are not equal and this coder is LANTIN1 and the other coder is UTF16 you have a short cut on the assumption that the contents will be different, but in other cases like compareTo or regionMatches this is not the case. Why the difference? String a = ? // LATIN1 encoding String b = ? // UTF16 encoding, sharing a common prefix with a, and some additional UTF16 chars afterwards a.startsWith(b.substring(0, a.length()); // false b.startsWith(a); // true ? Ah, I see that you are compressing in package private constructors, so in effect normalizing to LANTIN1 where possible: 3008 * Package private constructor. Trailing Void argument is there for 3009 * disambiguating it against other (public) constructors. 3010 * 3011 * Stores the char[] value into a byte[] that each byte represents 3012 * the8 low-order bits of the corresponding character, if the char[] 3013 * contains only latin1 character. Or a byte[] that stores all 3014 * characters in their byte sequences defined by the {@code StringUTF16}. 3015 */ 3016 String(char[] value, int off, int len, Void sig) { Thus i think my above example will actually work as expected, since the substring will result in a new string using a LATIN1 coder. But does my point still apply that the coder checking logic is inconsistently applied? I cannot quite tell if the normalization is consistently applied or only for certain operations. Perhaps there needs to be some asserts judiciously placed that verify the string content to better catch cases where normalization is unintentionally not applied? For new tests that use Random you should add the following * @key randomness I stopped there for now. Paul. P.S. I hope at some point in the future we can revisit the HotSpot intrinsics for byte[]/char[] equality and comparison with future array mismatch work. > On 30 Oct 2015, at 22:30, Xueming Shen wrote: > > Hi, > > Thanks for the comments/suggestions. Here are the updated webrevs with minor changes here > and there based on the feedback. > > http://cr.openjdk.java.net/~sherman/8054307/jdk/ > http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot/ > > [closed, Oracle internal only] > http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot/ > http://javaweb.us.oracle.com/~tohartma/compact_strings/hotspot_test_closed/ > > The code is ready for integration. The current plan is to integrate via the hotspot repo in coming > week if it passes the PIT. > > Thanks > -Sherman > > On 10/5/15 8:30 AM, Xueming Shen wrote: >> (resent to hotspot-dev at openjdk.java.net) >> >> Hi, >> >> Please review the change for JEP 254/Compact String project. >> >> JPE 254: http://openjdk.java.net/jeps/254 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8054307 >> Webrevs: http://cr.openjdk.java.net/~sherman/8054307/jdk/ >> http://cr.openjdk.java.net/~thartmann/compact_strings/webrev/hotspot >> >> Description: >> >> String Density project is to change the internal representation of the >> String class from a UTF-16 char array to a byte array plus an encoding >> flag field. The new String class stores characters encoded either as >> ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes >> per character), based upon the contents of the string. The encoding >> flag indicates which encoding is used. It offers reduced memory footprint >> while maintaining throughput performance. See JEP 254 for more additional >> information >> >> Implementation repo/try out: >> http://hg.openjdk.java.net/jdk9/sandbox/ branch: JDK-8054307-branch >> >> $ hg clone http://hg.openjdk.java.net/jdk9/sandbox/ >> $ cd sandbox >> $ sh ./get_source.sh >> $ sh ./common/bin/hgforest.sh up -r JDK-8054307-branch >> $ make configure >> $ make images >> >> Implementation Notes: >> >> - To change the internal representation of the String and the String >> builder classes (AbstractStringBuilder, StringBuilder and StringBuffer) >> from a UTF-16 char array to a byte array plus an encoding flag field. >> >> The new representation stores the String characters in a single byte >> format using the lower 8-bit of character's 16-bit UTF16 value, and >> sets the encoding flag as LATIN1, if all characters of the String >> object are Unicode Latin1 characters (with its UTF16 value < \u0100) >> >> It stores the String characters in 2-byte format with their UTF-16 value >> and sets the flag as UTF16, if any of the character inside the String >> object is NOT Unicode latin1 character. >> >> - To change the method implementation of the String class and its builders >> to function on the new internal character storage, mainly to delegate to >> two implementation classes StringUTF16 and StringLatin1 >> >> - To update the StringCoding class to decoding/encoding the String between >> String.byte[]/coder(LATIN1/UTF16) <-> byte[](native encoding) instead >> of the original String.char[] <-> byte[] (native encoding) >> >> - To update the hotSpot compiler (new and updated instrinsics), GC (String >> Deduplication mods) and Runtime to work with the new internal "byte[] + >> coder flag" representation. >> >> See Tobias's note for details of the hotspot changes: >> http://cr.openjdk.java.net/~thartmann/compact_strings/hotspot-impl-note >> >> - To add a vm option "CompactStrings" (default is true) to provide a >> switch-off mechanism to always store the String characters in UTF16 >> encoding (always 2 bytes, but still in a byte[], instead of the >> original char[]). >> >> >> Supporting performance artifacts: >> >> - Report(s) on memory footprint impact >> >> http://cr.openjdk.java.net/~shade/density/string-density-report.pdf >> >> Latest SPECjbb2005 footprint reduction and throughput numbers for both >> Intel (Linux) and SPARC, in which it shows the Compact String binaries >> use less memory and have higher throughput. >> >> latest:http://cr.openjdk.java.net/~sherman/8054307/specjbb2005 >> old: http://cr.openjdk.java.net/~huntch/string-density/reports/String-Density-SPARC-jbb2005-Report.pdf >> >> - Throughput performance impact via String API micro-benchmarks >> >> http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Haswell_090915.pdf >> http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/IvyBridge_090915.pdf >> http://cr.openjdk.java.net/~thartmann/compact_strings/microbenchmarks/Sparc_090915.pdf >> http://cr.openjdk.java.net/~sherman/8054307/string-coding.txt >> >> Thanks, >> Sherman > From paul.sandoz at oracle.com Tue Nov 3 18:12:48 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 19:12:48 +0100 Subject: RFR 9: 8138566: (Process) java.lang.Process.allChildren specification clarification In-Reply-To: <5638DEF6.20204@Oracle.com> References: <56340016.80701@oracle.com> <2F703D9C-5567-45AF-8AC2-8174CFBF03A0@oracle.com> <5638DEF6.20204@Oracle.com> Message-ID: <8B126E6B-1209-4177-9A81-5635F7BA967C@oracle.com> > On 3 Nov 2015, at 17:21, Roger Riggs wrote: > > Hi Paul, > > Thanks for the review. > > The webrev is updated in place: > http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ > > > I added an @apiNote to both onExit methods: > > * The process may be observed to have terminated with {@link #isAlive} > * before the ComputableFuture is completed and dependent actions are invoked. > > It is not strong enough for happens-before due to multi-threading possibly under conditions > where a thread might experience arbitrary delays in the implementation of isAlive. > > A minior update in ProcessUtil: the getAllChildren is renamed to getDescendants. > +1 Paul. From magnus.ihse.bursie at oracle.com Tue Nov 3 19:24:07 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 Nov 2015 20:24:07 +0100 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" In-Reply-To: <5638F2BB.8020203@oracle.com> References: <5638F2BB.8020203@oracle.com> Message-ID: <563909D7.3070907@oracle.com> Hi Alejandro, On 2015-11-03 18:45, Alejandro E Murillo wrote: > Please review these changes: > > bug: https://bugs.openjdk.java.net/browse/JDK-8139986 > Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ Looks good to me. /Magnus > > Background: > These changes introduce a new system property named "jdk.debug" > intended to > identify the type of the build. The build system has already been > modified (see [1]) > to provide the build type through the "--with-debug-level" configure > option, > and to remove that info from the (new) version string and > consequently from the "java.version" and "java.vm.version" system > properties. > > Here, the configure debug level is used to initialize the value of the > "jdk.debug" system > property. There are also changes to adapt any code that relied on the > value of those version > properties to determine the build type. They were changed to use this > new property. > > The Launcher output was also modified to look as follows: > > jdk.debug = (?*foo*? != ?release?) > $java -version > java version "9-ea" > Java(TM) SE Runtime Environment (*foo *build 9-ea+88) > Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, > mixed mode) > > jdk.debug = ?release?: (no change) > > $java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+88) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) > > > All this will be described and updated in the JEP-223 doc [2] shortly. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139951 > [2] http://openjdk.java.net/jeps/223 > > Thanks > From alejandro.murillo at oracle.com Tue Nov 3 19:45:12 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 03 Nov 2015 12:45:12 -0700 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" In-Reply-To: <563909D7.3070907@oracle.com> References: <5638F2BB.8020203@oracle.com> <563909D7.3070907@oracle.com> Message-ID: <56390EC8.4040305@oracle.com> Thanks Magnus! Alejandro On 11/3/2015 12:24 PM, Magnus Ihse Bursie wrote: > Hi Alejandro, > > On 2015-11-03 18:45, Alejandro E Murillo wrote: >> Please review these changes: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8139986 >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ > > Looks good to me. > > /Magnus > >> >> Background: >> These changes introduce a new system property named "jdk.debug" >> intended to >> identify the type of the build. The build system has already been >> modified (see [1]) >> to provide the build type through the "--with-debug-level" configure >> option, >> and to remove that info from the (new) version string and >> consequently from the "java.version" and "java.vm.version" system >> properties. >> >> Here, the configure debug level is used to initialize the value of >> the "jdk.debug" system >> property. There are also changes to adapt any code that relied on the >> value of those version >> properties to determine the build type. They were changed to use >> this new property. >> >> The Launcher output was also modified to look as follows: >> >> jdk.debug = (?*foo*? != ?release?) >> $java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (*foo *build 9-ea+88) >> Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, >> mixed mode) >> >> jdk.debug = ?release?: (no change) >> >> $java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+88) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) >> >> >> All this will be described and updated in the JEP-223 doc [2] shortly. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8139951 >> [2] http://openjdk.java.net/jeps/223 >> >> Thanks >> > -- Alejandro From daniel.fuchs at oracle.com Tue Nov 3 20:12:55 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 3 Nov 2015 21:12:55 +0100 Subject: RFR: JDK-8140364: JEP 264 Platform Logger API and Service Implementation In-Reply-To: <562A49BB.7070206@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> <5626B6B7.2040501@oracle.com> <54D9FB8E-A69D-4A41-B81D-D8C1BBFC50EF@oracle.com> <562A49BB.7070206@oracle.com> Message-ID: <56391547.5010006@oracle.com> Hi Mandy, I have pushed an update that adds the diagnosability tweaks you asked me for in LoggerFinderLoader. I also added a couple of new tests. No changes in the API specification. The sandbox JDK-8046565-branch and public links have been refreshed. best regards, -- daniel sandbox branch JDK-8046565-branch http://cr.openjdk.java.net/~chegar/docs/sandbox.html http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html On 23/10/15 16:52, Daniel Fuchs wrote: > Hi, > > Please find below the online link integrating the latest editorial > comments I received (from Mandy): > > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html > > > sandbox branch JDK-8046565-branch updated as well. > > best regards > > -- daniel > > Start of the review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035715.html > > Subject: RFR: JDK-8046565: Platform Logger API and Service > > JEP 264 JBS Issue (8046565): > https://bugs.openjdk.java.net/browse/JDK-8046565 > > RFE that will be ultimately used to commit (8140364): > https://bugs.openjdk.java.net/browse/JDK-8140364 From Roger.Riggs at Oracle.com Tue Nov 3 20:32:17 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 Nov 2015 15:32:17 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <173536F2-C957-4454-97A6-F49FEBD2B156@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <173536F2-C957-4454-97A6-F49FEBD2B156@oracle.com> Message-ID: <563919D0.4050406@Oracle.com> Hi Mandy, On 11/2/2015 2:53 PM, Mandy Chung wrote: >> On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote: >> >> Updated Javadoc: >> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > I?m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: > 1. For an existing finalizer (say cleanup function), it will be replaced with > Cleaner.create().phantomCleanable(this, this::cleanup); Not quite, It can't reference this; the cleanup method must not have any reference to the object being cleaned up because the Cleanable holds a strong reference to the cleanup state and would keep it from being xxx unreachable. The cleaning function must only refer to the state (and behavior) that does the cleaning. It could be a static method with all the state in the arguments. Or a instance method on a object holding only the cleanup state. > > It may be useful to provide a sharable Cleaner instance that doesn?t go away. yes, for the use cases in java.base, there will be a common cleaner in the jdk.internal.misc package. > > The primary use for this Cleaner API is to replace finalizers. I wonder it worths having a convenient method easier to relate to finalizer (say Cleaner.finalizable?) Not just finalizers; I would stay away from the term finalizer to avoid overloading the understanding. Finalization is specific specification defined semantics. > > 2. Do you know any existing use of soft / weak references in the JDK can benefit from this automatic cleanup mechanism? The typical cache implementation using soft/weak references is to purge the entries when the cache is accessed and manages the reference queue without a background thread. Peter Levart offered an example of a self cleaning Weak key'ed collection. It would be nice to have a ConcurrentHashMap with Weak keys. > > I?m in two minds that it sounds sensible for this Cleaner API to extend for soft/weak references whereas I am not certain of the use cases. Anyone can share the known use cases that would be helpful. Besides the cases already mentioned on the thread... Anyone? > >> Updated Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > 57 final PhantomCleanable phantomCleanableList; > 59 final WeakCleanable weakCleanableList; > 61 final SoftCleanable softCleanableList; > > - is there any benefit of keeping separate list for each reference type? Each cleaner has one single ReferenceRueue and it seems that keeping one single Cleanable list could achieve similar performance in most cases while the implementation might be simplified. Since each type has to extend the corresponding Reference subtype; the code was easier to understand and maintain with separate queues. There were several iterations using different approaches suggested during the earlier reviews. > > > 111 thread.setPriority(Thread.MAX_PRIORITY); > > VM threads are near max priority. The reference handler thread is MAX_PRORITY whereas the finalizer thread is MAX_PRIORITY-2. I'll change it to be equal to the finalizer priority; MAX_PRIORITY - 2 for the default ThreadFactory > I think the cleaner thread should not be of MAX_PRIORITY and also perhaps the caller may need a way to get the thread associated with a Cleaner so that users can set the priority if needed? The priority should be set by the ThreadFactory; if an application needs to control the thread it can/should provide a custom ThreadFactory; that will keep the API clean. The setting of the default thread priority should be in the default thread factory. Thanks, Roger ps. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Mandy > > From mandy.chung at oracle.com Tue Nov 3 21:18:22 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Nov 2015 13:18:22 -0800 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <563919D0.4050406@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <173536F2-C957-4454-97A6-F49FEBD2B156@oracle.com> <563919D0.4050406@Oracle.com> Message-ID: <3BCA153D-BAE9-47B1-9A4E-70EDB09038B6@oracle.com> > On Nov 3, 2015, at 12:32 PM, Roger Riggs wrote: > > Hi Mandy, > > On 11/2/2015 2:53 PM, Mandy Chung wrote: >>> On Oct 20, 2015, at 11:28 AM, Roger Riggs >>> wrote: >>> >>> Updated Javadoc: >>> >>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >> I?m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: >> 1. For an existing finalizer (say cleanup function), it will be replaced with >> Cleaner.create().phantomCleanable(this, this::cleanup); >> > Not quite, It can't reference this; the cleanup method must not have any reference to the object > being cleaned up because the Cleanable holds a strong reference to the cleanup state and would keep > it from being xxx unreachable. > The cleaning function must only refer to the state (and behavior) that does the cleaning. > It could be a static method with all the state in the arguments. > Or a instance method on a object holding only the cleanup state. Right. This was just used as an example (I didn?t pay attention to its correctness) to lead to the comments below. >> >> It may be useful to provide a sharable Cleaner instance that doesn?t go away. >> > yes, for the use cases in java.base, there will be a common cleaner in the jdk.internal.misc package. Should the API provide a sharable Cleaner instance for application/library to use if they want to avoid one cleaner for each library? >> >> The primary use for this Cleaner API is to replace finalizers. I wonder it worths having a convenient method easier to relate to finalizer (say Cleaner.finalizable?) >> > Not just finalizers; I would stay away from the term finalizer to avoid overloading the understanding. > Finalization is specific specification defined semantics. >> >> 2. Do you know any existing use of soft / weak references in the JDK can benefit from this automatic cleanup mechanism? The typical cache implementation using soft/weak references is to purge the entries when the cache is accessed and manages the reference queue without a background thread. >> > Peter Levart offered an example of a self cleaning Weak key'ed collection. > It would be nice to have a ConcurrentHashMap with Weak keys. Agree. When there is ConcurrentHashMap with Weak keys, would this weakCleanable be used for other use cases (that?s the part unclear to me). > >> >> I?m in two minds that it sounds sensible for this Cleaner API to extend for soft/weak references whereas I am not certain of the use cases. Anyone can share the known use cases that would be helpful. >> > > Besides the cases already mentioned on the thread... Anyone? > >> >>> Updated Webrev: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >> >> 57 final PhantomCleanable phantomCleanableList; >> 59 final WeakCleanable weakCleanableList; >> 61 final SoftCleanable softCleanableList; >> >> - is there any benefit of keeping separate list for each reference type? Each cleaner has one single ReferenceRueue and it seems that keeping one single Cleanable list could achieve similar performance in most cases while the implementation might be simplified. >> > Since each type has to extend the corresponding Reference subtype; the code was easier to understand and maintain with separate queues. There were several iterations using different approaches suggested during the earlier reviews. OK. I didn?t review all iterations. The remaining open question is whether the Cleaner API should support weakCleanable and softCleanable or keep it for phantom cleanable only. Mark will likely have input to this. >> >> >> 111 thread.setPriority(Thread.MAX_PRIORITY); >> >> VM threads are near max priority. The reference handler thread is MAX_PRORITY whereas the finalizer thread is MAX_PRIORITY-2. >> > I'll change it to be equal to the finalizer priority; MAX_PRIORITY - 2 for the default ThreadFactory >> I think the cleaner thread should not be of MAX_PRIORITY and also perhaps the caller may need a way to get the thread associated with a Cleaner so that users can set the priority if needed? > The priority should be set by the ThreadFactory; if an application needs to control the thread > it can/should provide a custom ThreadFactory; that will keep the API clean. > > The setting of the default thread priority should be in the default thread factory. > Did I look at an older webrev? The version I looked at - CleanerImpl changes the thread priority after ThreadFactory creates it: Thread thread = threadFactory.newThread(this); thread.setPriority(Thread.MAX_PRIORITY); Anyway the ThreadFactory setting the priority is good and reflected in your new webrev: http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ Mandy From mandy.chung at oracle.com Tue Nov 3 21:33:19 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Nov 2015 13:33:19 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5638AC76.4080603@gmail.com> References: <5638AC76.4080603@gmail.com> Message-ID: <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> > On Nov 3, 2015, at 4:45 AM, Peter Levart wrote: > > Hi Mandy, > > Great API. > > One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: > > walk((s) -> s.map(StackFrame::getDeclaringClass) > .skip(2) > .findFirst()).orElse(Thread.currentThread().getClass()); > > ... the .orElse is presumably meant for the case when getCallerClass() is called directly from within Thread.run() method right? In that case Thread's implementation class is presented as the one doing the invocation of Thread.run(), which seems logical. > > But what about if getCallerClass() is called from a method that has been invoked from native code via JNI in a newly attached thread that was not started in Java (like the main method)? We will also get the Thread's implementation class as the caller. Is this still logical? That should be Thread.class. > > What would it be if getCallerClass() returned just Optional> and was left to the user to decide what to do in corner cases when there is no Java caller? > I considered Optional>. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native. Most common cases will find a caller class. Returning an Optional will force most common uses to handle the case if it?s absent. It?s a tradeoff that I think it?s better to return Thread.class for the JNI attached thread calling getCallerClass in native which would rarely happen. > So returning java.lang.Class objects is safe now there is jigsaw to enforce isolation when doing reflection on them. It's great to see how things fall together nicely. Yup. I?m really looking forward to the strong encapsulation that strengthens the security. Mandy From Roger.Riggs at Oracle.com Tue Nov 3 21:42:03 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 Nov 2015 16:42:03 -0500 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <3BCA153D-BAE9-47B1-9A4E-70EDB09038B6@oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <173536F2-C957-4454-97A6-F49FEBD2B156@oracle.com> <563919D0.4050406@Oracle.com> <3BCA153D-BAE9-47B1-9A4E-70EDB09038B6@oracle.com> Message-ID: <56392A2A.5000003@Oracle.com> Hi Mandy, A couple of followups below... On 11/3/2015 4:18 PM, Mandy Chung wrote: >> On Nov 3, 2015, at 12:32 PM, Roger Riggs wrote: >> >> Hi Mandy, >> >> On 11/2/2015 2:53 PM, Mandy Chung wrote: >>>> On Oct 20, 2015, at 11:28 AM, Roger Riggs >>>> wrote: >>>> >>>> Updated Javadoc: >>>> >>>> http://cr.openjdk.java.net/~rriggs/cleaner-doc/ >>> I?m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: >>> 1. For an existing finalizer (say cleanup function), it will be replaced with >>> Cleaner.create().phantomCleanable(this, this::cleanup); >>> >> Not quite, It can't reference this; the cleanup method must not have any reference to the object >> being cleaned up because the Cleanable holds a strong reference to the cleanup state and would keep >> it from being xxx unreachable. >> The cleaning function must only refer to the state (and behavior) that does the cleaning. >> It could be a static method with all the state in the arguments. >> Or a instance method on a object holding only the cleanup state. > Right. This was just used as an example (I didn?t pay attention to its correctness) to lead to the comments below. > >>> It may be useful to provide a sharable Cleaner instance that doesn?t go away. >>> >> yes, for the use cases in java.base, there will be a common cleaner in the jdk.internal.misc package. > Should the API provide a sharable Cleaner instance for application/library to use if they want to avoid one cleaner for each library? It seemed like it might be an attractive nuisance because there could be interference between the Cleaning functions using a single Thread context. Some might be tolerant of long delays (For example, closing a network connections vs. others that might want to clear some state. For use within java.base, it would not be robust to use a Cleaner thread shared with applications. A shared cleaner could be added later if there there is a use case for it. > >>> The primary use for this Cleaner API is to replace finalizers. I wonder it worths having a convenient method easier to relate to finalizer (say Cleaner.finalizable?) >>> >> Not just finalizers; I would stay away from the term finalizer to avoid overloading the understanding. >> Finalization is specific specification defined semantics. >>> 2. Do you know any existing use of soft / weak references in the JDK can benefit from this automatic cleanup mechanism? The typical cache implementation using soft/weak references is to purge the entries when the cache is accessed and manages the reference queue without a background thread. >>> >> Peter Levart offered an example of a self cleaning Weak key'ed collection. >> It would be nice to have a ConcurrentHashMap with Weak keys. > Agree. When there is ConcurrentHashMap with Weak keys, would this weakCleanable be used for other use cases (that?s the part unclear to me). > >>> I?m in two minds that it sounds sensible for this Cleaner API to extend for soft/weak references whereas I am not certain of the use cases. Anyone can share the known use cases that would be helpful. >>> >> Besides the cases already mentioned on the thread... Anyone? A developer at JavaOne wanted more control over the policy for clearing SoftReferences possibly taking into account the cost of creating the cache entry. A technique I proposed was to use a SoftReference, not for the cached resource itself but as a sentinel for the VM needing to free 'soft' memory. One possible use for a SoftCleaner is to implement a sensible cleaning strategy for a Cache. The CleaningFunction was would be triggered when freeing SoftReferences was needed by VM GC policy and could be used as a hook to use its own algorithm to free some of its cached values. >> >>>> Updated Webrev: >>>> >>>> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ >>> 57 final PhantomCleanable phantomCleanableList; >>> 59 final WeakCleanable weakCleanableList; >>> 61 final SoftCleanable softCleanableList; >>> >>> - is there any benefit of keeping separate list for each reference type? Each cleaner has one single ReferenceRueue and it seems that keeping one single Cleanable list could achieve similar performance in most cases while the implementation might be simplified. >>> >> Since each type has to extend the corresponding Reference subtype; the code was easier to understand and maintain with separate queues. There were several iterations using different approaches suggested during the earlier reviews. > OK. I didn?t review all iterations. > > The remaining open question is whether the Cleaner API should support weakCleanable and softCleanable or keep it for phantom cleanable only. > > Mark will likely have input to this. See above. Thanks, Roger > > >>> >>> 111 thread.setPriority(Thread.MAX_PRIORITY); >>> >>> VM threads are near max priority. The reference handler thread is MAX_PRORITY whereas the finalizer thread is MAX_PRIORITY-2. >>> >> I'll change it to be equal to the finalizer priority; MAX_PRIORITY - 2 for the default ThreadFactory >>> I think the cleaner thread should not be of MAX_PRIORITY and also perhaps the caller may need a way to get the thread associated with a Cleaner so that users can set the priority if needed? >> The priority should be set by the ThreadFactory; if an application needs to control the thread >> it can/should provide a custom ThreadFactory; that will keep the API clean. >> >> The setting of the default thread priority should be in the default thread factory. >> > Did I look at an older webrev? The version I looked at - CleanerImpl changes the thread priority after ThreadFactory creates it: > > Thread thread = threadFactory.newThread(this); > thread.setPriority(Thread.MAX_PRIORITY); > > Anyway the ThreadFactory setting the priority is good and reflected in your new webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ > > Mandy > From david.lloyd at redhat.com Tue Nov 3 22:08:59 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 3 Nov 2015 16:08:59 -0600 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> References: <5638AC76.4080603@gmail.com> <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> Message-ID: <5639307B.6040501@redhat.com> On 11/03/2015 03:33 PM, Mandy Chung wrote: > >> On Nov 3, 2015, at 4:45 AM, Peter Levart wrote: >> >> Hi Mandy, >> >> Great API. >> >> One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: >> >> walk((s) -> s.map(StackFrame::getDeclaringClass) >> .skip(2) >> .findFirst()).orElse(Thread.currentThread().getClass()); >> >> ... the .orElse is presumably meant for the case when getCallerClass() is called directly from within Thread.run() method right? In that case Thread's implementation class is presented as the one doing the invocation of Thread.run(), which seems logical. >> >> But what about if getCallerClass() is called from a method that has been invoked from native code via JNI in a newly attached thread that was not started in Java (like the main method)? We will also get the Thread's implementation class as the caller. Is this still logical? > > That should be Thread.class. > >> >> What would it be if getCallerClass() returned just Optional> and was left to the user to decide what to do in corner cases when there is no Java caller? >> > > I considered Optional>. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native. Most common cases will find a caller class. Returning an Optional will force most common uses to handle the case if it?s absent. It?s a tradeoff that I think it?s better to return Thread.class for the JNI attached thread calling getCallerClass in native which would rarely happen. I'll say it: I don't think the world will fall apart if it just returns null when there's no caller. Some might even consider that to be intuitive. >> So returning java.lang.Class objects is safe now there is jigsaw to enforce isolation when doing reflection on them. It's great to see how things fall together nicely. > > Yup. I?m really looking forward to the strong encapsulation that strengthens the security. I think Class objects are safe even without the weird new isolation rules, but that's a discussion for another mailing list :) -- - DML From daniel.daugherty at oracle.com Tue Nov 3 22:42:08 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 3 Nov 2015 15:42:08 -0700 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" In-Reply-To: <5638F2BB.8020203@oracle.com> References: <5638F2BB.8020203@oracle.com> Message-ID: <56393840.5040208@oracle.com> On 11/3/15 10:45 AM, Alejandro E Murillo wrote: > Please review these changes: > > bug: https://bugs.openjdk.java.net/browse/JDK-8139986 > Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ jdk/src/java.base/share/classes/sun/misc/Version.java.template nit: L103: if (jdk_debug_level.startsWith("release") ) Please delete extra space between right parens. Also, looks like other single line if-statements in this file uses this format: if (expr) { statement; } jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java No comments. hotspot/make/aix/makefiles/vm.make No comments. hotspot/make/bsd/makefiles/vm.make No comments. hotspot/make/linux/makefiles/vm.make No comments. hotspot/make/solaris/makefiles/vm.make No comments. hotspot/make/windows/makefiles/defs.make No comments. hotspot/make/windows/makefiles/vm.make No comments. hotspot/make/windows/projectfiles/common/Makefile No comments. hotspot/src/share/vm/runtime/arguments.cpp No comments. hotspot/src/share/vm/runtime/statSampler.cpp No comments. hotspot/src/share/vm/runtime/vm_version.cpp nit L68 #error DEBUG_LEVEL must be defined Please delete the extra space before "must be..." hotspot/src/share/vm/runtime/vm_version.hpp No comments. hotspot/test/testlibrary/jdk/test/lib/Platform.java No comments. Thumbs up. If you fix the minor style issues above, I don't need to see another webrev. Dan > > Background: > These changes introduce a new system property named "jdk.debug" > intended to > identify the type of the build. The build system has already been > modified (see [1]) > to provide the build type through the "--with-debug-level" configure > option, > and to remove that info from the (new) version string and > consequently from the "java.version" and "java.vm.version" system > properties. > > Here, the configure debug level is used to initialize the value of the > "jdk.debug" system > property. There are also changes to adapt any code that relied on the > value of those version > properties to determine the build type. They were changed to use this > new property. > > The Launcher output was also modified to look as follows: > > jdk.debug = (?*foo*? != ?release?) > $java -version > java version "9-ea" > Java(TM) SE Runtime Environment (*foo *build 9-ea+88) > Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, > mixed mode) > > jdk.debug = ?release?: (no change) > > $java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+88) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) > > > All this will be described and updated in the JEP-223 doc [2] shortly. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139951 > [2] http://openjdk.java.net/jeps/223 > > Thanks > From alejandro.murillo at oracle.com Wed Nov 4 00:11:35 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 03 Nov 2015 17:11:35 -0700 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" In-Reply-To: <56393840.5040208@oracle.com> References: <5638F2BB.8020203@oracle.com> <56393840.5040208@oracle.com> Message-ID: <56394D37.5020000@oracle.com> On 11/3/2015 3:42 PM, Daniel D. Daugherty wrote: > On 11/3/15 10:45 AM, Alejandro E Murillo wrote: >> Please review these changes: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8139986 >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ > > jdk/src/java.base/share/classes/sun/misc/Version.java.template > nit: L103: if (jdk_debug_level.startsWith("release") ) > Please delete extra space between right parens. > will fix that > Also, looks like other single line if-statements in > this file uses this format: > > if (expr) { > statement; > } right, will also fix that thanks Dan! Alejandro > > jdk/test/lib/testlibrary/jdk/testlibrary/Platform.java > No comments. > > hotspot/make/aix/makefiles/vm.make > No comments. > > hotspot/make/bsd/makefiles/vm.make > No comments. > > hotspot/make/linux/makefiles/vm.make > No comments. > > hotspot/make/solaris/makefiles/vm.make > No comments. > > hotspot/make/windows/makefiles/defs.make > No comments. > > hotspot/make/windows/makefiles/vm.make > No comments. > > hotspot/make/windows/projectfiles/common/Makefile > No comments. > > hotspot/src/share/vm/runtime/arguments.cpp > No comments. > > hotspot/src/share/vm/runtime/statSampler.cpp > No comments. > > hotspot/src/share/vm/runtime/vm_version.cpp > nit L68 #error DEBUG_LEVEL must be defined > Please delete the extra space before "must be..." > > hotspot/src/share/vm/runtime/vm_version.hpp > No comments. > > hotspot/test/testlibrary/jdk/test/lib/Platform.java > No comments. > > > Thumbs up. If you fix the minor style issues above, > I don't need to see another webrev. > > Dan > > >> >> Background: >> These changes introduce a new system property named "jdk.debug" >> intended to >> identify the type of the build. The build system has already been >> modified (see [1]) >> to provide the build type through the "--with-debug-level" configure >> option, >> and to remove that info from the (new) version string and >> consequently from the "java.version" and "java.vm.version" system >> properties. >> >> Here, the configure debug level is used to initialize the value of >> the "jdk.debug" system >> property. There are also changes to adapt any code that relied on the >> value of those version >> properties to determine the build type. They were changed to use >> this new property. >> >> The Launcher output was also modified to look as follows: >> >> jdk.debug = (?*foo*? != ?release?) >> $java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (*foo *build 9-ea+88) >> Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, >> mixed mode) >> >> jdk.debug = ?release?: (no change) >> >> $java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+88) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) >> >> >> All this will be described and updated in the JEP-223 doc [2] shortly. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8139951 >> [2] http://openjdk.java.net/jeps/223 >> >> Thanks >> > -- Alejandro From weijun.wang at oracle.com Wed Nov 4 01:24:41 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Nov 2015 09:24:41 +0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: References: <561ED8BF.40901@oracle.com> <561F16C1.6090702@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> Message-ID: <4B1D129A-8D55-4EF1-A017-AB98A68D9847@oracle.com> Curious that you added a new method called jarFile.getRuntimeVersionedEntry(entryName). Is this the *only* method you would call for a multi-release jar? If so, is it still necessary to modify the old getEntry() method? Thanks Max > On Nov 4, 2015, at 1:11 AM, Steve Drach wrote: > > Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > From steve.drach at oracle.com Wed Nov 4 02:41:40 2015 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 3 Nov 2015 18:41:40 -0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <4B1D129A-8D55-4EF1-A017-AB98A68D9847@oracle.com> References: <561ED8BF.40901@oracle.com> <561F16C1.6090702@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> <4B1D129A-8D55-4EF1-A017-AB98A68D9847@oracle.com> Message-ID: <30BE9596-B674-457B-ACB5-03A8141F2777@oracle.com> > On Nov 3, 2015, at 5:24 PM, Wang Weijun wrote: > > Curious that you added a new method called jarFile.getRuntimeVersionedEntry(entryName). It?s new to JarFile, but not new to the changeset, it?s been in there since the reviews started. > Is this the *only* method you would call for a multi-release jar? No, it?s a method we had to add to support runtime versioning for the Class.getResource() method. We either had to set runtime versioning for all JarFiles obtained from a JarURLConnection or set it specifically for a resource entry retrieved by the Class.getResource() method, that uses a JarURLConnection. It?s a rather convoluted path through the system, but it you follow it, you?ll see what we did and how ? look at the changes for JarURLConnection. It?s a rather specialized method that I wish could be private, but it can?t be. Having said that, someone might find a use for it. It?s equivalent to JarFile.setRuntimeVersioned().getJarEntry(), but it doesn?t set a permanent versioning strategy for the JarFile. See MultiReleaseJarProperties testRuntimeVersioning test. > If so, is it still necessary to modify the old getEntry() method? Yes, for general entry retrieval as well as for loading classes. > > Thanks > Max > >> On Nov 4, 2015, at 1:11 AM, Steve Drach wrote: >> >> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >> > From joe.darcy at oracle.com Wed Nov 4 02:48:54 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 3 Nov 2015 18:48:54 -0800 Subject: JDK 9 RFR of JDK-8141359: @Deprecated on packages should be clarified Message-ID: <56397216.1000003@oracle.com> Hello, Please review the short patch below to address JDK-8141359: @Deprecated on packages should be clarified --- a/src/java.base/share/classes/java/lang/Deprecated.java Tue Nov 03 17:41:38 2015 -0800 +++ b/src/java.base/share/classes/java/lang/Deprecated.java Tue Nov 03 18:47:38 2015 -0800 @@ -36,7 +36,7 @@ * *

Use of the @Deprecated annotation on a local variable * declaration or on a parameter declaration or a package declaration - * has no effect. + * has no effect on the warnings issued by a compiler. * * @author Neal Gafter * @since 1.5 Thanks, -Joe From mandy.chung at oracle.com Wed Nov 4 02:59:02 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Nov 2015 18:59:02 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5639307B.6040501@redhat.com> References: <5638AC76.4080603@gmail.com> <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> <5639307B.6040501@redhat.com> Message-ID: > On Nov 3, 2015, at 2:08 PM, David M. Lloyd wrote: > >> I considered Optional>. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native. Most common cases will find a caller class. Returning an Optional will force most common uses to handle the case if it?s absent. It?s a tradeoff that I think it?s better to return Thread.class for the JNI attached thread calling getCallerClass in native which would rarely happen. > > I'll say it: I don't think the world will fall apart if it just returns null when there's no caller. Some might even consider that to be intuitive. I think there is no real issue to return Thread.class either, right? Mandy From mandy.chung at oracle.com Wed Nov 4 03:50:23 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Nov 2015 19:50:23 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <84FCE25A-8EB4-48C8-8F3E-D0BDFBF3D86D@oracle.com> References: <84FCE25A-8EB4-48C8-8F3E-D0BDFBF3D86D@oracle.com> Message-ID: > On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote: > > Hi Mandy, > > This is very nice work. > > Comments below, mostly minor stuff. > Thanks for the review. I fixed most of the comments below. One question: Is the name ?StackStream" inappropriate and its subtypes? I prefer StackStream to StackTraverser. > > PlatformLogger.java > (and similar comments for duplicated code in LogRecord.java) > ? > > 542 static final StackWalker stackWalker; > > Use capitals for static variable. > Fixed. > > 556 private boolean lookingForLogger = true; > 557 /** > > Missing line-feed. > Fixed. > > 588 private String getCallerInfo() { > 589 Optional frame = new CallerFinder().get(); > 590 if (frame.isPresent()) { > 591 StackWalker.StackFrame f = frame.get(); > 592 return f.getClassName() + " " + f.getMethodName(); > 593 } else { > 594 return name; > 595 } > 596 } > > > Consider using: > > return frame.map(f -> f.getClassName() + " " + f.getMethodName()).orElse(name); > Thanks for the nicer alternative. > You might want to highlight that CallerFinder is a stateful predicate. > > > LogRecord.java > ? > > 642 // Skip all frames until we have found the first logger frame. > 643 Optional frame = new CallerFinder().get(); > 644 if (frame.isPresent()) { > 645 StackWalker.StackFrame f = frame.get(); > 646 setSourceClassName(f.getClassName()); > 647 setSourceMethodName(f.getMethodName()); > 648 } > 649 // We haven't found a suitable frame, so just punt. This is > 650 // OK as we are only committed to making a "best effort" here. > 651 } > > Consider using: > > frame.ifPresent(f -> { > setSourceClassName(f.getClassName()); > setSourceMethodName(f.getMethodName()); > }); > Fixed. > > LiveStackFrame > ? > > 41 /** > 42 * Return the monitors held by this stack frames. This method returns > 43 * an empty array if no monitor is held by this stack frame. > 44 * > 45 * @return the monitors held by this stack frames > 46 */ > 47 public Object[] getMonitors(); > > s/this stack frames/stack frame > > Can the contents of the array be modified? > > Yes this can be modified. Each stack frame has its own arrays. > 49 /** > 50 * Gets the local variable array of this stack frame. > 51 * > 52 *

A single local variable can hold a value of type boolean, byte, char, > 53 * short, int, float, reference or returnAddress. A pair of local varaibles > 54 * can hold a value of type long or double. In other words, > 55 * a value of type long or type double occupies two consecutive local > 56 * variables. For a value of primitive type, the element in the > 57 * local variable array is an {@link PrimitiveValue} object; > 58 * otherwise, the element is an {@code Object}. > 59 * > 60 *

A value of type long or double will be represented by > 61 * a {@code PrimitiveValue} object containing the value in the elements > 62 * at index n and n+1 in the local variable array. > 63 * > 64 * @return the local variable array of this stack frame. > 65 */ > 66 public Object[] getLocals(); > > s/varaibles/variables > > (double slots are a PITA!) > Yes it is. > > StackStream > ? > > Suggest using something other than Stream in the name is this is really about Spliterator and traversal e.g. perhaps StackTraverser. Same for sub-types of StackStream. > > 494 @Override > 495 public void forEachRemaining(Consumer action) { > 496 throw new UnsupportedOperationException("Specialized StackWalker"); > 497 } > 498 > 499 @Override > 500 public boolean tryAdvance(Consumer action) { > 501 throw new UnsupportedOperationException("Specialized StackWalker"); > 502 } > > Is this required? > CallerClassStream and StackTrace don?t support to use with Stream API for performance. > > StackWalker > ? > > 46 * The {@linkplain Stream#spliterator() spliterator} of the stream performs > 47 * the stack frame traversal in an {@linkplain Spliterator#ORDERED ordered} manner. > > It?s probably best not to mention Spliterator. Suggest > > the stream reports stack frame elements in order, from the top most frame that represents the execution point at > which the stack was generated to the bottom most frame... > > > 64 *

Examples > > Use an @apiNote > > > 82 public final class StackWalker { > 83 /** > 84 * A {@code StackFrame} object represent a method invocation returned by > 85 * {@link StackWalker}. > > > s/object represent/object represents > > > 87 *

{@code StackFrame} objects returned by {@link StackWalker} may not implement > 88 * the {@link #getDeclaringClass()} method > 89 * depending on the requested {@linkplain Option stack walking options}. > > Rather than "may not implement? suggest something like: > > The getDeclaring class method may be unsupported as determined by the stack walking options of a stack walker. > > > 118 * @throws UnsupportedOperationException if this {@code StackFrame} > 119 * does not implement this method > > if this StackFrame does not support? as determined by ? > > > 137 public String getFileName(); > 138 /** > > Missing line-feed. > > > 151 /** > 152 * Returns true if the method containing the execution point > 153 * represented by this stack frame is a native method. > 154 * > 155 * @return {@code true} if the method containing the execution point > 156 * represented by this stack frame is a native method. > 157 */ > 158 public boolean isNativeMethod(); > > Consistently use {@code true} > > > 160 /** > 161 * Gets a {@code StackTraceElement} for this stack frame. > 162 * > 163 * @apiNote This method does not seem to be needed as user could simply > 164 * use StackFrame methods directly. > 165 * > 166 * @return {@code StackTraceElement} for this stack frame. > 167 * > 168 * */ > 169 public default StackTraceElement asStackTraceElement() { > > I guess that @apiNote is a TODO? Perhaps remove it if you think it is not needed, unless it is useful for compatibility reasons, it might be e.g. consider map(StackFrame::asStackTraceElement) > > > > 238 private final List options; > > Do you require the bound here? > Sorry WalkerOption has been removed. I only updated the API but not webrev.00. > > 241 /** > 242 * Gets a {@code StackWalker} instance. > 243 * > 244 *

This {@code StackWalker} obtains the method name and the class name > 245 * with all {@linkplain StackWalker.Option#SHOW_HIDDEN_FRAMES hidden frames} > 246 * skipped. > 247 */ > 248 public StackWalker() { > > s/Gets/Creates > > Same for other constructor methods. > > > 252 /** > 253 * Gets a {@code StackWalker} instance with the given options specifying > 254 * the stack frame information it can access. If no option is specified, this > 255 * {@code StackWalker} obtains the method name and the class name > 256 * with all {@linkplain StackWalker.Option#SHOW_HIDDEN_FRAMES hidden frames} > 257 * skipped. > > If no options are given? > > It might be easier to state as if the options were {CLASS_REFERENCE, SHOW_REFLECT_FRAMES}, perhaps it depends if the default is someone under specified i.e. is it guaranteed that the option set will be the complement of the single set SHOW_HIDDEN_FRAMES? In fact the default can?t be expressed with the current options. This is a good point though and I have been considering adding SHOW_METHOD_INFO which will be the default. I?ll update the API. > > I guess any unrecognized options are ignored? > Now it takes only Option enums. > > 324 /** > 325 * Applies the given function to the stream of {@code StackFrame}s > 326 * for the current thread, traversing from the top of the stack, > 327 * which is the method calling this method. > 328 * > 329 *

To find the first 10 calling frames, first skipping those frames whose > 330 * declaring class belong to package {@code com.foo}: > 331 *

> 332 * 
{@code List frames = new StackWalker().walk((s) ->}
> 
> } -> {
> 
> 333      *     s.dropWhile(f -> f.getClassName().startsWith("com.foo."))
> 334      *      .limit(10)
> 335      *      .collect(Collectors.toList()));
> 336      *
> 337 * @apiNote The {@code Stream} object will be closed when > 338 * this method returns. When a closed {@code Stream} object > 339 * is reused, {@code IllegalStateException} will be thrown. > > Yay, dropWhile :-) > > Use an @apiNote for the example, the original note is i think normative. > > Probably need to mention that parallel execution will is effectively disabled and stream pipeline execution will only occur on the current thread. > > > > 402 @CallerSensitive > 403 public T walk(Function, T> function, > 404 Function batchSizeMapper) { > > Can you use IntUnaryOperator? > Remi and David suggest that too. > > 430 /** > 431 * Gets the {@code Class} object of the caller invoking the method > 432 * that calls this {@code getCallerClass} method. > 433 * > 434 *

This is equivalent to calling > 435 *

> 436 * 
{@code walk((s) ->}
> 
> } -> {
> 
> 437      *     s.map(StackFrame::getDeclaringClass)
> 438      *      .skip(2)
> 439      *      .findFirst()).orElse(Thread.currentThread().getClass());
> 440      *
> > > 441 * > 442 *

For example, {@code Util::getResourceBundle} loads a resource bundle on behalf > 443 * of the caller. It calls this {@code getCallerClass} method to find the method > 444 * calling {@code Util::getResourceBundle} and use the caller's class loader to > 445 * load the resource bundle. The caller class in this example is the {@code Foo} class. > > > use @apiNote > > > BatchSizeMapper > ? > > As usual i always advice using testng and data providers, up to you. I started this one with TestNG but this data provider requires the method to return Object[][]. I automatically resorted to old-school test :) > > 105 return frameCount = stream > 106 .map(f -> { > 107 if (verbose) System.out.println(f); > 108 return f; > 109 }) > > You can use peek instead. > > > GetCallerClassTest > ? > > 105 class Test1 { > 106 static void test() { > 107 GetCallerClassTest.staticGetCallerClass(Test1.class); > 108 GetCallerClassTest.reflectiveGetCallerClass(Test1.class); > 109 } > 110 } > 111 > 112 class Test2 { > 113 static void test() { > 114 GetCallerClassTest.staticGetCallerClass(Test2.class); > 115 GetCallerClassTest.reflectiveGetCallerClass(Test2.class); > 116 } > 117 } > > > Duplicate tests? > Probably extra-caution and can be removed. > Suggest renaming tests because on failure it might easier to understand what failed. > Right - I have to review the tests one more pass before posting the updated webrev. > > HiddenFrames > ? > > 64 void walk() { > 65 Arrays.stream(new int[]{0}) > 66 .forEach(i -> walker.walk(s -> { > 67 s.forEach(this::checkFrame); > 68 return null; > 69 })); > > Can you use Stream.of(0).forEach instead. > Yes Stream.of is better. > > Ran out of time :-) Thanks a lot. Mandy From david.holmes at oracle.com Wed Nov 4 03:52:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Nov 2015 13:52:35 +1000 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" In-Reply-To: <5638F2BB.8020203@oracle.com> References: <5638F2BB.8020203@oracle.com> Message-ID: <56398103.3000105@oracle.com> Looks good to me! Thanks, David On 4/11/2015 3:45 AM, Alejandro E Murillo wrote: > Please review these changes: > > bug: https://bugs.openjdk.java.net/browse/JDK-8139986 > Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ > > Background: > These changes introduce a new system property named "jdk.debug" intended to > identify the type of the build. The build system has already been > modified (see [1]) > to provide the build type through the "--with-debug-level" configure > option, > and to remove that info from the (new) version string and > consequently from the "java.version" and "java.vm.version" system > properties. > > Here, the configure debug level is used to initialize the value of the > "jdk.debug" system > property. There are also changes to adapt any code that relied on the > value of those version > properties to determine the build type. They were changed to use this > new property. > > The Launcher output was also modified to look as follows: > > jdk.debug = (?*foo*? != ?release?) > $java -version > java version "9-ea" > Java(TM) SE Runtime Environment (*foo *build 9-ea+88) > Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, > mixed mode) > > jdk.debug = ?release?: (no change) > > $java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+88) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) > > > All this will be described and updated in the JEP-223 doc [2] shortly. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139951 > [2] http://openjdk.java.net/jeps/223 > > Thanks > From alejandro.murillo at oracle.com Wed Nov 4 06:13:12 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 03 Nov 2015 23:13:12 -0700 Subject: [verona.stage] RFR 8139986: Store debug level in java.vm.debug and conditionally print in "java -version" In-Reply-To: <56398103.3000105@oracle.com> References: <5638F2BB.8020203@oracle.com> <56398103.3000105@oracle.com> Message-ID: <5639A1F8.4010403@oracle.com> Thanks David! Alejandro On 11/3/2015 8:52 PM, David Holmes wrote: > Looks good to me! > > Thanks, > David > > On 4/11/2015 3:45 AM, Alejandro E Murillo wrote: >> Please review these changes: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8139986 >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8139986/ >> >> Background: >> These changes introduce a new system property named "jdk.debug" >> intended to >> identify the type of the build. The build system has already been >> modified (see [1]) >> to provide the build type through the "--with-debug-level" configure >> option, >> and to remove that info from the (new) version string and >> consequently from the "java.version" and "java.vm.version" system >> properties. >> >> Here, the configure debug level is used to initialize the value of the >> "jdk.debug" system >> property. There are also changes to adapt any code that relied on the >> value of those version >> properties to determine the build type. They were changed to use this >> new property. >> >> The Launcher output was also modified to look as follows: >> >> jdk.debug = (?*foo*? != ?release?) >> $java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (*foo *build 9-ea+88) >> Java HotSpot(TM) 64-Bit Server VM (*foo *build 9-ea+88, >> mixed mode) >> >> jdk.debug = ?release?: (no change) >> >> $java -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+88) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+88, mixed mode) >> >> >> All this will be described and updated in the JEP-223 doc [2] shortly. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8139951 >> [2] http://openjdk.java.net/jeps/223 >> >> Thanks >> -- Alejandro From peter.levart at gmail.com Wed Nov 4 08:06:59 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 Nov 2015 09:06:59 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> References: <5638AC76.4080603@gmail.com> <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> Message-ID: <5639BCA3.9040502@gmail.com> On 11/03/2015 10:33 PM, Mandy Chung wrote: >> On Nov 3, 2015, at 4:45 AM, Peter Levart wrote: >> >> Hi Mandy, >> >> Great API. >> >> One thing I noticed is method StackWalker.getCallerClass() which is described as equivalent to the following: >> >> walk((s) -> s.map(StackFrame::getDeclaringClass) >> .skip(2) >> .findFirst()).orElse(Thread.currentThread().getClass()); >> >> ... the .orElse is presumably meant for the case when getCallerClass() is called directly from within Thread.run() method right? In that case Thread's implementation class is presented as the one doing the invocation of Thread.run(), which seems logical. >> >> But what about if getCallerClass() is called from a method that has been invoked from native code via JNI in a newly attached thread that was not started in Java (like the main method)? We will also get the Thread's implementation class as the caller. Is this still logical? > That should be Thread.class. Yes, but is this always the right choice? > >> What would it be if getCallerClass() returned just Optional> and was left to the user to decide what to do in corner cases when there is no Java caller? >> > I considered Optional>. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native. Most common cases will find a caller class. Returning an Optional will force most common uses to handle the case if it?s absent. It?s a tradeoff that I think it?s better to return Thread.class for the JNI attached thread calling getCallerClass in native which would rarely happen. I was not thinking of calling StackWalker::getCallerClass from native, but calling some method from native, which then calls StackWalker::getCallerClass. The method itself can not anticipate how it will be called. Most methods calling getCallerClass will assume their caller is a Java method and won't bother to think of consequences when this is not the case. But any method can be called from native code in a newly attached thread. I'm not saying this is common, but can happen. So the question is whether Thread.class is always the right substitute in such situations and whether it would be better to return null or Optional.empty(). If you don't want to force users to handle the uncommon case then perhaps it's best to return null. They will get NPE in the uncommon case and will be forced to handle it as opposed to using Thread.class which might silently "work", but not do the right thing. Regards, Peter > > >> So returning java.lang.Class objects is safe now there is jigsaw to enforce isolation when doing reflection on them. It's great to see how things fall together nicely. > Yup. I?m really looking forward to the strong encapsulation that strengthens the security. > Mandy From peter.levart at gmail.com Wed Nov 4 08:21:40 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 Nov 2015 09:21:40 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5639BCA3.9040502@gmail.com> References: <5638AC76.4080603@gmail.com> <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> <5639BCA3.9040502@gmail.com> Message-ID: <5639C014.9030706@gmail.com> On 11/04/2015 09:06 AM, Peter Levart wrote: >>> What would it be if getCallerClass() returned just >>> Optional> and was left to the user to decide what to do in >>> corner cases when there is no Java caller? >>> >> I considered Optional>. I believe it is rare to have a JNI >> attached thread calling StackWalker::getCallerClass from native. >> Most common cases will find a caller class. Returning an Optional >> will force most common uses to handle the case if it?s absent. It?s >> a tradeoff that I think it?s better to return Thread.class for the >> JNI attached thread calling getCallerClass in native which would >> rarely happen. > > I was not thinking of calling StackWalker::getCallerClass from native, > but calling some method from native, which then calls > StackWalker::getCallerClass. The method itself can not anticipate how > it will be called. Most methods calling getCallerClass will assume > their caller is a Java method and won't bother to think of > consequences when this is not the case. But any method can be called > from native code in a newly attached thread. I'm not saying this is > common, but can happen. > > So the question is whether Thread.class is always the right substitute > in such situations and whether it would be better to return null or > Optional.empty(). If you don't want to force users to handle the > uncommon case then perhaps it's best to return null. They will get NPE > in the uncommon case and will be forced to handle it as opposed to > using Thread.class which might silently "work", but not do the right > thing. ... additionaly, Thread.class (or a subclass) can not be reliably used as a sentinel value to identify such uncommon cases because it can sometimes be a legal caller, as in: public class StackWalkerDemo { public static void doIt() { StackWalker sw = new StackWalker(StackWalker.Option.CLASS_REFERENCE); System.out.println("I was called from: " + sw.getCallerClass()); } public static void main(String[] args) throws Exception { Thread t = new Thread(StackWalkerDemo::doIt); t.start(); t.join(); } } Regards, Peter From michael.haupt at oracle.com Wed Nov 4 08:39:16 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 4 Nov 2015 09:39:16 +0100 Subject: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev In-Reply-To: References: Message-ID: <52A380C7-D34D-4C35-82C1-0C0A78E1F5EC@oracle.com> All, the code in question has been reviewed already: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031871.html Best, Michael > Am 02.11.2015 um 09:12 schrieb Michael Haupt : > > (Apologies for multiple posts with wrong subject lines.) > >> Dear all, >> >> cross-posted to jdk8u-dev and core-libs-dev. >> >> Please review this change. >> Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 >> Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00 >> >> This adds a missing test to 8u-dev that was not pushed along with the feature backport it belongs to. The backport was approved; see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html . >> >> Thanks, >> >> Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From paul.sandoz at oracle.com Wed Nov 4 08:46:16 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Nov 2015 09:46:16 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: <84FCE25A-8EB4-48C8-8F3E-D0BDFBF3D86D@oracle.com> Message-ID: > On 4 Nov 2015, at 04:50, Mandy Chung wrote: > > >> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote: >> >> Hi Mandy, >> >> This is very nice work. >> >> Comments below, mostly minor stuff. >> > > Thanks for the review. > > I fixed most of the comments below. One question: > > Is the name ?StackStream" inappropriate and its subtypes? I prefer StackStream to StackTraverser. > I think using Stream in the name gives the wrong impression. It?s not a subtype of j.u.Stream, it?s the thing that is used as a source for a Stream, in some cases. IIUC it?s really two things, a form of Spliterator that supports sequential traversal of stack elements via tryAdvanced/forEachRemaining, and a thing to directly query stack elements. > >> >> StackStream >> ? >> >> Suggest using something other than Stream in the name is this is really about Spliterator and traversal e.g. perhaps StackTraverser. Same for sub-types of StackStream. >> >> 494 @Override >> 495 public void forEachRemaining(Consumer action) { >> 496 throw new UnsupportedOperationException("Specialized StackWalker"); >> 497 } >> 498 >> 499 @Override >> 500 public boolean tryAdvance(Consumer action) { >> 501 throw new UnsupportedOperationException("Specialized StackWalker"); >> 502 } >> >> Is this required? >> > > CallerClassStream and StackTrace don?t support to use with Stream API for performance. Then perhaps those classes should implement those methods to throw USO? or there should be a sub-type which indicates Spliterator traversal is not supported? Then i think it becomes much clearer on what sub-types support what contract. Or maybe the Spliterator can be pushed down to sub-types that are used as the source for a Stream? (I have not re-looked into the details to how awkward this might become.) > >> >> 238 private final List options; >> >> Do you require the bound here? >> > > Sorry WalkerOption has been removed. I only updated the API but not webrev.00. > Ok, thats good! >> >> 241 /** >> 242 * Gets a {@code StackWalker} instance. >> 243 * >> 244 *

This {@code StackWalker} obtains the method name and the class name >> 245 * with all {@linkplain StackWalker.Option#SHOW_HIDDEN_FRAMES hidden frames} >> 246 * skipped. >> 247 */ >> 248 public StackWalker() { >> >> s/Gets/Creates >> >> Same for other constructor methods. >> >> >> 252 /** >> 253 * Gets a {@code StackWalker} instance with the given options specifying >> 254 * the stack frame information it can access. If no option is specified, this >> 255 * {@code StackWalker} obtains the method name and the class name >> 256 * with all {@linkplain StackWalker.Option#SHOW_HIDDEN_FRAMES hidden frames} >> 257 * skipped. >> >> If no options are given? >> >> It might be easier to state as if the options were {CLASS_REFERENCE, SHOW_REFLECT_FRAMES}, perhaps it depends if the default is someone under specified i.e. is it guaranteed that the option set will be the complement of the single set SHOW_HIDDEN_FRAMES? > > In fact the default can?t be expressed with the current options. This is a good point though and I have been considering adding SHOW_METHOD_INFO which will be the default. I?ll update the API. > Ok. >> >> I guess any unrecognized options are ignored? >> > > Now it takes only Option enums. > That?s better. > >> >> 430 /** >> 431 * Gets the {@code Class} object of the caller invoking the method >> 432 * that calls this {@code getCallerClass} method. >> 433 * >> 434 *

This is equivalent to calling >> 435 *

>> 436 * 
{@code walk((s) ->}
>> 
>> } -> {
>> 
>> 437      *     s.map(StackFrame::getDeclaringClass)
>> 438      *      .skip(2)
>> 439      *      .findFirst()).orElse(Thread.currentThread().getClass());
>> 440      *
>> >> >> 441 * >> 442 *

For example, {@code Util::getResourceBundle} loads a resource bundle on behalf >> 443 * of the caller. It calls this {@code getCallerClass} method to find the method >> 444 * calling {@code Util::getResourceBundle} and use the caller's class loader to >> 445 * load the resource bundle. The caller class in this example is the {@code Foo} class. >> >> >> use @apiNote >> >> >> BatchSizeMapper >> ? >> >> As usual i always advice using testng and data providers, up to you. > > I started this one with TestNG but this data provider requires the method to return Object[][]. I automatically resorted to old-school test :) > :-) it?s more of an annoyance, i often compose using a list then convert. I can help out if you like. IIRC it may also possible to return Iterable or Iterator i cannot remember, but don?t expect the TestNG documentation to tell you that!, you need to look into the source code to work that out. Paul. From paul.sandoz at oracle.com Wed Nov 4 09:01:10 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Nov 2015 10:01:10 +0100 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: References: <561ED8BF.40901@oracle.com> <561F16C1.6090702@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> Message-ID: <8E943A53-0D6A-4688-A3C8-B35D6EB99766@oracle.com> Hi Steve, Hi Steve, I don?t think we need to cache versioned entries (as we discussed a while back). For class loading it?s likely to increase memory costs without any performance benefit (if anything a performance decrease). It?s easy to add back later on if we have data that suggests otherwise. We can reduce the search space for searching for versioned entries by setting the lower bound of the base version to one minus the first Java major release that has runtime support for multi-release jar files i.e. 8 as it currently stands. 312 * @throws IllegalStateException if called after an entry has been read ? after an entry has been obtained (see ?.) You might need some further clarification in setVersioned/setRuntimeVersioned itself describing the lifecycle e.g. this method may be called one or more times after construction and before the first operation that obtains an entry, after which the jar file configuration?s is considered immutable, and subsequent calls to this method will result in an ISE. Paul. > On 3 Nov 2015, at 18:11, Steve Drach wrote: > > Please review the latest webrev that addresses the issue raised in Sherman?s comments below, with my comments interspersed in-line. The changes between this webrev and the last one are in the definition and use of the ismultiRelease() method and the introduction of a configuration lock, the boolean configured, that prevents setting the version after an entry has been read from the jar file. As a consequence of the configuration lock, I had to modify a couple tests and add a new one. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 > JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 > Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ > From forax at univ-mlv.fr Wed Nov 4 09:03:50 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Nov 2015 10:03:50 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> References: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> Message-ID: <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> Hi Paul, The use of BaseStream was just an example, here is another one that works only if the function first parameter type is declared as '? super Stream'. static Function, Integer> counter() { return stream::count; } ... StackWalker walker = ... int count = walker.walk(counter()); regards, R?mi ----- Mail original ----- > De: "Paul Sandoz" > Cc: core-libs-dev at openjdk.java.net > Envoy?: Lundi 2 Novembre 2015 13:44:24 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > I agree with Maurizio, the first signature is good enough. > > One could argue that it might be better to apply PECS since it would > encourage more consistent usage when it is actually required as all too > often it?s easy to forget, and then too late to change. However, i don?t > want to encourage the use of BaseStream since it was an unfortunate mistake > that this made public. > > Paul. > > > On 2 Nov 2015, at 13:26, Maurizio Cimadamore > > wrote: > > > > So, we have three potential signatures here: > > > > T walk(Function, T> function) //1 > > > > T walk(Function, ? extends T> function) > > //2 > > > > T walk(Function, R> > > function) //3 > > > > > > Under normal conditions (i.e. lambda parameter being passed to 'walk') I > > think all these signatures are fundamentally equivalent; (2) and (3) seem > > to have been designed for something like this: > > > > Number n = walk(s -> new Integer(1)); > > > > That is, the function returns something that is more specific w.r.t. what > > is expected in the return type of walk. But - in reality, if 'walk' > > returns an R that is a subtype of T (as in the third signature), then walk > > also returns a T (as R is a subtype of T), so the result value can be > > passed where a T is expected. > > > > The converse example: > > > > Integer n1 = walk(s -> (Number)null); > > > > Similarly fails on all three signatures. > > > > > > More generally, with all such signatures, T will always receive: > > > > * lower bound(s) (from the return value(s) of the lambda passed as a > > parameter to the 'walk' method) > > * one upper bound (from the target-type associated with the 'walk' call. > > > > Under such conditions, the upper bound will always be disregarded in favor > > of the lower bounds - meaning that instantiation of T will always be > > driven by what's inside the lambda. Signature (3) mentions different > > variables (R and T) but the end result is the same - as the bound says R > > extends T - meaning that lower bounds of R are propagated to T - leading > > to exactly the same situation. > > > > > > In other words, I don't think there are obvious examples in which the > > behavior of these three signatures will be significantly different - if > > the return type of 'walk' would have been a generic type such as List, > > the situation would have been completely different - with with a 'naked' > > T, I think the first signature is good enough, and the third is, in my > > opinion, making things harder than what they need to be. > > > > I think the second signature is not necessary, from a pure type-system > > perspective; but I guess one could make an argument for it, but purely in > > terms of consistency with other areas (after all, the second > > type-parameter of a Function is in a covariant position). > > > > I hope this helps. > > > > Maurizio > > > From paul.sandoz at oracle.com Wed Nov 4 09:57:41 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Nov 2015 10:57:41 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> References: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> Message-ID: <936ED23B-3BC9-4FFC-B2D6-3CC5E8D083C0@oracle.com> > On 4 Nov 2015, at 10:03, Remi Forax wrote: > > Hi Paul, > > The use of BaseStream was just an example, here is another one that works only if the function first parameter type is declared as '? super Stream'. > > static Function, Integer> counter() { > return stream::count; > } > > ... > StackWalker walker = ... > int count = walker.walk(counter()); > Good point. Damn, i don?t like wildcards :-) The following works fine: static Function, Long> counter() { return Stream::count; } But there could also cases where one is stuck using a wildcard: Function, Long> f = Stream::count; Paul. From sgehwolf at redhat.com Wed Nov 4 10:54:36 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Nov 2015 11:54:36 +0100 Subject: jmx-dev RFR 6425769: jmx remote bind address In-Reply-To: <5638C89F.2090406@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> Message-ID: <1446634476.3554.8.camel@redhat.com> Hi, Updated webrev with jtreg test in Java: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 I believe this updated webrev addresses all concerns and incorporates suggestions brought up by Jaroslav and Daniel. I'm still looking for a sponsor and a hotspot/servicability-dev reviewer. Could somebody maintaining javax.rmi.ssl have a look at this as well? Thank you! Cheers, Severin On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > On 2.11.2015 19:06, Severin Gehwolf wrote: > > Hi, > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > Hi, > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > Hi Severin, > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > that's > > > > a better alias than hotspot-dev for this kind of changes - > > > > maybe > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > I will let serviceability team members comment on the hotspot > > > > changes. > > > > > > > > ConnectorBootstrap.java > > > > > > > > I have one suggestion and one concern: > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > Factory) > > > > and > > > > ssf??(Server Socket Factory) variables rather than introduce > > > > the > > > > two > > > > new variables rmiServerSocketFactory and > > > > rmiClientSocketFactory. > > > > You might want to create a new boolean 'useSocketFactory' > > > > variable, > > > > if that makes the code more readable. > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > work, > > > > the client socket factory will be serialized and sent to the > > > > client > > > > side. This is problematic for interoperability, as the class > > > > may > > > > not > > > > present in the remote client - if the remote client is e.g. jdk > > > > 8. > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > doesn't do > > > > anything useful - so I would suggest to simply get rid of it, > > > > and > > > > only > > > > set the Server Socket Factory when SSL is not involved. > > > > Thanks. Fixed in updated webrev. > > > > > > Tests: > > > > > > > > Concerning the tests - we're trying to get rid of shell scripts > > > > rather than introducing new ones :-) > > > > Could the test be rewritten in pure java using the Process API? > > > > > > > > I believe there's even a test library that will let you do that > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > (see ProcessTools.java) > > > > It'll take me a bit to rewrite the test in pure Java, but should be > > fine. This is not yet fixed in the updated webrev. > > > > > > Other: > > > > > > > > Also - I believe the new option should be documented in: > > > > src/java.management/share/conf/management.properties > > > > Docs have been updated > > in src/java.management/share/conf/management.properties. > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > related > > > to javax.rmi.ssl - someone maintaining this library should also > > > comment here. > > > > > > Also, the change is introducing new API (system property) and > > > changing the existing one (adding SslRmiServerSocketFactory > > > public > > > constructors) so compatibility review process will have to be > > > involved. > > > > OK. What exactly is there for me to do? I'm not familiar with this > > process. Note that the intent would be to get this backported to > > JDK 8. > Not much for you. But for the potential Oracle sponsor this means she > will have to remember to go through some extra hoops before > integrating your patch. I see. Thanks for clarifying it. > -JB- > > > > > New webrev at: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > Thanks, > > Severin > > > > > -JB- > > > > > > > > best regards, > > > > > > > > -- daniel > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that the > > > > > JMX > > > > > agent > > > > > binds to the wildcard address by default, preventing users to > > > > > use > > > > > system properties for JMX agents on multi-homed hosts. Given > > > > > a > > > > > host > > > > > with local network interfaces, 192.168.0.1 and 192.168.0.2 > > > > > say, > > > > > it's > > > > > impossible to start two JMX agents binding to fixed ports but > > > > > to > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > The JDK would bind to all local interfaces by default. In the > > > > > above > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is that > > > > > the > > > > > second > > > > > Java process would get a "Connection refused" error because > > > > > another > > > > > process has already been bound to the specified JMX/RMI port > > > > > pairs. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425 > > > > > 769/ > > > > > 00/ > > > > > > > > > > Testing done: > > > > > jdk_jmx and jdk_management tests all pass after this change > > > > > (no > > > > > regressions). There is also a new JTREG test which fails > > > > > prior > > > > > this > > > > > change and passes after. Updates to the diagnostic command > > > > > have > > > > > been > > > > > tested manually. > > > > > > > > > > I understand that, if approved, the JDK and hotspot changes > > > > > should get > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > it's > > > > > only a > > > > > doc-update for the new JDK property in the relevant > > > > > diagnostic > > > > > command. > > > > > > > > > > Could someone please review and sponsor this change? Please > > > > > let > > > > > me know > > > > > if there are questions. > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > From adinn at redhat.com Wed Nov 4 11:02:13 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 4 Nov 2015 11:02:13 +0000 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: <5638AC76.4080603@gmail.com> <2A178701-DE52-4E92-9EEB-D5C65DF6F6E6@oracle.com> <5639307B.6040501@redhat.com> Message-ID: <5639E5B5.7060704@redhat.com> On 04/11/15 02:59, Mandy Chung wrote: > >> On Nov 3, 2015, at 2:08 PM, David M. Lloyd >> wrote: >> >>> I considered Optional>. I believe it is rare to have a >>> JNI attached thread calling StackWalker::getCallerClass from >>> native. Most common cases will find a caller class. Returning >>> an Optional will force most common uses to handle the case if >>> it?s absent. It?s a tradeoff that I think it?s better to return >>> Thread.class for the JNI attached thread calling getCallerClass >>> in native which would rarely happen. >> >> I'll say it: I don't think the world will fall apart if it just >> returns null when there's no caller. Some might even consider that >> to be intuitive. > > I think there is no real issue to return Thread.class either, right? I don't understand this comment. Several posters in this very thread have raised the issue that this fails to disambiguate cases where there is a caller frame belonging to Thread from those where there is no caller frame. Have you not recognised this ambiguity or are you discounting it? regards, Andrew Dinn ----------- From timo.kinnunen at gmail.com Wed Nov 4 11:19:47 2015 From: timo.kinnunen at gmail.com (Timo Kinnunen) Date: Wed, 4 Nov 2015 12:19:47 +0100 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> References: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> Message-ID: <5639e9d9.6a68c20a.60303.4d1c@mx.google.com> Hi, I tested your version of the wildcard counter and it appears to be incompatible with one possible signature of the StackWalker.walk method. Here?s my code. Please see the line with ERROR comment: static class StackWalker { static class StackFrame implements CharSequence { // ... } T walk(Function, ? extends T> function, IntUnaryOperator sizing) { return function.apply(Stream.of("one " + sizing.applyAsInt(1), "two" + sizing.applyAsInt(2)).map(StackFrame::new)); } T powerWalk(Function, T> function, IntUnaryOperator sizing) { return function.apply(Stream.of("one " + sizing.applyAsInt(1), "two" + sizing.applyAsInt(2)).map(StackFrame::new)); } } static Function, Long> wildCounter() { return Stream::count; } static Function, Long> tameCounter() { return Stream::count; } public static void main(String[] args) { Function, Long> tameCounter = tameCounter(); Function, Long> wildCounter = wildCounter(); Long counted1 = new StackWalker().walk(tameCounter, i -> i); Long counted2 = new StackWalker().walk(wildCounter, i -> i); Long counted3 = new StackWalker().powerWalk(tameCounter, i -> i); Long counted4 = new StackWalker().powerWalk(wildCounter, i -> i); // ERROR System.out.println(counted1 + counted2 + counted3 + counted4); } This may be a problem with javac, but it doesn?t exactly inspire confidence in me towards wildcards. More like it?s another example in a long-running pattern of bad behavior. The version by Paul Sandoz compiles without issues, no surprises there as usual. And this is what javac is telling me: Information:Using javac 1.8.0_65 to compile java sources Error:(77, 50) java: method powerWalk in class nonnulls.GenericTest.StackWalker cannot be applied to given types; required: java.util.function.Function,T>,java.util.function.IntUnaryOperator found: java.util.function.Function,java.lang.Long>,(i)->i reason: cannot infer type-variable(s) T (argument mismatch; java.util.function.Function,java.lang.Long> cannot be converted to java.util.function.Function,T>) Sent from Mail for Windows 10 From: Remi Forax Sent: Wednesday, November 4, 2015 10:04 To: Paul Sandoz Cc: core-libs-dev at openjdk.java.net Subject: Re: Proposed API for JEP 259: Stack-Walking API Hi Paul, The use of BaseStream was just an example, here is another one that works only if the function first parameter type is declared as '? super Stream'. static Function, Integer> counter() { return stream::count; } ... StackWalker walker = ... int count = walker.walk(counter()); regards, R?mi ----- Mail original ----- > De: "Paul Sandoz" > Cc: core-libs-dev at openjdk.java.net > Envoy?: Lundi 2 Novembre 2015 13:44:24 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > I agree with Maurizio, the first signature is good enough. > > One could argue that it might be better to apply PECS since it would > encourage more consistent usage when it is actually required as all too > often it?s easy to forget, and then too late to change. However, i don?t > want to encourage the use of BaseStream since it was an unfortunate mistake > that this made public. > > Paul. > > > On 2 Nov 2015, at 13:26, Maurizio Cimadamore > > wrote: > > > > So, we have three potential signatures here: > > > > T walk(Function, T> function) //1 > > > > T walk(Function, ? extends T> function) > > //2 > > > > T walk(Function, R> > > function) //3 > > > > > > Under normal conditions (i.e. lambda parameter being passed to 'walk') I > > think all these signatures are fundamentally equivalent; (2) and (3) seem > > to have been designed for something like this: > > > > Number n = walk(s -> new Integer(1)); > > > > That is, the function returns something that is more specific w.r.t. what > > is expected in the return type of walk. But - in reality, if 'walk' > > returns an R that is a subtype of T (as in the third signature), then walk > > also returns a T (as R is a subtype of T), so the result value can be > > passed where a T is expected. > > > > The converse example: > > > > Integer n1 = walk(s -> (Number)null); > > > > Similarly fails on all three signatures. > > > > > > More generally, with all such signatures, T will always receive: > > > > * lower bound(s) (from the return value(s) of the lambda passed as a > > parameter to the 'walk' method) > > * one upper bound (from the target-type associated with the 'walk' call. > > > > Under such conditions, the upper bound will always be disregarded in favor > > of the lower bounds - meaning that instantiation of T will always be > > driven by what's inside the lambda. Signature (3) mentions different > > variables (R and T) but the end result is the same - as the bound says R > > extends T - meaning that lower bounds of R are propagated to T - leading > > to exactly the same situation. > > > > > > In other words, I don't think there are obvious examples in which the > > behavior of these three signatures will be significantly different - if > > the return type of 'walk' would have been a generic type such as List, > > the situation would have been completely different - with with a 'naked' > > T, I think the first signature is good enough, and the third is, in my > > opinion, making things harder than what they need to be. > > > > I think the second signature is not necessary, from a pure type-system > > perspective; but I guess one could make an argument for it, but purely in > > terms of consistency with other areas (after all, the second > > type-parameter of a Function is in a covariant position). > > > > I hope this helps. > > > > Maurizio > > > From peter.levart at gmail.com Wed Nov 4 12:18:29 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 Nov 2015 13:18:29 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> Message-ID: <5639F795.6000005@gmail.com> Hi Michael, Vladimir, I have finally managed to look at the code on a bigger screen and I think your latest webrev is correct now. But it feels like it works around the fact that BMH subclass definition (just definition, not initialization) is not atomic. I asked myself why normal class loading doesn't suffer from this issue. It's because ClassLoader basically does class definition in atomic way: protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // ClassNotFoundException thrown if class not found // from the non-null parent class loader } if (c == null) { // If still not found, then invoke findClass in order // to find the class. c = findClass(name); } } if (resolve) { resolveClass(c); } return c; } } ...so, under the lock that is keyed by class name, it 1st tries to 'findLoadedClass' and if it is not there, it defines it. If defining the BMH subclass worked the same way and decoupled class initialization from the definition, there would be no duplicate definition attempts and a work-around would not be needed. If a BMH subclass was defined successfully, but its initialization failed, we would not attempt to define it once more next time, we would just try to extract the static field value from corrupted class and fail with similar exception as the 1st time (or with exception that is chosen by VM when trying to use such class, which I think is more correct). Here's what I am thinking, in code: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ Now that definition of BMH subclass is atomic, caching of SpeciesData can be simplified. We don't need special placeholder instances as locks and synchronized static methods. To make BMH subclass definition atomic, we can leverage CHM.computeIfAbsent that does the similar "placeholder" dance, but in much more sophisticated way. BMH logic is much more straightforward and easier to grasp that way. So what do you think of this version. Your version is logically correct too, so you decide which one is better. Regards, Peter On 10/29/2015 04:20 PM, Michael Haupt wrote: > Hi Vladimir, Peter, > > once more, thanks for all your comments. The revised webrev is at http://cr.openjdk.java.net/~mhaupt/8131129/webrev.01/. > > Best, > > Michael > >> Am 28.10.2015 um 17:37 schrieb Vladimir Ivanov : >> >> Peter, >> >>> Hi Vladimir, I think you are right. The proposed fix alone even >>> increases the chance of duplicate class definition attempts as it delays >>> registration in cache to after whole clinit successfully finishes. I >>> would still keep this initialization rearrangement as it fixes the >>> possible publication race too. If the source of 1st exception is from >>> clinit method execution, then it would be best to skip forced class >>> initialization and delay it to its 1st use. Eager initialization does >>> not serve any purpose if the registration into cache is performed out of >>> clinit method as proposed in the fix. >>> >>> To summarise: the proposed initialization fix would have to be >>> accompanied with removal of forced class initialization to achieve the >>> effect of your option (1) below. >> There's no benefit from skipping eager initialization - if class initialization fails, the class becomes unusable anyway. >> >> The idea was to split class init and SPECIES_DATA field init. It would allow to retry Species_* class init later once the initial attempt failed. But there's not much value is that right now, since VM doesn't unload generated adapters. So, once code cache is exhausted there's not much JVM can do about it. >> >> Also, publishing not fully initialized Species_* class requires all users to check whether the initialization is completed, which can be too much from performance perspective. >> >> So, I'm in favor of modified (3) Michael proposed. >> >> Best regards, >> Vladimir Ivanov >> >>> Regards, Peter >>> >>> Michael, Peter, >>> >>> Thanks for detailed analysis! It was a hard one to track down :-) >>> >>> Unfortunately, I don't see how the proposed change fixes the problem. >>> >>> The failure occurs during SpeciesData instantiation >>> (BMH$SpeciesData.). It means updateCache has not yet been called >>> from getForClass: >>> >>> static SpeciesData getForClass(String types, Class>> BoundMethodHandle> clazz) { >>> return updateCache(types, new SpeciesData(types, clazz)); >>> } >>> >>> With your changes, updateCache is called only after successful loading >>> of a class. So, the cache isn't updated if there was an error during >>> previous attempt. >>> >>> The real problem is more severe IMO. The loaded class is useless when >>> its initialization finishes abruptly, so there's no way to instantiate >>> it or reload. Right now it is manifested as a duplicate class definition >>> attempt, but if you avoid repeated class loading it will just fail >>> slightly later - the system is already broken and there's no way to recover. >>> >>> I see the following ways to proceed: >>> (1) delay class initialization (fill in Species_*.SPECIES_DATA field >>> afterwards) and attempt to finish initialization on subsequent requests, >>> but skipping class loading step; >>> >>> (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry >>> Species creation; >>> >>> (3) give up on that particular Species shape and throw an error >>> whenever it is requested (how it works right now, but with more >>> meaningful error message). >>> >>> I remember I experimented with (2), but even after JDK-8078629 [2] there >>> was still measurable peak performance regression on Octane/Nashorn. >>> >>> (1) looks more favorable and robust, but right now there shouldn't be >>> much difference - there's no support in VM to unload MH.linkTo* >>> adapters, so the failure will repeatedly occur once the code cache is full. >>> >>> My conclusion is that it is mostly a test problem, but java.lang.invoke >>> framework should clearly communicate the reason why it fails. Since the >>> test is aware about code cache overflow problems, it looks preferable to >>> go with (1) or (3) for now. VM should throw VirtualMachineError on >>> repeated attempts to instantiate SPECIES_DATA and the test already >>> filters them out. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8078602 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8078629 >>> >>> On 10/28/15 12:19 PM, Michael Haupt wrote: >>> >>> Dear all, >>> >>> please review this change. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8131129 >>> Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/ >>> >>> Thanks to Peter Levart, who has contributed the actual code to fix >>> the issue. >>> >>> The background of this is as follows. Bug 8131129 is an intermittent >>> failure in a multi-threaded test for LambdaForm caching. The failure >>> was not reproducible but used to occur on various platforms every >>> now and then. I was able to dig up some stack traces that reveal the >>> real cause in internal test logs. These traces finally confirmed a >>> suspicion that both Peter and I had had but could, for lack of >>> complete failure information, not pin down as the cause of the >>> issue. (Most traces from failures of the test were only partial, as >>> the test harness is selective about traces it logs.) >>> >>> At the heart of the problem is an overflowing code cache for >>> adapters in the VM. The test, dynamically generating considerable >>> amounts of LambdaForm and BoundMethodHandle species classes, would >>> eventually trigger this overflow. The place at which the problem >>> would surface is this, in >>> BoundMethodHandle.Factory.generateConcreteBMHClass(): >>> >>> Class bmhClass = >>> //UNSAFE.defineAnonymousClass(BoundMethodHandle.class, >>> classFile, null).asSubclass(BoundMethodHandle.class); >>> UNSAFE.defineClass(className, classFile, 0, classFile.length, >>> BoundMethodHandle.class.getClassLoader(), null) >>> .asSubclass(BoundMethodHandle.class); >>> UNSAFE.ensureClassInitialized(bmhClass); >>> >>> The test would generate a BMH species with a given type signature >>> via defineClass and immediately thereafter force initialisation of >>> that class, in the course of which a SpeciesData instance is >>> supposed to be created and entered in the BMH species cache. In case >>> the VM's adapter code cache overflowed during this operation, the >>> BMH species' class initialiser would not finish its execution >>> properly, leading to a stale placeholder entry left behind in the >>> cache. The presence of this very placeholder would trick the next >>> request for a BMH species with the same type signature into >>> believing the class needed to be defined, leading to the observed >>> failure. >>> >>> An exemplary stack trace is appended below. >>> >>> Both Peter and I had come up with solutions, but I think Peter's is >>> better as it gets rid of the somewhat intricate and semi-hidden >>> cache registration call made from generated code. With Peter's fix, >>> it's all visible in library code now. >>> >>> Thanks, >>> >>> Michael >>> >>> >>> >>> ----- >>> java.lang.InternalError: java.lang.NoSuchMethodException: no such >>> method: >>> java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >>> at >>> java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) >>> at >>> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) >>> at >>> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) >>> at >>> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) >>> at >>> java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) >>> at >>> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) >>> at >>> java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) >>> at >>> java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) >>> at >>> java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) >>> at >>> java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.(BoundMethodHandle.java:347) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) >>> at >>> java.lang.invoke.BoundMethodHandle$Species_IL7.(Species_IL7) >>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>> at >>> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >>> at >>> java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >>> at >>> java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >>> at >>> java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >>> at >>> java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >>> at >>> java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >>> at TestMethods$4.getMH(TestMethods.java:180) >>> at TestMethods.getTestCaseMH(TestMethods.java:548) >>> at >>> LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >>> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown >>> Source) >>> at java.lang.Thread.run(Thread.java:745) >>> Caused by: java.lang.NoSuchMethodException: no such method: >>> java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >>> at >>> java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) >>> at >>> java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) >>> at >>> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) >>> ... 25 more >>> Caused by: java.lang.NoSuchMethodError: >>> java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; >>> at java.lang.invoke.MethodHandleNatives.resolve(Native Method) >>> at >>> java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) >>> at >>> java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) >>> ... 26 more >>> Caused by: java.lang.VirtualMachineError: out of space in CodeCache >>> for method handle intrinsic >>> ... 29 more >>> java.lang.LinkageError: loader (instance of ): >>> attempted duplicate class definition for name: >>> "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> at sun.misc.Unsafe.defineClass(Native Method) >>> at >>> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >>> at >>> java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >>> at >>> java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >>> at >>> java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >>> at >>> java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >>> at >>> java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >>> at TestMethods$4.getMH(TestMethods.java:180) >>> at TestMethods.getTestCaseMH(TestMethods.java:548) >>> at >>> LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >>> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown >>> Source) >>> at java.lang.Thread.run(Thread.java:745) >>> java.lang.LinkageError: loader (instance of ): >>> attempted duplicate class definition for name: >>> "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> at sun.misc.Unsafe.defineClass(Native Method) >>> at >>> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) >>> at >>> java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) >>> at >>> java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) >>> at >>> java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) >>> at >>> java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) >>> at >>> java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) >>> at TestMethods$4.getMH(TestMethods.java:180) >>> at TestMethods.getTestCaseMH(TestMethods.java:548) >>> at >>> LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) >>> at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown >>> Source) >>> at java.lang.Thread.run(Thread.java:745) >>> STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: >>> java.lang.LinkageError: loader (instance of ): attempted >>> duplicate class definition for name: >>> "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> `main' threw exception: java.lang.LinkageError: loader (instance of >>> ): attempted duplicate class definition for name: >>> "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> `main' threw exception: java.lang.InternalError: >>> java.lang.NoSuchMethodException: no such method: >>> java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic >>> java.lang.LinkageError: loader (instance of ): >>> attempted duplicate class definition for name: >>> "java/lang/invoke/BoundMethodHandle$Species_IL7" >>> at sun.misc.Unsafe.defineClass(Native Method) >>> at >>> java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) >>> at >>> java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) >>> ----- >>> >>> >>> From forax at univ-mlv.fr Wed Nov 4 13:00:57 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 Nov 2015 14:00:57 +0100 (CET) Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <936ED23B-3BC9-4FFC-B2D6-3CC5E8D083C0@oracle.com> References: <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> <936ED23B-3BC9-4FFC-B2D6-3CC5E8D083C0@oracle.com> Message-ID: <1694834770.1779970.1446642057666.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: core-libs-dev at openjdk.java.net > Envoy?: Mercredi 4 Novembre 2015 10:57:41 > Objet: Re: Proposed API for JEP 259: Stack-Walking API > > > > On 4 Nov 2015, at 10:03, Remi Forax wrote: > > > > Hi Paul, > > > > The use of BaseStream was just an example, here is another one that works > > only if the function first parameter type is declared as '? super > > Stream'. > > > > static Function, Integer> counter() { > > return stream::count; > > } > > > > ... > > StackWalker walker = ... > > int count = walker.walk(counter()); > > > > Good point. Damn, i don?t like wildcards :-) > > The following works fine: > > static Function, Long> counter() { > return Stream::count; > } > > But there could also cases where one is stuck using a wildcard: > > Function, Long> f = Stream::count; Wildcards are not that complex, but because they are use-side annotations, it's really easy to forget them, and IDEs do not help here :( I really hope that the JEP about declaration site variance [1] will be implemented at the beginning of jdk 10, it will remove the need of wildcards for functional interfaces. > > Paul. > R?mi [1] http://openjdk.java.net/jeps/8043488 From Roger.Riggs at Oracle.com Wed Nov 4 14:30:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 Nov 2015 09:30:59 -0500 Subject: JDK 9 RFR of JDK-8141359: @Deprecated on packages should be clarified In-Reply-To: <56397216.1000003@oracle.com> References: <56397216.1000003@oracle.com> Message-ID: <563A16A3.5000802@Oracle.com> Hi Joe, Looks fine. Roger On 11/3/2015 9:48 PM, joe darcy wrote: > Hello, > > Please review the short patch below to address > > JDK-8141359: @Deprecated on packages should be clarified > > --- a/src/java.base/share/classes/java/lang/Deprecated.java Tue Nov > 03 17:41:38 2015 -0800 > +++ b/src/java.base/share/classes/java/lang/Deprecated.java Tue Nov > 03 18:47:38 2015 -0800 > @@ -36,7 +36,7 @@ > * > *

Use of the @Deprecated annotation on a local variable > * declaration or on a parameter declaration or a package declaration > - * has no effect. > + * has no effect on the warnings issued by a compiler. > * > * @author Neal Gafter > * @since 1.5 > > Thanks, > > -Joe From paul.sandoz at oracle.com Wed Nov 4 14:32:25 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Nov 2015 15:32:25 +0100 Subject: RFR 8141409 Arrays.equals accepting a Comparator Message-ID: <1D336362-AB01-47ED-BD0C-3D5897F73D03@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8141409-Arrays-equals-comparator/webrev/ https://bugs.openjdk.java.net/browse/JDK-8141409 This builds on (the already reviewed): https://bugs.openjdk.java.net/browse/JDK-8033148 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ and adds yet more methods to Arrays, only two this time though, to fill out the missing gaps related to array equality with a comparator. In addition i added an Objects.compare method, which simplifies the implementations of some object-bearing methods. Both additions simplify the specification some object-bearing methods. Paul. From peter.levart at gmail.com Wed Nov 4 14:38:38 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 Nov 2015 15:38:38 +0100 Subject: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization In-Reply-To: <56392A2A.5000003@Oracle.com> References: <560D3F61.6040607@Oracle.com> <560E6FEB.60607@gmail.com> <560EA3F2.7030108@Oracle.com> <5612F582.4050909@Oracle.com> <5613F19E.7010708@gmail.com> <56141107.8000407@Oracle.com> <5616D504.4000104@Oracle.com> <20151012123016.566133@eggemoggin.niobe.net> <561E55CE.3000400@oracle.com> <561E5794.5050002@Oracle.com> <561E5A06.3000802@oracle.com> <561E5E88.7070302@Oracle.com> <561E6030.4020403@oracle.com> <561E60B8.2040900@Oracle.com> <561E654E.6040106@oracle.com> <561E9454.6030700@Oracle.com> <561F5FF4.1080505@gmail.com> <1A8D706F-BCA0-41F3-9456-7DA93E5D906E@oracle.com> <561FA84D.5030502@oracle.com> <561FAEDE.5040100@gmail.com> <561FCDB9.5080306@Oracle.com> <562687C8.1040106@Oracle.com> <173536F2-C957-4454-97A6-F49FEBD2B156@oracle.com> <563919D0.4050406@Oracle.com> <3BCA153D-BAE9-47B1-9A4E-70EDB09038B6@oracle.com> <56392A2A.5000003@Oracle.com> Message-ID: <563A186E.8010209@gmail.com> On 11/03/2015 10:42 PM, Roger Riggs wrote: >>>> I?m in two minds that it sounds sensible for this Cleaner API to >>>> extend for soft/weak references whereas I am not certain of the use >>>> cases. Anyone can share the known use cases that would be helpful. >>>> >>> Besides the cases already mentioned on the thread... Anyone? > A developer at JavaOne wanted more control over the policy for > clearing SoftReferences > possibly taking into account the cost of creating the cache entry. > A technique I proposed was to use a SoftReference, not for the cached > resource itself > but as a sentinel for the VM needing to free 'soft' memory. > > One possible use for a SoftCleaner is to implement a sensible cleaning > strategy for > a Cache. The CleaningFunction was would be triggered when freeing > SoftReferences > was needed by VM GC policy and could be used as a hook to use its own > algorithm > to free some of its cached values. ...and register another Soft CleaningFunction at the same time... Clever! So you get periodic call-backs from GC when GC thinks it's time to do some soft cleaning, and implement the strategy of cleaning the data structure yourself, like: void doPeriodicCleaningWhenGcThinksItsTime(Cleaner cleaner, Runnable strategy) { cleaner.softCleanable(new Object(), () -> { strategy.run(); doPeriodicCleaningWhenGcThinksItsTime(cleaner, strategy); }); } Regards, Peter From weijun.wang at oracle.com Wed Nov 4 14:47:59 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 Nov 2015 22:47:59 +0800 Subject: OT: working directory of another drive on cygwin Message-ID: <563A1A9F.4060706@oracle.com> In Windows, there is a concept called working directory of another drive. For example, in a cmd.exe windows, you can call cd d:\xyz and although you are now still in C:, but if you call "D:" to go to the D: drive, you will find yourself in d:\xyz. In fact, Paths.get("d:").toAbsolutePath() will show it. Now, I am about to write a jtreg test on it. However, I found in cygwin, it's always D:\. If you call "cd d:/xyz", and "cd c:" back, working directory of D: is D:\ instead of D:\xyz. That is to say, except for the current drive. working directory of any other drive is always the root there. Is there a way to change it? Or must I write a BAT file and call cmd.exe /C to execute it? Thanks Max From rob.mckenna at oracle.com Wed Nov 4 15:09:31 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 4 Nov 2015 15:09:31 +0000 Subject: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev In-Reply-To: <52A380C7-D34D-4C35-82C1-0C0A78E1F5EC@oracle.com> References: <52A380C7-D34D-4C35-82C1-0C0A78E1F5EC@oracle.com> Message-ID: <563A1FAB.1090805@oracle.com> Sorry for the delay Michael, I had understood the subject to mean you were waiting on another explicit review. Approved. -Rob On 04/11/15 08:39, Michael Haupt wrote: > All, > > the code in question has been reviewed already: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031871.html > > Best, > > Michael > >> Am 02.11.2015 um 09:12 schrieb Michael Haupt : >> >> (Apologies for multiple posts with wrong subject lines.) >> >>> Dear all, >>> >>> cross-posted to jdk8u-dev and core-libs-dev. >>> >>> Please review this change. >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 >>> Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00 >>> >>> This adds a missing test to 8u-dev that was not pushed along with the feature backport it belongs to. The backport was approved; see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html . >>> >>> Thanks, >>> >>> Michael > From michael.haupt at oracle.com Wed Nov 4 16:06:18 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 4 Nov 2015 17:06:18 +0100 Subject: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev In-Reply-To: <563A1FAB.1090805@oracle.com> References: <52A380C7-D34D-4C35-82C1-0C0A78E1F5EC@oracle.com> <563A1FAB.1090805@oracle.com> Message-ID: <28BFF972-9735-410F-A129-44AEB3C8544F@oracle.com> Hi Rob, my bad. Thanks a lot! Michael > Am 04.11.2015 um 16:09 schrieb Rob McKenna : > > Sorry for the delay Michael, I had understood the subject to mean you were waiting on another explicit review. > > Approved. > > -Rob > > On 04/11/15 08:39, Michael Haupt wrote: >> All, >> >> the code in question has been reviewed already: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031871.html >> >> Best, >> >> Michael >> >>> Am 02.11.2015 um 09:12 schrieb Michael Haupt : >>> >>> (Apologies for multiple posts with wrong subject lines.) >>> >>>> Dear all, >>>> >>>> cross-posted to jdk8u-dev and core-libs-dev. >>>> >>>> Please review this change. >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 >>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00 >>>> >>>> This adds a missing test to 8u-dev that was not pushed along with the feature backport it belongs to. The backport was approved; see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html . >>>> >>>> Thanks, >>>> >>>> Michael >> -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From steve.drach at oracle.com Wed Nov 4 16:40:20 2015 From: steve.drach at oracle.com (Steve Drach) Date: Wed, 4 Nov 2015 08:40:20 -0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <8E943A53-0D6A-4688-A3C8-B35D6EB99766@oracle.com> References: <561ED8BF.40901@oracle.com> <561F16C1.6090702@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> <8E943A53-0D6A-4688-A3C8-B35D6EB99766@oracle.com> Message-ID: <81927B40-CAE2-4A65-BFE4-FA33B33EDE9F@oracle.com> > On Nov 4, 2015, at 1:01 AM, Paul Sandoz wrote: > > Hi Steve, > > Hi Steve, > > I don?t think we need to cache versioned entries (as we discussed a while back). For class loading it?s likely to increase memory costs without any performance benefit (if anything a performance decrease). It?s easy to add back later on if we have data that suggests otherwise. Okay, I?ll take that code out. As you said, it?s easy to add back if needed. > > We can reduce the search space for searching for versioned entries by setting the lower bound of the base version to one minus the first Java major release that has runtime support for multi-release jar files i.e. 8 as it currently stands. Yes, I can do that. I?ll need to change the test jar file from versions 8 and 9 to versions 9 and 10 because we won?t see the version 8 classes in the current test jar and it?s nice to have a test jar with more than one version. > > 312 * @throws IllegalStateException if called after an entry has been read > > ? after an entry has been obtained (see ?.) > > You might need some further clarification in setVersioned/setRuntimeVersioned itself describing the lifecycle e.g. > > this method may be called one or more times after construction and before the first operation that obtains an entry, > after which the jar file configuration?s is considered immutable, and subsequent calls to this method will result in an ISE. Okay. > > Paul. > >> On 3 Nov 2015, at 18:11, Steve Drach wrote: >> >> Please review the latest webrev that addresses the issue raised in Sherman?s comments below, with my comments interspersed in-line. The changes between this webrev and the last one are in the definition and use of the ismultiRelease() method and the introduction of a configuration lock, the boolean configured, that prevents setting the version after an entry has been read from the jar file. As a consequence of the configuration lock, I had to modify a couple tests and add a new one. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >> > From openjdk at duigou.org Wed Nov 4 16:51:08 2015 From: openjdk at duigou.org (Mike Duigou) Date: Wed, 04 Nov 2015 08:51:08 -0800 Subject: RFR 8141409 Arrays.equals accepting a Comparator In-Reply-To: References: Message-ID: > Date: Wed, 4 Nov 2015 15:32:25 +0100 > From: Paul Sandoz > To: core-libs-dev > Subject: RFR 8141409 Arrays.equals accepting a Comparator > Please review: > > In addition i added an Objects.compare method, which simplifies the > implementations of some object-bearing methods. Why not put the method on Comparable? The null handling choice seems arbitrary. Nulls last or nulls disallowed would be equally valid. As usual I favour nulls disallowed. From joe.darcy at oracle.com Wed Nov 4 17:23:24 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 4 Nov 2015 09:23:24 -0800 Subject: JDK 9 RFR of JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves Message-ID: <563A3F0C.7060609@oracle.com> Hello, Please review the simple patch below which addresses JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves In summary, the patch moves the test java/lang/ProcessHandle/TreeTest.java from tier 1 to tier 2; the test can be moved back to tier 1 once better stability is demonstrated (c.f. JDK-8139345). Thanks, -Joe --- a/test/TEST.groups Wed Nov 04 09:01:15 2015 -0800 +++ b/test/TEST.groups Wed Nov 04 09:19:47 2015 -0800 @@ -27,6 +27,7 @@ tier1 = \ :jdk_lang \ + -java/lang/ProcessHandle/TreeTest.java \ :jdk_util \ sun/nio/cs/ISO8859x.java \ java/nio/Buffer \ @@ -34,6 +35,7 @@ :jdk_math tier2 = \ + java/lang/ProcessHandle/TreeTest.java \ :jdk_io \ :jdk_nio \ -sun/nio/cs/ISO8859x.java \ From roger.riggs at oracle.com Wed Nov 4 19:13:38 2015 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 4 Nov 2015 14:13:38 -0500 Subject: JDK 9 RFR of JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves In-Reply-To: <563A3F0C.7060609@oracle.com> References: <563A3F0C.7060609@oracle.com> Message-ID: <563A58E2.2050909@oracle.com> Hi Joe, Looks fine. Roger On 11/4/15 12:23 PM, joe darcy wrote: > Hello, > > Please review the simple patch below which addresses > > JDK-8141454: Move java/lang/ProcessHandle/TreeTest.java until > stability improves > > In summary, the patch moves the test > java/lang/ProcessHandle/TreeTest.java from tier 1 to tier 2; the test > can be moved back to tier 1 once better stability is demonstrated > (c.f. JDK-8139345). > > Thanks, > > -Joe > > --- a/test/TEST.groups Wed Nov 04 09:01:15 2015 -0800 > +++ b/test/TEST.groups Wed Nov 04 09:19:47 2015 -0800 > @@ -27,6 +27,7 @@ > > tier1 = \ > :jdk_lang \ > + -java/lang/ProcessHandle/TreeTest.java \ > :jdk_util \ > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > @@ -34,6 +35,7 @@ > :jdk_math > > tier2 = \ > + java/lang/ProcessHandle/TreeTest.java \ > :jdk_io \ > :jdk_nio \ > -sun/nio/cs/ISO8859x.java \ From claes.redestad at oracle.com Wed Nov 4 20:12:59 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 4 Nov 2015 21:12:59 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <5639F795.6000005@gmail.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> Message-ID: <563A66CB.9070705@oracle.com> Hi, On 2015-11-04 13:18, Peter Levart wrote: > Here's what I am thinking, in code: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ > > Now that definition of BMH subclass is atomic, caching of SpeciesData > can be simplified. We don't need special placeholder instances as > locks and synchronized static methods. To make BMH subclass definition > atomic, we can leverage CHM.computeIfAbsent that does the similar > "placeholder" dance, but in much more sophisticated way. BMH logic is > much more straightforward and easier to grasp that way. > > So what do you think of this version. Your version is logically > correct too, so you decide which one is better. I've been tracking this patch for a bit since it's startup sensitive, and suggested some improvements offline to avoid the reflection lookups on non-asserting code that's been rolled into this patch. I gave both patches here a spin and noticed that Peter's variant pulls in some 6 extra classes on a jigsaw Hello World test I'm playing with (such as ConcurrentHashMap$BaseIterator). Not a strong argument in itself, but if there's no stronger reason for your version than to clean this up a bit I'd vote in favor of Michael's approach... > Regards, Peter > > On 10/29/2015 04:20 PM, Michael Haupt wrote: >> Hi Vladimir, Peter, >> >> once more, thanks for all your comments. The revised webrev is at >> http://cr.openjdk.java.net/~mhaupt/8131129/webrev.01/. however, the access to FAILED_SPECIES_CACHE doesn't seem to be thread-safe and needs to be synchronized with a static lock object in BoundMethodHandle (initiating different SpeciesData concurrently might lead to ConcurrentModificationException when accessing or putting values into FAILED_SPECIES_CACHE. I'd suggest cleaning up the synchronized methods to lock on specific objects while we're at it, and maybe should initialize FAILED_SPECIES_CACHE as Collections.emptyList(), since it'll typically never be used anyhow: http://cr.openjdk.java.net/~redestad/scratch/bmh.race.01/ Perhaps this clunky implementation is an argument in favor of Peter's approach, but it keeps class count in check. Thanks! /Claes >> >> Best, >> >> Michael From paul.sandoz at oracle.com Wed Nov 4 21:41:14 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 Nov 2015 22:41:14 +0100 Subject: RFR 8141409 Arrays.equals accepting a Comparator In-Reply-To: References: Message-ID: <8C0ACF9E-A595-4D2F-9257-F595B74E5986@oracle.com> > On 4 Nov 2015, at 17:51, Mike Duigou wrote: > >> Date: Wed, 4 Nov 2015 15:32:25 +0100 >> From: Paul Sandoz >> To: core-libs-dev >> Subject: RFR 8141409 Arrays.equals accepting a Comparator >> Please review: >> In addition i added an Objects.compare method, which simplifies the >> implementations of some object-bearing methods. > > Why not put the method on Comparable? > I wanted it to be located with: public static boolean equals(Object a, Object b) public static int compare(T a, T b, Comparator c) > The null handling choice seems arbitrary. I wanted Arrays.equals to be consistent with the Comparable accepting Arrays.compare and Arrays.mismatch, so it was a coin toss between nulls first and nulls last, hence that choice is propagated to Objects.compare, which is consistent with Objects.equals. The other solution, as you suggest out, is to ditch support Comparable null values, where a certain choice is picked. for the relevant Comparable accepting Arrays methods. That would be more consistent with existing operations on Comparables, such as Arrays.sort etc. and for consistency with Arrays.equals a null accepting Comparator would need to be used with the relevant methods on Arrays. Hmm? now you have me rethinking this :-) thoughts? Paul. > Nulls last or nulls disallowed would be equally valid. As usual I favour nulls disallowed. > From peter.levart at gmail.com Wed Nov 4 22:31:42 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 4 Nov 2015 23:31:42 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <563A66CB.9070705@oracle.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> Message-ID: <563A874E.3010105@gmail.com> Hi Claes, On 11/04/2015 09:12 PM, Claes Redestad wrote: > Hi, > > On 2015-11-04 13:18, Peter Levart wrote: >> Here's what I am thinking, in code: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ >> >> Now that definition of BMH subclass is atomic, caching of SpeciesData >> can be simplified. We don't need special placeholder instances as >> locks and synchronized static methods. To make BMH subclass >> definition atomic, we can leverage CHM.computeIfAbsent that does the >> similar "placeholder" dance, but in much more sophisticated way. BMH >> logic is much more straightforward and easier to grasp that way. >> >> So what do you think of this version. Your version is logically >> correct too, so you decide which one is better. > > I've been tracking this patch for a bit since it's startup sensitive, > and suggested some improvements offline to avoid the reflection > lookups on non-asserting code that's been rolled into this patch. > > I gave both patches here a spin and noticed that Peter's variant pulls > in some 6 extra classes on a jigsaw Hello World test I'm playing with > (such as ConcurrentHashMap$BaseIterator). Not a strong argument in > itself, but if there's no stronger reason for your version than to > clean this up a bit I'd vote in favor of Michael's approach... The extra classes needed are not a consequence of using ConcurrentHashMap per se (as it is already used in CacheLoader to hold locks), but the result of iteration that is performed here: 431 for (SpeciesData d : CACHE.values()) { 432 d.initForBootstrap(); 433 } ...if this iteration is replaced by iteration over staticSpeciesData array, there should not be any additional class loaded... I just don't know why this is needed: 367 static { CACHE.put("", EMPTY); } // make bootstrap predictable If this is there to force HashMap (or ConcurrentHashMap) to initialize it's internal table (which it does lazily) and the entry is otherwise not used, then iterating over staticSpeciesData array becomes equivalent to iterating over ConcurrentHashMap's values... If this EMPTY value is used, it can be EMPTY.initForBootstrap()ed explicitly out of loop. Regards, Peter > >> Regards, Peter >> >> On 10/29/2015 04:20 PM, Michael Haupt wrote: >>> Hi Vladimir, Peter, >>> >>> once more, thanks for all your comments. The revised webrev is at >>> http://cr.openjdk.java.net/~mhaupt/8131129/webrev.01/. > > however, the access to FAILED_SPECIES_CACHE doesn't seem to be > thread-safe and needs to be synchronized with a static lock object in > BoundMethodHandle (initiating different SpeciesData concurrently might > lead to ConcurrentModificationException when accessing or putting > values into FAILED_SPECIES_CACHE. > > I'd suggest cleaning up the synchronized methods to lock on specific > objects while we're at it, and maybe should initialize > FAILED_SPECIES_CACHE as Collections.emptyList(), since it'll typically > never be used anyhow: > > http://cr.openjdk.java.net/~redestad/scratch/bmh.race.01/ > > Perhaps this clunky implementation is an argument in favor of Peter's > approach, but it keeps class count in check. > > Thanks! > > /Claes > >>> >>> Best, >>> >>> Michael > From claes.redestad at oracle.com Wed Nov 4 23:09:42 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 05 Nov 2015 00:09:42 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <563A874E.3010105@gmail.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> <563A874E.3010105@gmail.com> Message-ID: <563A9036.7090308@oracle.com> On 2015-11-04 23:31, Peter Levart wrote: > Hi Claes, > > On 11/04/2015 09:12 PM, Claes Redestad wrote: >> Hi, >> >> On 2015-11-04 13:18, Peter Levart wrote: >>> Here's what I am thinking, in code: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.02/ >>> >>> Now that definition of BMH subclass is atomic, caching of >>> SpeciesData can be simplified. We don't need special placeholder >>> instances as locks and synchronized static methods. To make BMH >>> subclass definition atomic, we can leverage CHM.computeIfAbsent that >>> does the similar "placeholder" dance, but in much more sophisticated >>> way. BMH logic is much more straightforward and easier to grasp that >>> way. >>> >>> So what do you think of this version. Your version is logically >>> correct too, so you decide which one is better. >> >> I gave both patches here a spin and noticed that Peter's variant >> pulls in some 6 extra classes on a jigsaw Hello World test I'm >> playing with (such as ConcurrentHashMap$BaseIterator). Not a strong >> argument in itself, but if there's no stronger reason for your >> version than to clean this up a bit I'd vote in favor of Michael's >> approach... > > The extra classes needed are not a consequence of using > ConcurrentHashMap per se (as it is already used in CacheLoader to hold > locks), but the result of iteration that is performed here: > > 431 for (SpeciesData d : CACHE.values()) { > 432 d.initForBootstrap(); > 433 } > > > ...if this iteration is replaced by iteration over staticSpeciesData > array, there should not be any additional class loaded... > > I just don't know why this is needed: > > 367 static { CACHE.put("", EMPTY); } // make bootstrap > predictable > > If this is there to force HashMap (or ConcurrentHashMap) to initialize > it's internal table (which it does lazily) and the entry is otherwise > not used, then iterating over staticSpeciesData array becomes > equivalent to iterating over ConcurrentHashMap's values... If this > EMPTY value is used, it can be EMPTY.initForBootstrap()ed explicitly > out of loop. I'd be happy with getting rid of both loops and the staticSpeciesData array. Refactor the second two rows into a private static method or not and merge with the static block at line 367: private static void initSpeciesData(SpeciesData speciesData) { CACHE.put(speciesData.typeChars, speciesData); speciesData.initForBootstrap(); } static { // Pre-fill the BMH species-data cache with BMH's inner subclasses. All of these classes' SPECIES_DATA // fields must be added to ensure proper cache population. initSpeciesData(EMPTY); initSpeciesData(Species_L.SPECIES_DATA); assert speciesDataCachePopulated(); ... The assert should take care of failing (a lot of) tests if someone forgets to statically add initSpeciesData for any future (static) inner subclasses of BMH, so I can't think of a real reason to not simplify like this. /Claes > > Regards, Peter > >> >>> Regards, Peter >>> >>> On 10/29/2015 04:20 PM, Michael Haupt wrote: >>>> Hi Vladimir, Peter, >>>> >>>> once more, thanks for all your comments. The revised webrev is at >>>> http://cr.openjdk.java.net/~mhaupt/8131129/webrev.01/. >> >> however, the access to FAILED_SPECIES_CACHE doesn't seem to be >> thread-safe and needs to be synchronized with a static lock object in >> BoundMethodHandle (initiating different SpeciesData concurrently >> might lead to ConcurrentModificationException when accessing or >> putting values into FAILED_SPECIES_CACHE. >> >> I'd suggest cleaning up the synchronized methods to lock on specific >> objects while we're at it, and maybe should initialize >> FAILED_SPECIES_CACHE as Collections.emptyList(), since it'll >> typically never be used anyhow: >> >> http://cr.openjdk.java.net/~redestad/scratch/bmh.race.01/ >> >> Perhaps this clunky implementation is an argument in favor of Peter's >> approach, but it keeps class count in check. >> >> Thanks! >> >> /Claes >> >>>> >>>> Best, >>>> >>>> Michael >> > From mandy.chung at oracle.com Thu Nov 5 01:15:58 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 Nov 2015 17:15:58 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <56375B18.1010800@redhat.com> References: <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> <5633F14B.4080503@redhat.com> <5779E088-D59B-427F-83E9-3EB160386CD7@oracle.com> <56375B18.1010800@redhat.com> Message-ID: Sorry for the delay getting back to this. > On Nov 2, 2015, at 4:46 AM, David M. Lloyd wrote: > > I think there are two problems with the current approach: > > 1. The function for getting the next batch size is not coupled to the function actually doing the work. I think it is just as likely (if not more so) that any information about the optimum number of frames to be gathered per batch can only be sensibly determined as a result of the current work being done. In this case, you'd have to do something odd like use a captured shared AtomicInteger or similar to pass information back and forth, which is not good. I agree that the next batch size is not coupled to the function consuming the stack frames. > > 2. The fact that frames are acquired in batches is an implementation detail. I do not believe it's a reasonable expectation of a user to know the optimum batch size; the API should not be exposing implementation details like this. On the other hand, the user might be reasonably expected to be able to inform the stack walker as to how many more frames are expected to be needed. The stack walker could easily use this information, even if it fetches in batches, by keeping a "remainingNeeded" counter of number of remaining frames expected to be used, which is decremented each time the stream returns an item, and read when a new batch is needed: it could (for example) use Math.min(10, remainingNeeded). For short-circuiting, I also think it?s reasonable to expect the user know how many remaining frames it expects to traverse and it may not need to increase the batch size i.e. it might not need to update the remainingNeeded over time. The user to supply the estimate number of frames needed may be adequate for it (like what you suggest previously having the walk method to take an initial batch size for the simple case). Walking the entire stack (or almost all stack frames) is the use case that this hint may help in performance since the stack depth is unknown and it?s a tradeoff between memory and runtime. Throwable::init and AccessControlContext are the use cases that need to be performant. It?s better to wait for more experience of using the StackWalker and see if any other use cases need adaptive sizing . I propose to drop this walk(Function, IntUnaryFunction) for now and decide to add such ability later. For taking the estimated number of consumed frames, one option is to have a walk(int initialFramesNeeded, Function function) method. The other option is to have the StackWalker(int minDepth, int maxDepth, Set

    should be lower case to match
- you could fix the

->

in the line before the edit. [ There other editorial inconsistencies and indenting in the file; but maybe that's a different review.] Roger On 11/2/2015 12:37 PM, Lance Andersen wrote: > Hi, > > Need a reviewer for 8136496. The CCC has been approved. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8136496/webrev.00/ > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From vladimir.x.ivanov at oracle.com Thu Nov 5 15:02:53 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 5 Nov 2015 18:02:53 +0300 Subject: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements In-Reply-To: <563B62A8.2030908@oracle.com> References: <563B62A8.2030908@oracle.com> Message-ID: <563B6F9D.7060900@oracle.com> Looks good. Best regards, Vladimir Ivanov On 11/5/15 5:07 PM, Claes Redestad wrote: > Hi, > > looking for reviews for two trivial improvements to java.lang.invoke: > > 8141536: MethodType field offset calculation could be lazy > > Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8141536 > > 8141539: Avoid calculating string constants in InnerClassLambdaMetaFactory > > Webrev: http://cr.openjdk.java.net/~redestad/8141539/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8141539 > > /Claes From claes.redestad at oracle.com Thu Nov 5 15:02:49 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 5 Nov 2015 16:02:49 +0100 Subject: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements In-Reply-To: <563B6F9D.7060900@oracle.com> References: <563B62A8.2030908@oracle.com> <563B6F9D.7060900@oracle.com> Message-ID: <563B6F99.3000508@oracle.com> On 2015-11-05 16:02, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov Thanks! /Claes > > On 11/5/15 5:07 PM, Claes Redestad wrote: >> Hi, >> >> looking for reviews for two trivial improvements to java.lang.invoke: >> >> 8141536: MethodType field offset calculation could be lazy >> >> Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141536 >> >> 8141539: Avoid calculating string constants in >> InnerClassLambdaMetaFactory >> >> Webrev: http://cr.openjdk.java.net/~redestad/8141539/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141539 >> >> /Claes From lance.andersen at oracle.com Thu Nov 5 15:11:27 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 5 Nov 2015 10:11:27 -0500 Subject: RFR 8136496 Connection.begin/endRequest In-Reply-To: <563B6EFA.1000206@Oracle.com> References: <43937D2E-621B-4F5C-A323-0C7BE525AA64@oracle.com> <563B6EFA.1000206@Oracle.com> Message-ID: Hi Roger, thank you. I made the proposed changes below. Yes I will do a format clean-up separately as there are issues in multiple places Best Lance On Nov 5, 2015, at 10:00 AM, Roger Riggs wrote: > Hi Lance, > > Looks fine except for a few editorial fixes. > > Editorial: > > - Update copyrights to 2015. > > src/java.sql/share/classes/java/sql/Connection.java: > - about 1515: "." on a separate line. > - several places: missing "." after "no-op" > - later: missing "." after "{@code beginRequest} is a no-op" > > src/java.sql/share/classes/javax/sql/PooledConnection.java > - about line 75: the

    should be lower case to match
> - you could fix the

->

in the line before the edit. > [ There other editorial inconsistencies and indenting in the file; but maybe that's a different review.] > > Roger > > > On 11/2/2015 12:37 PM, Lance Andersen wrote: >> Hi, >> >> Need a reviewer for 8136496. The CCC has been approved. >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8136496/webrev.00/ >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Thu Nov 5 16:04:37 2015 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 5 Nov 2015 11:04:37 -0500 Subject: RFR: 8141546 Fix typo in javadoc for Connection Message-ID: <0333F668-9657-40A1-B147-D556E0457E58@oracle.com> Hi, Need a quick review to fix a javadoc issue that I missed (thought I ran -Xdoclint but did not) Best Lance [ljanders-mac:classes/java/sql] ljanders% javac -Xdoclint Connection.java [ljanders-mac:classes/java/sql] ljanders% hg diff Connection.java diff -r 67d91e7479c1 src/java.sql/share/classes/java/sql/Connection.java --- a/src/java.sql/share/classes/java/sql/Connection.java Thu Nov 05 10:37:08 2015 -0500 +++ b/src/java.sql/share/classes/java/sql/Connection.java Thu Nov 05 10:52:27 2015 -0500 @@ -1540,7 +1540,7 @@ * @throws SQLException if an error occurs * @since 1.9 * @see endRequest - * @see PooledConnection + * @see javax.sql.PooledConnection */ default void beginRequest() throws SQLException { // Default method takes no action @@ -1570,7 +1570,7 @@ *

* The pooling manager should call {@code endRequest} on the underlying connection * when the applications returns the connection back to the connection pool. - * * The pooling manager does not need to call {@code endRequest} if: *

    *
  • The connection pool caches {@code PooledConnection} objects
    • @@ -1582,7 +1582,7 @@ * @throws SQLException if an error occurs * @since 1.9 * @see beginRequest - * @see PooledConnection + * @see javax.sql.PooledConnection */ default void endRequest() throws SQLException { // Default method takes no action [ljanders-mac:classes/java/sql] ljanders% Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From claes.redestad at oracle.com Thu Nov 5 16:04:20 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 5 Nov 2015 17:04:20 +0100 Subject: RFR: 8141546 Fix typo in javadoc for Connection In-Reply-To: <0333F668-9657-40A1-B147-D556E0457E58@oracle.com> References: <0333F668-9657-40A1-B147-D556E0457E58@oracle.com> Message-ID: <563B7E04.80805@oracle.com> Looks good! /Claes On 2015-11-05 17:04, Lance Andersen wrote: > Hi, > > Need a quick review to fix a javadoc issue that I missed (thought I ran -Xdoclint but did not) > > Best > Lance > > [ljanders-mac:classes/java/sql] ljanders% javac -Xdoclint Connection.java > [ljanders-mac:classes/java/sql] ljanders% hg diff Connection.java > diff -r 67d91e7479c1 src/java.sql/share/classes/java/sql/Connection.java > --- a/src/java.sql/share/classes/java/sql/Connection.java Thu Nov 05 10:37:08 2015 -0500 > +++ b/src/java.sql/share/classes/java/sql/Connection.java Thu Nov 05 10:52:27 2015 -0500 > @@ -1540,7 +1540,7 @@ > * @throws SQLException if an error occurs > * @since 1.9 > * @see endRequest > - * @see PooledConnection > + * @see javax.sql.PooledConnection > */ > default void beginRequest() throws SQLException { > // Default method takes no action > @@ -1570,7 +1570,7 @@ > *

    > * The pooling manager should call {@code endRequest} on the underlying connection > * when the applications returns the connection back to the connection pool. > - * + *

    > * The pooling manager does not need to call {@code endRequest} if: > *

      > *
    • The connection pool caches {@code PooledConnection} objects
      • > @@ -1582,7 +1582,7 @@ > * @throws SQLException if an error occurs > * @since 1.9 > * @see beginRequest > - * @see PooledConnection > + * @see javax.sql.PooledConnection > */ > default void endRequest() throws SQLException { > // Default method takes no action > [ljanders-mac:classes/java/sql] ljanders% > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Alan.Bateman at oracle.com Thu Nov 5 16:11:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 16:11:09 +0000 Subject: RFR: 8141546 Fix typo in javadoc for Connection In-Reply-To: <0333F668-9657-40A1-B147-D556E0457E58@oracle.com> References: <0333F668-9657-40A1-B147-D556E0457E58@oracle.com> Message-ID: <563B7F9D.4060008@oracle.com> On 05/11/2015 16:04, Lance Andersen wrote: > Hi, > > Need a quick review to fix a javadoc issue that I missed (thought I ran -Xdoclint but did not) > > Looks fine. From peter.levart at gmail.com Thu Nov 5 16:25:43 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Nov 2015 17:25:43 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> <563A874E.3010105@gmail.com> <563A9036.7090308@oracle.com> <563AFE84.3020700@gmail.com> <563B3872.8030400@oracle.com> Message-ID: <563B8307.6060008@gmail.com> On 11/05/2015 02:16 PM, Michael Haupt wrote: > Hi Claes, Peter, Vladimir, all, > > I really support Peter's latest proposal: it reduces the amounts of code, synchronisation, and complication, and actually addresses the problem at hand too. What's more to wish for? :-) > > I propose to adopt this solution: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ > > Not sure how to proceed. Peter's name should be on the changeset. As he's a Committer, I'm fine if he pushes it once it's signed off by a Reviewer. > > Thanks, > > Michael Hi Michael, Vladimir, Claes, all, When I try the following example: public class Test { static class Failure { static final int value; static { if (true) { throw new InternalError("Failure"); } value = 123; } } public static void main(String[] args) { try { Field valueField = Failure.class.getDeclaredField("value"); int value = valueField.getInt(null); System.out.println("Got value: " + value); } catch (Throwable e) { System.out.println("\n1st exception:\n"); e.printStackTrace(System.out); } try { Field valueField = Failure.class.getDeclaredField("value"); int value = valueField.getInt(null); System.out.println("Got value: " + value); } catch (Throwable e) { System.out.println("\n2nd exception:\n"); e.printStackTrace(System.out); } } } ...I get the following output: 1st exception: java.lang.InternalError: Failure at Test$Failure.(Test.java:12) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) at java.lang.reflect.Field.getInt(Field.java:574) at Test.main(Test.java:21) 2nd exception: java.lang.NoClassDefFoundError: Could not initialize class Test$Failure at sun.misc.Unsafe.ensureClassInitialized(Native Method) at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) at java.lang.reflect.Field.getInt(Field.java:574) at Test.main(Test.java:30) The 1st attempt that also tries to initialize the class throws InternalError directly from , but the 2nd attempt is a kind of LinkageError, which is a different type. So in order for the test(s) to pass, we have to consider this secondary exception too as a non-critical exception: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ I think this is better then trying to disguise NoClassDefFoundError into a VirtualMachineError just in order to "fool" the test(s). This is how VM operates and in general, Error(s) thrown by VM should be propagated up to the top and reported as-is. Regards, Peter > >> Am 05.11.2015 um 12:07 schrieb Claes Redestad : >> >> >> On 2015-11-05 08:00, Peter Levart wrote: >>> >>> Ok, here it is: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >>> >>> I just moved CACHE registration into SpeciesData.initForBootstrap() method, so no new method is needed. Note that patched source now contains the same number of lines as original. How does the jigsaw HelloWorld score now? >>> >>> Regards, Peter >> Thanks, this looks really good to me. I verified that #classes are the same and it even looks like footprint improves ever so slightly. >> >> /Claes From michael.haupt at oracle.com Thu Nov 5 16:34:22 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 5 Nov 2015 17:34:22 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <563B8307.6060008@gmail.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> <563A874E.3010105@gmail.com> <563A9036.7090308@oracle.com> <563AFE84.3020700@gmail.com> <563B3872.8030400@oracle.com> <563B8307.6060008@gmail.com> Message-ID: Hi Peter, but this is more like a separate RFE for improving the testing infrastructure, right? Or am I missing something? Unless this is important for the fix to 8131129, I'd like to keep it separate. Best, Michael > Am 05.11.2015 um 17:25 schrieb Peter Levart : > > > > On 11/05/2015 02:16 PM, Michael Haupt wrote: >> Hi Claes, Peter, Vladimir, all, >> >> I really support Peter's latest proposal: it reduces the amounts of code, synchronisation, and complication, and actually addresses the problem at hand too. What's more to wish for? :-) >> >> I propose to adopt this solution: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >> >> Not sure how to proceed. Peter's name should be on the changeset. As he's a Committer, I'm fine if he pushes it once it's signed off by a Reviewer. >> >> Thanks, >> >> Michael > > Hi Michael, Vladimir, Claes, all, > > When I try the following example: > > public class Test { > > static class Failure { > static final int value; > static { > if (true) { > throw new InternalError("Failure"); > } > value = 123; > } > } > > public static void main(String[] args) { > try { > Field valueField = Failure.class.getDeclaredField("value"); > int value = valueField.getInt(null); > System.out.println("Got value: " + value); > } catch (Throwable e) { > System.out.println("\n1st exception:\n"); > e.printStackTrace(System.out); > } > > try { > Field valueField = Failure.class.getDeclaredField("value"); > int value = valueField.getInt(null); > System.out.println("Got value: " + value); > } catch (Throwable e) { > System.out.println("\n2nd exception:\n"); > e.printStackTrace(System.out); > } > } > } > > > ...I get the following output: > > > 1st exception: > > java.lang.InternalError: Failure > at Test$Failure.(Test.java:12) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) > at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) > at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) > at java.lang.reflect.Field.getInt(Field.java:574) > at Test.main(Test.java:21) > > 2nd exception: > > java.lang.NoClassDefFoundError: Could not initialize class Test$Failure > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) > at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) > at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) > at java.lang.reflect.Field.getInt(Field.java:574) > at Test.main(Test.java:30) > > > The 1st attempt that also tries to initialize the class throws InternalError directly from , but the 2nd attempt is a kind of LinkageError, which is a different type. So in order for the test(s) to pass, we have to consider this secondary exception too as a non-critical exception: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ > > I think this is better then trying to disguise NoClassDefFoundError into a VirtualMachineError just in order to "fool" the test(s). This is how VM operates and in general, Error(s) thrown by VM should be propagated up to the top and reported as-is. > > Regards, Peter > >> >>> Am 05.11.2015 um 12:07 schrieb Claes Redestad : >>> >>> >>> On 2015-11-05 08:00, Peter Levart wrote: >>>> >>>> Ok, here it is: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >>>> >>>> I just moved CACHE registration into SpeciesData.initForBootstrap() method, so no new method is needed. Note that patched source now contains the same number of lines as original. How does the jigsaw HelloWorld score now? >>>> >>>> Regards, Peter >>> Thanks, this looks really good to me. I verified that #classes are the same and it even looks like footprint improves ever so slightly. >>> >>> /Claes -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From aleksey.shipilev at oracle.com Thu Nov 5 16:48:27 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 5 Nov 2015 19:48:27 +0300 Subject: RFR (S): 8141536, 8141539: Minor java.lang.invoke improvements In-Reply-To: <563B62A8.2030908@oracle.com> References: <563B62A8.2030908@oracle.com> Message-ID: <563B885B.3020702@oracle.com> Both improvements look good. Thanks, -Aleksey On 11/05/2015 05:07 PM, Claes Redestad wrote: > looking for reviews for two trivial improvements to java.lang.invoke: > > 8141536: MethodType field offset calculation could be lazy > > Webrev: http://cr.openjdk.java.net/~redestad/8141536/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8141536 > > 8141539: Avoid calculating string constants in InnerClassLambdaMetaFactory > > Webrev: http://cr.openjdk.java.net/~redestad/8141539/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8141539 From steve.drach at oracle.com Thu Nov 5 17:10:02 2015 From: steve.drach at oracle.com (Steve Drach) Date: Thu, 5 Nov 2015 09:10:02 -0800 Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar files In-Reply-To: <8E943A53-0D6A-4688-A3C8-B35D6EB99766@oracle.com> References: <561ED8BF.40901@oracle.com> <561F16C1.6090702@oracle.com> <56207360.6040502@oracle.com> <18A22B13-E31D-45D6-A350-40C35BDDEE73@oracle.com> <562EFF8F.6070501@oracle.com> <8E943A53-0D6A-4688-A3C8-B35D6EB99766@oracle.com> Message-ID: <448E1831-7142-4B95-B0D8-D07A34704D32@oracle.com> Hi, Here?s a new webrev that addresses the issues Paul brought up. The versioned entry cache has been removed, the search space has been reduced, the documentation for setVersioned(int) and setRuntimeVersioned() has been updated to clarify when IllegalStateException is thrown, and the tests have been changed to accommodate a jar file with versions 9 and 10, rather than 8 and 9. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ Steve > On Nov 4, 2015, at 1:01 AM, Paul Sandoz wrote: > > Hi Steve, > > Hi Steve, > > I don?t think we need to cache versioned entries (as we discussed a while back). For class loading it?s likely to increase memory costs without any performance benefit (if anything a performance decrease). It?s easy to add back later on if we have data that suggests otherwise. > > We can reduce the search space for searching for versioned entries by setting the lower bound of the base version to one minus the first Java major release that has runtime support for multi-release jar files i.e. 8 as it currently stands. > > 312 * @throws IllegalStateException if called after an entry has been read > > ? after an entry has been obtained (see ?.) > > You might need some further clarification in setVersioned/setRuntimeVersioned itself describing the lifecycle e.g. > > this method may be called one or more times after construction and before the first operation that obtains an entry, > after which the jar file configuration?s is considered immutable, and subsequent calls to this method will result in an ISE. > > Paul. > >> On 3 Nov 2015, at 18:11, Steve Drach wrote: >> >> Please review the latest webrev that addresses the issue raised in Sherman?s comments below, with my comments interspersed in-line. The changes between this webrev and the last one are in the definition and use of the ismultiRelease() method and the introduction of a configuration lock, the boolean configured, that prevents setting the version after an entry has been read from the jar file. As a consequence of the configuration lock, I had to modify a couple tests and add a new one. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 >> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 >> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ >> > From joe.darcy at oracle.com Thu Nov 5 17:17:46 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 5 Nov 2015 09:17:46 -0800 Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 In-Reply-To: <563ABE31.8010807@oracle.com> References: <563ABE31.8010807@oracle.com> Message-ID: <563B8F3A.3020706@oracle.com> Hi Chris, The langtools and jaxp repos also have TEST.ROOT files with a requiredVersion clause. I'd prefer if the files in those repos were updated at the same to b12. Thanks, -Joe On 11/4/2015 6:25 PM, Chris Plummer wrote: > Please review the following changes: > > http://cr.openjdk.java.net/~cjplummer/8141489/ > https://bugs.openjdk.java.net/browse/JDK-8141489 > > The changes I did for 8140189 require that version 4.1 b12 of jtreg be > used, so TEST.ROOT has been updated to reflect this. > > Testing with JPRT right now. I also ran with b11 and confirmed that > the following errors are produced for hotspot and jdk tests: > > Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test > requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 > b11. > > Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test > requires jtreg version 4.1 b12 or higher and this is jtreg version 4.1 > b11. > > thanks, > > Chris From chris.plummer at oracle.com Thu Nov 5 17:26:58 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 5 Nov 2015 09:26:58 -0800 Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 In-Reply-To: <563B8F3A.3020706@oracle.com> References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com> Message-ID: <563B9162.6020605@oracle.com> Hi Joe, Is there a reason to upgrade them if the tests don't actually require b12? BTW, there are more than just those two repos. The following all have TEST.ROOT: bash-4.1$ find . -name TEST.ROOT ./hotspot/agent/test/jdi/TEST.ROOT ./hotspot/test/TEST.ROOT ./deploy/test/TEST.ROOT ./nashorn/test/TEST.ROOT ./jaxp/test/TEST.ROOT ./jdk/test/TEST.ROOT ./langtools/make/test/TEST.ROOT ./langtools/test/TEST.ROOT But not all of the above specify requiredVersion bash-4.1$ grep requiredVersion `find . -name TEST.ROOT` ./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12 ./deploy/test/TEST.ROOT:requiredVersion=4.1 b11 ./nashorn/test/TEST.ROOT:requiredVersion=4.1 b11 ./jaxp/test/TEST.ROOT:requiredVersion=4.1 b11 ./jdk/test/TEST.ROOT:requiredVersion=4.1 b12 ./langtools/test/TEST.ROOT:requiredVersion=4.1 b11 (Note the ones with b12 are the ones I've already modified for this commit) thanks, Chris On 11/5/15 9:17 AM, joe darcy wrote: > Hi Chris, > > The langtools and jaxp repos also have TEST.ROOT files with a > requiredVersion clause. I'd prefer if the files in those repos were > updated at the same to b12. > > Thanks, > > -Joe > > On 11/4/2015 6:25 PM, Chris Plummer wrote: >> Please review the following changes: >> >> http://cr.openjdk.java.net/~cjplummer/8141489/ >> https://bugs.openjdk.java.net/browse/JDK-8141489 >> >> The changes I did for 8140189 require that version 4.1 b12 of jtreg >> be used, so TEST.ROOT has been updated to reflect this. >> >> Testing with JPRT right now. I also ran with b11 and confirmed that >> the following errors are produced for hotspot and jdk tests: >> >> Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/jdk/test >> requires jtreg version 4.1 b12 or higher and this is jtreg version >> 4.1 b11. >> >> Error: The testsuite at /local/ws/jdk9/hs-rt.8141489/hotspot/test >> requires jtreg version 4.1 b12 or higher and this is jtreg version >> 4.1 b11. >> >> thanks, >> >> Chris > From joe.darcy at oracle.com Thu Nov 5 18:16:20 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 5 Nov 2015 10:16:20 -0800 Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 In-Reply-To: <563B9162.6020605@oracle.com> References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com> <563B9162.6020605@oracle.com> Message-ID: <563B9CF4.20504@oracle.com> Hi Chris, On 11/5/2015 9:26 AM, Chris Plummer wrote: > Hi Joe, > > Is there a reason to upgrade them if the tests don't actually require > b12? BTW, there are more than just those two repos. The following all > have TEST.ROOT: > > bash-4.1$ find . -name TEST.ROOT > ./hotspot/agent/test/jdi/TEST.ROOT > ./hotspot/test/TEST.ROOT > ./deploy/test/TEST.ROOT > ./nashorn/test/TEST.ROOT > ./jaxp/test/TEST.ROOT > ./jdk/test/TEST.ROOT > ./langtools/make/test/TEST.ROOT > ./langtools/test/TEST.ROOT The jtreg configuration files in the $REPO/test directories were regularized earlier in JDK 9 with JDK-8075543: Add tiered testing definitions to the JDK 9 forest For consistency across the JDK, this included adding a minimum jtreg version to 4.1 b11 even if the tests in those repos didn't actually use b11 specific features. I think these same TEST.ROOT files should be updated in unison to b12. Thanks, -Joe From chris.plummer at oracle.com Thu Nov 5 18:25:42 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 5 Nov 2015 10:25:42 -0800 Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 In-Reply-To: <563B9CF4.20504@oracle.com> References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com> <563B9162.6020605@oracle.com> <563B9CF4.20504@oracle.com> Message-ID: <563B9F26.3050309@oracle.com> On 11/5/15 10:16 AM, joe darcy wrote: > Hi Chris, > > On 11/5/2015 9:26 AM, Chris Plummer wrote: >> Hi Joe, >> >> Is there a reason to upgrade them if the tests don't actually require >> b12? BTW, there are more than just those two repos. The following all >> have TEST.ROOT: >> >> bash-4.1$ find . -name TEST.ROOT >> ./hotspot/agent/test/jdi/TEST.ROOT >> ./hotspot/test/TEST.ROOT >> ./deploy/test/TEST.ROOT >> ./nashorn/test/TEST.ROOT >> ./jaxp/test/TEST.ROOT >> ./jdk/test/TEST.ROOT >> ./langtools/make/test/TEST.ROOT >> ./langtools/test/TEST.ROOT > > The jtreg configuration files in the $REPO/test directories were > regularized earlier in JDK 9 with > > JDK-8075543: Add tiered testing definitions to the JDK 9 forest > > For consistency across the JDK, this included adding a minimum jtreg > version to 4.1 b11 even if the tests in those repos didn't actually > use b11 specific features. I think these same TEST.ROOT files should > be updated in unison to b12. Ok. I'll get started on it and send out a new webrev when ready. Chris > > Thanks, > > -Joe > From peter.levart at gmail.com Thu Nov 5 19:05:27 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Nov 2015 20:05:27 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> <563A874E.3010105@gmail.com> <563A9036.7090308@oracle.com> <563AFE84.3020700@gmail.com> <563B3872.8030400@oracle.com> <563B8307.6060008@gmail.com> Message-ID: <563BA877.1010201@gmail.com> Hi Michael, The test failure exposed a weakness in the BMH subclass generation and initialization which is fixed by a patch to BMH. OTOH the test will still fail next time with a different exception but that is another issue, I agree. Regards, Peter On 11/05/2015 05:34 PM, Michael Haupt wrote: > Hi Peter, > > but this is more like a separate RFE for improving the testing infrastructure, right? Or am I missing something? Unless this is important for the fix to 8131129, I'd like to keep it separate. > > Best, > > Michael > >> Am 05.11.2015 um 17:25 schrieb Peter Levart : >> >> >> >> On 11/05/2015 02:16 PM, Michael Haupt wrote: >>> Hi Claes, Peter, Vladimir, all, >>> >>> I really support Peter's latest proposal: it reduces the amounts of code, synchronisation, and complication, and actually addresses the problem at hand too. What's more to wish for? :-) >>> >>> I propose to adopt this solution: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >>> >>> Not sure how to proceed. Peter's name should be on the changeset. As he's a Committer, I'm fine if he pushes it once it's signed off by a Reviewer. >>> >>> Thanks, >>> >>> Michael >> Hi Michael, Vladimir, Claes, all, >> >> When I try the following example: >> >> public class Test { >> >> static class Failure { >> static final int value; >> static { >> if (true) { >> throw new InternalError("Failure"); >> } >> value = 123; >> } >> } >> >> public static void main(String[] args) { >> try { >> Field valueField = Failure.class.getDeclaredField("value"); >> int value = valueField.getInt(null); >> System.out.println("Got value: " + value); >> } catch (Throwable e) { >> System.out.println("\n1st exception:\n"); >> e.printStackTrace(System.out); >> } >> >> try { >> Field valueField = Failure.class.getDeclaredField("value"); >> int value = valueField.getInt(null); >> System.out.println("Got value: " + value); >> } catch (Throwable e) { >> System.out.println("\n2nd exception:\n"); >> e.printStackTrace(System.out); >> } >> } >> } >> >> >> ...I get the following output: >> >> >> 1st exception: >> >> java.lang.InternalError: Failure >> at Test$Failure.(Test.java:12) >> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >> at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) >> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) >> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) >> at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) >> at java.lang.reflect.Field.getInt(Field.java:574) >> at Test.main(Test.java:21) >> >> 2nd exception: >> >> java.lang.NoClassDefFoundError: Could not initialize class Test$Failure >> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >> at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) >> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) >> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) >> at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) >> at java.lang.reflect.Field.getInt(Field.java:574) >> at Test.main(Test.java:30) >> >> >> The 1st attempt that also tries to initialize the class throws InternalError directly from , but the 2nd attempt is a kind of LinkageError, which is a different type. So in order for the test(s) to pass, we have to consider this secondary exception too as a non-critical exception: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ >> >> I think this is better then trying to disguise NoClassDefFoundError into a VirtualMachineError just in order to "fool" the test(s). This is how VM operates and in general, Error(s) thrown by VM should be propagated up to the top and reported as-is. >> >> Regards, Peter >> >>>> Am 05.11.2015 um 12:07 schrieb Claes Redestad : >>>> >>>> >>>> On 2015-11-05 08:00, Peter Levart wrote: >>>>> Ok, here it is: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >>>>> >>>>> I just moved CACHE registration into SpeciesData.initForBootstrap() method, so no new method is needed. Note that patched source now contains the same number of lines as original. How does the jigsaw HelloWorld score now? >>>>> >>>>> Regards, Peter >>>> Thanks, this looks really good to me. I verified that #classes are the same and it even looks like footprint improves ever so slightly. >>>> >>>> /Claes From peter.levart at gmail.com Thu Nov 5 19:08:02 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Nov 2015 20:08:02 +0100 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <563BA877.1010201@gmail.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> <563A874E.3010105@gmail.com> <563A9036.7090308@oracle.com> <563AFE84.3020700@gmail.com> <563B3872.8030400@oracle.com> <563B8307.6060008@gmail.com> <563BA877.1010201@gmail.com> Message-ID: <563BA912.2020808@gmail.com> On 11/05/2015 08:05 PM, Peter Levart wrote: > Hi Michael, > > The test failure exposed a weakness in the BMH subclass generation and > initialization which is fixed by a patch to BMH. OTOH the test will > still fail next time with a different exception but that is another > issue, I agree. We can 1st push the fix for 8131129 and then wait for test failure to confirm the expectations and then file another issue for fixing the test(s). Regards, Peter > > Regards, Peter > > On 11/05/2015 05:34 PM, Michael Haupt wrote: >> Hi Peter, >> >> but this is more like a separate RFE for improving the testing infrastructure, right? Or am I missing something? Unless this is important for the fix to 8131129, I'd like to keep it separate. >> >> Best, >> >> Michael >> >>> Am 05.11.2015 um 17:25 schrieb Peter Levart: >>> >>> >>> >>> On 11/05/2015 02:16 PM, Michael Haupt wrote: >>>> Hi Claes, Peter, Vladimir, all, >>>> >>>> I really support Peter's latest proposal: it reduces the amounts of code, synchronisation, and complication, and actually addresses the problem at hand too. What's more to wish for? :-) >>>> >>>> I propose to adopt this solution:http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >>>> >>>> Not sure how to proceed. Peter's name should be on the changeset. As he's a Committer, I'm fine if he pushes it once it's signed off by a Reviewer. >>>> >>>> Thanks, >>>> >>>> Michael >>> Hi Michael, Vladimir, Claes, all, >>> >>> When I try the following example: >>> >>> public class Test { >>> >>> static class Failure { >>> static final int value; >>> static { >>> if (true) { >>> throw new InternalError("Failure"); >>> } >>> value = 123; >>> } >>> } >>> >>> public static void main(String[] args) { >>> try { >>> Field valueField = Failure.class.getDeclaredField("value"); >>> int value = valueField.getInt(null); >>> System.out.println("Got value: " + value); >>> } catch (Throwable e) { >>> System.out.println("\n1st exception:\n"); >>> e.printStackTrace(System.out); >>> } >>> >>> try { >>> Field valueField = Failure.class.getDeclaredField("value"); >>> int value = valueField.getInt(null); >>> System.out.println("Got value: " + value); >>> } catch (Throwable e) { >>> System.out.println("\n2nd exception:\n"); >>> e.printStackTrace(System.out); >>> } >>> } >>> } >>> >>> >>> ...I get the following output: >>> >>> >>> 1st exception: >>> >>> java.lang.InternalError: Failure >>> at Test$Failure.(Test.java:12) >>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>> at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) >>> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) >>> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) >>> at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) >>> at java.lang.reflect.Field.getInt(Field.java:574) >>> at Test.main(Test.java:21) >>> >>> 2nd exception: >>> >>> java.lang.NoClassDefFoundError: Could not initialize class Test$Failure >>> at sun.misc.Unsafe.ensureClassInitialized(Native Method) >>> at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:43) >>> at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:142) >>> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:1088) >>> at java.lang.reflect.Field.getFieldAccessor(Field.java:1069) >>> at java.lang.reflect.Field.getInt(Field.java:574) >>> at Test.main(Test.java:30) >>> >>> >>> The 1st attempt that also tries to initialize the class throws InternalError directly from , but the 2nd attempt is a kind of LinkageError, which is a different type. So in order for the test(s) to pass, we have to consider this secondary exception too as a non-critical exception: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ >>> >>> I think this is better then trying to disguise NoClassDefFoundError into a VirtualMachineError just in order to "fool" the test(s). This is how VM operates and in general, Error(s) thrown by VM should be propagated up to the top and reported as-is. >>> >>> Regards, Peter >>> >>>>> Am 05.11.2015 um 12:07 schrieb Claes Redestad: >>>>> >>>>> >>>>> On 2015-11-05 08:00, Peter Levart wrote: >>>>>> Ok, here it is: >>>>>> >>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.03/ >>>>>> >>>>>> I just moved CACHE registration into SpeciesData.initForBootstrap() method, so no new method is needed. Note that patched source now contains the same number of lines as original. How does the jigsaw HelloWorld score now? >>>>>> >>>>>> Regards, Peter >>>>> Thanks, this looks really good to me. I verified that #classes are the same and it even looks like footprint improves ever so slightly. >>>>> >>>>> /Claes > From chris.plummer at oracle.com Thu Nov 5 19:12:19 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 5 Nov 2015 11:12:19 -0800 Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 In-Reply-To: <563B9F26.3050309@oracle.com> References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com> <563B9162.6020605@oracle.com> <563B9CF4.20504@oracle.com> <563B9F26.3050309@oracle.com> Message-ID: <563BAA13.8060205@oracle.com> Hi Joe, Here's the updated webrev: http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8141489 These are all the repos that have been updated: >$ grep requiredVersion `find . -name TEST.ROOT` ./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12 ./deploy/test/TEST.ROOT:requiredVersion=4.1 b12 ./nashorn/test/TEST.ROOT:requiredVersion=4.1 b12 ./jaxp/test/TEST.ROOT:requiredVersion=4.1 b12 ./jdk/test/TEST.ROOT:requiredVersion=4.1 b12 ./langtools/test/TEST.ROOT:requiredVersion=4.1 b12 Test job has been submitted to JPRT. thanks, Chris From joe.darcy at oracle.com Thu Nov 5 19:19:54 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 5 Nov 2015 11:19:54 -0800 Subject: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12 In-Reply-To: <563BAA13.8060205@oracle.com> References: <563ABE31.8010807@oracle.com> <563B8F3A.3020706@oracle.com> <563B9162.6020605@oracle.com> <563B9CF4.20504@oracle.com> <563B9F26.3050309@oracle.com> <563BAA13.8060205@oracle.com> Message-ID: <563BABDA.1030503@oracle.com> Hi Chris, Looks fine to me; thanks, -Joe On 11/5/2015 11:12 AM, Chris Plummer wrote: > Hi Joe, > > Here's the updated webrev: > > http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8141489 > > These are all the repos that have been updated: > > >$ grep requiredVersion `find . -name TEST.ROOT` > ./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12 > ./deploy/test/TEST.ROOT:requiredVersion=4.1 b12 > ./nashorn/test/TEST.ROOT:requiredVersion=4.1 b12 > ./jaxp/test/TEST.ROOT:requiredVersion=4.1 b12 > ./jdk/test/TEST.ROOT:requiredVersion=4.1 b12 > ./langtools/test/TEST.ROOT:requiredVersion=4.1 b12 > > Test job has been submitted to JPRT. > > thanks, > > Chris From mandy.chung at oracle.com Thu Nov 5 20:43:12 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Nov 2015 12:43:12 -0800 Subject: RFR: JDK-8140364: JEP 264 Platform Logger API and Service Implementation In-Reply-To: <56391547.5010006@oracle.com> References: <561660DA.7070900@oracle.com> <8D8890A3-2337-4178-BA5C-CC32DE12F27D@oracle.com> <561E3A9A.9050807@oracle.com> <6241BCF8-C6A3-4E64-94E9-5E70CEF4A829@oracle.com> <561E8CE7.9020609@oracle.com> <17C7339F-2107-49DE-B909-A65D779F0DF1@oracle.com> <56253412.4030800@oracle.com> <5626B6B7.2040501@oracle.com> <54D9FB8E-A69D-4A41-B81D-D8C1BBFC50EF@oracle.com> <562A49BB.7070206@oracle.com> <56391547.5010006@oracle.com> Message-ID: Thanks Daniel. I haven?t found the cycle to pull down your updates from the logging sandbox to review If the change is the same as you sent me earlier, your change should be good to go. Mandy > On Nov 3, 2015, at 12:12 PM, Daniel Fuchs wrote: > > Hi Mandy, > > I have pushed an update that adds the diagnosability tweaks > you asked me for in LoggerFinderLoader. > I also added a couple of new tests. > No changes in the API specification. > > The sandbox JDK-8046565-branch and public links have been refreshed. > > best regards, > > -- daniel > > sandbox branch JDK-8046565-branch > http://cr.openjdk.java.net/~chegar/docs/sandbox.html > > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html > http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html > > > On 23/10/15 16:52, Daniel Fuchs wrote: >> Hi, >> >> Please find below the online link integrating the latest editorial >> comments I received (from Mandy): >> >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html >> http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html >> >> >> sandbox branch JDK-8046565-branch updated as well. >> >> best regards >> >> -- daniel >> >> Start of the review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035715.html >> >> Subject: RFR: JDK-8046565: Platform Logger API and Service >> >> JEP 264 JBS Issue (8046565): >> https://bugs.openjdk.java.net/browse/JDK-8046565 >> >> RFE that will be ultimately used to commit (8140364): >> https://bugs.openjdk.java.net/browse/JDK-8140364 > From Fabrizio.Giudici at tidalwave.it Thu Nov 5 21:12:53 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 05 Nov 2015 22:12:53 +0100 Subject: Questions about Stream/Iterable/Files - and possibly the compiler Message-ID: Hello. My question is for the sake of curiosity, not being related to a real problem - or, better, the problem - which is tiny - can be fixed with a simple work around. But I'd like to blog a short post about it and I'd like to check I have all the context. It stemmed from a class about Java 8 that I recently taught and one of the participants asked about that. I think that there's something that possibly involves the compiler - I'll eventually post the relevant part of the questions to the proper mailing list. 1. Everything starts from this code chunk that doesnt' compile: Stream s = IntStream.rangeClosed(1, 10) // just as an example to quickly create a Stream .mapToObj(n -> "String #" + n); Files.write(Paths.get("/tmp/pippo.txt"), s); error: no suitable method found for write(Path,Stream) Files.write(Paths.get("/tmp/pippo.txt"), s); method Files.write(Path,byte[],OpenOption...) is not applicable (argument mismatch; Stream cannot be converted to byte[]) method Files.write(Path,Iterable,Charset,OpenOption...) is not applicable (argument mismatch; Stream cannot be converted to Iterable) method Files.write(Path,Iterable,OpenOption...) is not applicable (argument mismatch; Stream cannot be converted to Iterable) 2. Variation. Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s); This gives: Exception in thread "main" java.lang.ClassCastException: java.util.stream.IntPipeline$4 cannot be cast to java.lang.Iterable at StreamIteratorExample.main(StreamIteratorExample.java:13) Ok, so far it's the fact described here http://stackoverflow.com/questions/20129762/why-does-streamt-not-implement-iterablet on why Stream doesn't implement Iterable. Question A: Is the SO answer "because iterator() is usually supposed to be callable multiple times, while in a Stream it can't" correct? 3. This is the known trick around the problem: final Iterable i = s::iterator; Files.write(Paths.get("/tmp/pippo.txt"), i); It works and I think I understand why (Iterable has the same functional descriptor of Supplier, which is s::iterator, so they are compatible in assignment - right?). 4. But at this point putting it into the same line gives compilation error: Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); error: no suitable method found for write(Path,s::iterator) Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); method Files.write(Path,byte[],OpenOption...) is not applicable (argument mismatch; Array is not a functional interface) method Files.write(Path,Iterable,Charset,OpenOption...) is not applicable (argument mismatch; bad return type in method reference Iterator cannot be converted to Iterator) method Files.write(Path,Iterable,OpenOption...) is not applicable (argument mismatch; bad return type in method reference Iterator cannot be converted to Iterator) 5. This at last works: Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s::iterator); I assume that the compiler can't autonomously infer that s::iterator is compatible with Iterable so the cast is needed. I have a question about that (feature or bug?), but this is related to the compiler, so I think is OT here. At last, question B: Given all those premises, is there a specific reason for which Files.write() hasn't been overloaded with a version capable of accepting a Stream? It would have been the perfect complement of Files.lines() Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mandy.chung at oracle.com Thu Nov 5 21:48:45 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Nov 2015 13:48:45 -0800 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <1694834770.1779970.1446642057666.JavaMail.zimbra@u-pem.fr> References: <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> <936ED23B-3BC9-4FFC-B2D6-3CC5E8D083C0@oracle.com> <1694834770.1779970.1446642057666.JavaMail.zimbra@u-pem.fr> Message-ID: > On Nov 4, 2015, at 5:00 AM, Remi Forax wrote: > >> >> Good point. Damn, i don?t like wildcards :-) >> >> The following works fine: >> >> static Function, Long> counter() { >> return Stream::count; >> } >> >> But there could also cases where one is stuck using a wildcard: >> >> Function, Long> f = Stream::count; > > > Wildcards are not that complex, but because they are use-side annotations, it's really easy to forget them, and IDEs do not help here :( > > I really hope that the JEP about declaration site variance [1] will be implemented at the beginning of jdk 10, it will remove the need of wildcards for functional interfaces. > Remi, Paul, The current StackWalker::walk method: T walk(Function, T> function) This would mean that the StackWalker API is intended to work with a function taking Stream but not Stream. Changing to T walk(Function, ? extends T> function) will allow use of some existing functions taking Stream. I don?t object changing it to use wildcard. However, the StackWalker API is specific for reading StackFrame and I would expect it?s reasonable if it doesn?t work with a function taking Stream as the useful functions such as Stream::count, Stream::collect(Collectors.toList(?)) can be used. Just want to double confirm the advice which way to go. Mandy From Roger.Riggs at Oracle.com Thu Nov 5 21:56:17 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 5 Nov 2015 16:56:17 -0500 Subject: RFR 9: 8132394 : (process) ProcessBuilder support for a pipeline of processes Message-ID: <563BD081.8050208@Oracle.com> Please review the new ProcessBuilder.startPipeline API, implementation, and tests. The new method starts a Process for each ProcessBuilder, creating a pipeline of processes linked by their standard output and standard input streams. Each builder can use redirectErrorsream to coalesce error output with standard output. But otherwise standard error streams are not modified. The API is the same as discussed on the earlier core-libs thread [1] and addresses the comments. webrev: http://cr.openjdk.java.net/~rriggs/webrev-pipeline-8132394/ javadoc of ProcessBuilder: only startPipeline is new: http://cr.openjdk.java.net/~rriggs/pipedoc/ Thanks, Roger p.s. The PIPE_CHANNEL redirection proposed by Peter Levert is complementary and still has a bug or two to work out. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034634.html From forax at univ-mlv.fr Thu Nov 5 22:05:22 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Nov 2015 23:05:22 +0100 (CET) Subject: Questions about Stream/Iterable/Files - and possibly the compiler In-Reply-To: References: Message-ID: <2117786125.214078.1446761122608.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Fabrizio Giudici" > ?: core-libs-dev at openjdk.java.net > Envoy?: Jeudi 5 Novembre 2015 22:12:53 > Objet: Questions about Stream/Iterable/Files - and possibly the compiler > > Hello. Hello Fabrizio, > > My question is for the sake of curiosity, not being related to a real > problem - or, better, the problem - which is tiny - can be fixed with a > simple work around. But I'd like to blog a short post about it and I'd > like to check I have all the context. It stemmed from a class about Java 8 > that I recently taught and one of the participants asked about that. > > I think that there's something that possibly involves the compiler - I'll > eventually post the relevant part of the questions to the proper mailing > list. > > > 1. Everything starts from this code chunk that doesnt' compile: > > Stream s = IntStream.rangeClosed(1, 10) // just as an > example to quickly create a Stream > .mapToObj(n -> "String #" + n); > > Files.write(Paths.get("/tmp/pippo.txt"), s); > > error: no suitable method found for write(Path,Stream) > Files.write(Paths.get("/tmp/pippo.txt"), s); > method Files.write(Path,byte[],OpenOption...) is not applicable > (argument mismatch; Stream cannot be converted to byte[]) > method Files.write(Path,Iterable CharSequence>,Charset,OpenOption...) is not applicable > (argument mismatch; Stream cannot be converted to Iterable extends CharSequence>) > method Files.write(Path,Iterable CharSequence>,OpenOption...) is not applicable > (argument mismatch; Stream cannot be converted to Iterable extends CharSequence>) > as you said later, there is no overload that takes a Stream as parameter. > > 2. Variation. > > Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s); > > This gives: > > Exception in thread "main" java.lang.ClassCastException: > java.util.stream.IntPipeline$4 cannot be cast to java.lang.Iterable > at StreamIteratorExample.main(StreamIteratorExample.java:13) > > Ok, so far it's the fact described here > > http://stackoverflow.com/questions/20129762/why-does-streamt-not-implement-iterablet > > on why Stream doesn't implement Iterable. > > Question A: Is the SO answer "because iterator() is usually supposed to be > callable multiple times, while in a Stream it can't" correct? iterator() is not a 'real' method of Stream, it's a kind of escape hatch that you can use if you have an API that takes an Iterator as parameter but it will be slow. > > > 3. This is the known trick around the problem: > > final Iterable i = s::iterator; > Files.write(Paths.get("/tmp/pippo.txt"), i); > > It works and I think I understand why (Iterable has the same functional > descriptor of Supplier, which is s::iterator, so they are > compatible in assignment - right?). yes, Iterable is a functional interface, seen as () -> Iterator by the commpiler, s::iterator is compatible with () -> Iterator, so it works ! (BTW, final is not necessary here) > > > 4. But at this point putting it into the same line gives compilation error: > > Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); > > error: no suitable method found for write(Path,s::iterator) > Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); > method Files.write(Path,byte[],OpenOption...) is not applicable > (argument mismatch; Array is not a functional interface) > method Files.write(Path,Iterable CharSequence>,Charset,OpenOption...) is not applicable > (argument mismatch; bad return type in method reference > Iterator cannot be converted to Iterator) > method Files.write(Path,Iterable CharSequence>,OpenOption...) is not applicable > (argument mismatch; bad return type in method reference > Iterator cannot be converted to Iterator) The conversion from a method reference to a functional interface doesn't work if the target type is parameterized by wildcard. This is specified like this in the Java spec. I consider that this is a bug but this is actually what the spec says. I hope we will be able to fix that in Java 10, but that just my opinion. > > > 5. This at last works: > > Files.write(Paths.get("/tmp/pippo.txt"), > (Iterable)s::iterator); > > I assume that the compiler can't autonomously infer that s::iterator is > compatible with Iterable so the cast is needed. I have a question > about that (feature or bug?), but this is related to the compiler, so I > think is OT here. It's not a feature. It's what the spec says. As i said, i consider it as a bug. > > At last, question B: Given all those premises, is there a specific reason > for which Files.write() hasn't been overloaded with a version capable of > accepting a Stream? It would have been the perfect complement of > Files.lines() adding overloads with different interfaces is not a good idea, you can have a class that implements both interfaces (Stream and Iterable). > > > Thanks. cheers, R?mi > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it > From vladimir.x.ivanov at oracle.com Thu Nov 5 22:06:10 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 Nov 2015 01:06:10 +0300 Subject: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class In-Reply-To: <563B8307.6060008@gmail.com> References: <5630B93E.6020307@oracle.com> <5630F9AF.5040608@oracle.com> <225CAFC1-34B0-4132-B7D8-C76CDEB6C9D8@oracle.com> <5639F795.6000005@gmail.com> <563A66CB.9070705@oracle.com> <563A874E.3010105@gmail.com> <563A9036.7090308@oracle.com> <563AFE84.3020700@gmail.com> <563B3872.8030400@oracle.com> <563B8307.6060008@gmail.com> Message-ID: <563BD2D2.3030508@oracle.com> Peter, Michael, Very good work! I really like how CMH-based BMH & SpeciesData caches shape out in your proposal. > > http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.04/ Small cleanup suggestion: + static boolean speciesDataCachePopulated() { + Class rootCls = BoundMethodHandle.class; try { for (Class c : rootCls.getDeclaredClasses()) { if (rootCls.isAssignableFrom(c)) { final Class cbmh = c.asSubclass(BoundMethodHandle.class); Maybe get rid of multiple BMH mentions here and just use Class and rootCls? > I think this is better then trying to disguise NoClassDefFoundError into > a VirtualMachineError just in order to "fool" the test(s). This is how > VM operates and in general, Error(s) thrown by VM should be propagated > up to the top and reported as-is. We already discussed that aspect. It's not only to fool the tests, but also to provide more meaningful error reporting. I don't think that NoClassDefFoundError is satisfactory. Remember, we started our investigations with a similar type of errors. There are different ways to address the problem, but the most sensible IMO is: (1) split class initialization and Species instantiation; (2) on consecutive attempts after a failed one: either (a) repeat SpeciesData instantiation; or (b) cache first exception and return it. I'd try to instantiate corresponding Species right away and act accordingly. CLASS_CACHE.computeIfAbsent() in getConcreteBMHClass guarantees unique call per key, so no need to piggyback on class initialization anymore. CLASS_CACHE (or CACHE entries?) can be used to store initialization state. What do you think? Best regards, Vladimir Ivanov From maurizio.cimadamore at oracle.com Thu Nov 5 22:34:11 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Nov 2015 22:34:11 +0000 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: <5639e9d9.6a68c20a.60303.4d1c@mx.google.com> References: <1856609155.2548586.1446316180239.JavaMail.zimbra@u-pem.fr> <6F54C4AF-2B92-429B-B452-8FF3C372B6D9@oracle.com> <56355677.c3d41c0a.51143.ffffd3c8@mx.google.com> <5635e543.93d91c0a.2d575.ffff8c11@mx.google.com> <5637566A.3000203@oracle.com> <7BCA7991-4A65-48CA-B8BF-1341076C89F0@oracle.com> <271960317.1523250.1446627830985.JavaMail.zimbra@u-pem.fr> <5639e9d9.6a68c20a.60303.4d1c@mx.google.com> Message-ID: <563BD963.2090005@oracle.com> On 04/11/15 11:19, Timo Kinnunen wrote: > Hi, > > I tested your version of the wildcard counter and it appears to be incompatible with one possible signature of the StackWalker.walk method. > > Here?s my code. Please see the line with ERROR comment: > > static class StackWalker { > static class StackFrame implements CharSequence { > // ... > } > T walk(Function, ? extends T> function, IntUnaryOperator sizing) { > return function.apply(Stream.of("one " + sizing.applyAsInt(1), "two" + sizing.applyAsInt(2)).map(StackFrame::new)); > } > T powerWalk(Function, T> function, IntUnaryOperator sizing) { > return function.apply(Stream.of("one " + sizing.applyAsInt(1), "two" + sizing.applyAsInt(2)).map(StackFrame::new)); > } > } > > static Function, Long> wildCounter() { > return Stream::count; > } > static Function, Long> tameCounter() { > return Stream::count; > } > public static void main(String[] args) { > Function, Long> tameCounter = tameCounter(); > Function, Long> wildCounter = wildCounter(); > Long counted1 = new StackWalker().walk(tameCounter, i -> i); > Long counted2 = new StackWalker().walk(wildCounter, i -> i); > Long counted3 = new StackWalker().powerWalk(tameCounter, i -> i); > Long counted4 = new StackWalker().powerWalk(wildCounter, i -> i); // ERROR > System.out.println(counted1 + counted2 + counted3 + counted4); > } > > This may be a problem with javac, but it doesn?t exactly inspire confidence in me towards wildcards. More like it?s another example in a long-running pattern of bad behavior. The version by Paul Sandoz compiles without issues, no surprises there as usual. > > And this is what javac is telling me: > > Information:Using javac 1.8.0_65 to compile java sources > Error:(77, 50) java: method powerWalk in class nonnulls.GenericTest.StackWalker cannot be applied to given types; > required: java.util.function.Function,T>,java.util.function.IntUnaryOperator > found: java.util.function.Function,java.lang.Long>,(i)->i > reason: cannot infer type-variable(s) T > (argument mismatch; java.util.function.Function,java.lang.Long> cannot be converted to java.util.function.Function,T>) Right - you are passing a Function, Long> where a Function, T> is expected - regardless of what happens to the inference variable T, for this to be valid, it must be that Stream == Stream, which is obviously not the case. There's no doubt that '? super' is needed in the argument position for Function - as to the '? extends' in the return type I think it's irrelevant - i.e. this: T powerWalk(Function, T> function, IntUnaryOperator sizing) { and T powerWalk(Function, ? extends T> function, IntUnaryOperator sizing) { Should result in having same applicability. Maurizio > > > > Sent from Mail for Windows 10 > > > > From: Remi Forax > Sent: Wednesday, November 4, 2015 10:04 > To: Paul Sandoz > Cc: core-libs-dev at openjdk.java.net > Subject: Re: Proposed API for JEP 259: Stack-Walking API > > > Hi Paul, > > The use of BaseStream was just an example, here is another one that works only if the function first parameter type is declared as '? super Stream'. > > static Function, Integer> counter() { > return stream::count; > } > > ... > StackWalker walker = ... > int count = walker.walk(counter()); > > regards, > R?mi > > ----- Mail original ----- >> De: "Paul Sandoz" >> Cc: core-libs-dev at openjdk.java.net >> Envoy?: Lundi 2 Novembre 2015 13:44:24 >> Objet: Re: Proposed API for JEP 259: Stack-Walking API >> >> I agree with Maurizio, the first signature is good enough. >> >> One could argue that it might be better to apply PECS since it would >> encourage more consistent usage when it is actually required as all too >> often it?s easy to forget, and then too late to change. However, i don?t >> want to encourage the use of BaseStream since it was an unfortunate mistake >> that this made public. >> >> Paul. >> >>> On 2 Nov 2015, at 13:26, Maurizio Cimadamore >>> wrote: >>> >>> So, we have three potential signatures here: >>> >>> T walk(Function, T> function) //1 >>> >>> T walk(Function, ? extends T> function) >>> //2 >>> >>> T walk(Function, R> >>> function) //3 >>> >>> >>> Under normal conditions (i.e. lambda parameter being passed to 'walk') I >>> think all these signatures are fundamentally equivalent; (2) and (3) seem >>> to have been designed for something like this: >>> >>> Number n = walk(s -> new Integer(1)); >>> >>> That is, the function returns something that is more specific w.r.t. what >>> is expected in the return type of walk. But - in reality, if 'walk' >>> returns an R that is a subtype of T (as in the third signature), then walk >>> also returns a T (as R is a subtype of T), so the result value can be >>> passed where a T is expected. >>> >>> The converse example: >>> >>> Integer n1 = walk(s -> (Number)null); >>> >>> Similarly fails on all three signatures. >>> >>> >>> More generally, with all such signatures, T will always receive: >>> >>> * lower bound(s) (from the return value(s) of the lambda passed as a >>> parameter to the 'walk' method) >>> * one upper bound (from the target-type associated with the 'walk' call. >>> >>> Under such conditions, the upper bound will always be disregarded in favor >>> of the lower bounds - meaning that instantiation of T will always be >>> driven by what's inside the lambda. Signature (3) mentions different >>> variables (R and T) but the end result is the same - as the bound says R >>> extends T - meaning that lower bounds of R are propagated to T - leading >>> to exactly the same situation. >>> >>> >>> In other words, I don't think there are obvious examples in which the >>> behavior of these three signatures will be significantly different - if >>> the return type of 'walk' would have been a generic type such as List, >>> the situation would have been completely different - with with a 'naked' >>> T, I think the first signature is good enough, and the third is, in my >>> opinion, making things harder than what they need to be. >>> >>> I think the second signature is not necessary, from a pure type-system >>> perspective; but I guess one could make an argument for it, but purely in >>> terms of consistency with other areas (after all, the second >>> type-parameter of a Function is in a covariant position). >>> >>> I hope this helps. >>> >>> Maurizio >>> > From david.lloyd at redhat.com Thu Nov 5 22:43:17 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 5 Nov 2015 16:43:17 -0600 Subject: Proposed API for JEP 259: Stack-Walking API In-Reply-To: References: <5633CC1E.1030603@redhat.com> <3E3E56F1-6402-4CFF-84E1-9CEE9CC0D34C@oracle.com> <5633F14B.4080503@redhat.com> <5779E088-D59B-427F-83E9-3EB160386CD7@oracle.com> <56375B18.1010800@redhat.com> Message-ID: <563BDB85.5090109@redhat.com> On 11/04/2015 07:15 PM, Mandy Chung wrote: > [...] > For short-circuiting, I also think it?s reasonable to expect the user know how many remaining frames it expects to traverse and it may not need to increase the batch size i.e. it might not need to update the remainingNeeded over time. The user to supply the estimate number of frames needed may be adequate for it (like what you suggest previously having the walk method to take an initial batch size for the simple case). > > Walking the entire stack (or almost all stack frames) is the use case that this hint may help in performance since the stack depth is unknown and it?s a tradeoff between memory and runtime. Throwable::init and AccessControlContext are the use cases that need to be performant. It?s better to wait for more experience of using the StackWalker and see if any other use cases need adaptive sizing . I propose to drop this walk(Function, IntUnaryFunction) for now and decide to add such ability later. Yeah I agree, and furthermore I strongly suspect that there is only one "best" batch size for the majority of whole-stack traversals. > For taking the estimated number of consumed frames, one option is to have a walk(int initialFramesNeeded, Function function) method. The other option is to have the > StackWalker(int minDepth, int maxDepth, Set