Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-02 Thread Peter Levart
On 11/01/2013 10:11 PM, Mandy Chung wrote: On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote: 2013/11/1 4:15 -0700, mandy.ch...@oracle.com: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/ Looks good. Just one question: In Finalizer.java, at line 97 you look up the

Assorted annotation optimizations

2013-11-02 Thread Peter Levart
Hi, I propose a set of straightforward optimizations of annotations in the field of minimizing garbage creation and execution performance. Here's a webrev containing the changes: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationOptimizations/webrev.01/ Changes grouped by class/method:

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-03 Thread Peter Levart
On 11/04/2013 05:45 AM, Mandy Chung wrote: On 11/3/2013 5:32 PM, David Holmes wrote: Hi Mandy, On 2/11/2013 7:11 AM, Mandy Chung wrote: On 11/1/13 1:37 PM, mark.reinh...@oracle.com wrote: 2013/11/1 4:15 -0700, mandy.ch...@oracle.com:

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-03 Thread Peter Levart
On 11/04/2013 07:52 AM, Peter Levart wrote: Also VM.awaitBooted seems inherently risky as a general method as you would have to make sure that it is never called by the main VM initialization thread. Perhaps handle this in sun.misc.SharedSecrets.getJavaLangAccess so it is less 'general

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-04 Thread Peter Levart
On 11/04/2013 05:45 AM, Mandy Chung wrote: That said I think Peter may be right that there could be races with agents triggerring explicit finalization requests early in the VM initialization process - which means any blocking operation dependent on other parts of the initialization sequence

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-04 Thread Peter Levart
On 11/04/2013 09:48 AM, Alan Bateman wrote: On 04/11/2013 08:33, Peter Levart wrote: : What about the following helper class in java.lang package: If public then it leaks into the Java SE API. I think using SharedSecrets should be okay, assuming we can sort out any potential races getting

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-04 Thread Peter Levart
On 11/05/2013 03:21 AM, Mandy Chung wrote: On 11/4/2013 6:03 PM, David Holmes wrote: Hi Mandy, This all seems quite reasonable to me. Two minor nits: 1. The delay ntil typo in Finalizer.java is still present. Missed that :( 2. In VM.java. booted need not be volatile now that it is only

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-05 Thread Peter Levart
Hi Robert, I think this fix is not complete. When one sets the system property sun.reflect.noInflation=true, reflection proxy is still attempted to be generated for anonymous classes (see ReflectionFactory.newMethodAccessor/newConstructorAccessor). I would also restructure the

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-05 Thread Peter Levart
On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote: Changeset: 51b002381b35 Author:rfield Date: 2013-11-04 10:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class 8027681: Lambda

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-05 Thread Peter Levart
the trailing '/798154996' just before ';' Regards, Peter On 11/05/2013 09:55 AM, Peter Levart wrote: On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote: Changeset: 51b002381b35 Author:rfield Date: 2013-11-04 10:12 -0800 URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-05 Thread Peter Levart
On 11/05/2013 10:33 AM, Joel Borggrén-Franck wrote: I would also restructure the Method/Constructor accessor logic differently. The check for ReflectUtil.isVMAnonymousClass() can be performed just once (in the newMethodAccessor/newConstructorAccessor methods) and based on this check, create

Re: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass

2013-11-05 Thread Peter Levart
On 11/05/2013 12:33 PM, Chris Hegarty wrote: On 05/11/2013 10:59, Paul Sandoz wrote: On Nov 5, 2013, at 8:26 AM, Peter Levartpeter.lev...@gmail.com wrote: P.S. I'm curious about the strange seemingly unneeded code fragments in FinalizerThread and both Runnables. For example: 169

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-06 Thread Peter Levart
On 11/06/2013 11:37 AM, Remi Forax wrote: On 11/05/2013 11:11 AM, Joel Borggrén-Franck wrote: On 5 nov 2013, at 10:51, Peter Levart peter.lev...@gmail.com wrote: On 11/05/2013 10:33 AM, Joel Borggrén-Franck wrote: I would also restructure the Method/Constructor accessor logic differently

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-06 Thread Peter Levart
== '/') return true; if (c '0' || c '9') return false; } return false; } Regards, Peter Sent from my iPhone On Nov 5, 2013, at 8:55 AM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-07 Thread Peter Levart
On 11/07/2013 02:20 AM, John Rose wrote: On Nov 6, 2013, at 11:30 AM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: Well, indexOf(char) or lastIndexOf(char) searches for a single char. We can do better searching backwards for two chars at the same time

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

2013-11-10 Thread Peter Levart
On 11/11/2013 02:24 AM, Ali Ebrahimi wrote: This is another workaround: public T extends MemberAnnotatedElement, R R reflectAs(Class? super T expected, Lookup lookup); info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

2013-11-11 Thread Peter Levart
On 11/11/2013 08:14 AM, Peter Levart wrote: The method could simply be: public T extends Member T reflect(Lookup lookup); But if one needs to hint the compiler, explicit type parameters can be used as an escape hatch as always: Object o = info.Methodreflect(lookup); Well, well

Re: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

2013-11-11 Thread Peter Levart
On 11/05/2013 12:29 AM, Remi Forax wrote: But you are right that there is a performance pothole in the interoperation between lambdas and reflection. This implementation RFE, to use method handles instead of code spinning, would take care of that particular problem:

Re: Why stream from BufferedReader::lines is not closing the reader?

2013-11-18 Thread Peter Levart
On 11/18/2013 03:28 PM, Brian Goetz wrote: Which means that, if your stream holds non-memory resources, the flatMapper should create a stream that closes the underlying stream, like: blah.flatMap(path - { BufferedReader br = new BufferedReader(path); return

Re: CallerSensitive access rights problems

2013-11-18 Thread Peter Levart
On 11/18/2013 04:31 PM, Alan Bateman wrote: On 18/11/2013 14:59, Jochen Theodorou wrote: Hi, java.lang.Class has multiple methods annotated with CallerSensitive (see http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/tip/src/share/classes/java/lang/Class.java). Now if we in Groovy here

Re: Map.Entry.setValue as a default method

2013-11-21 Thread Peter Levart
On 11/21/2013 03:56 PM, Remi Forax wrote: Maybe one of: interface KoolReusablePair { default boolean defaultEquals(Object x) { ... } static int hashCode(KoolReusablePair self) { ... } ... } class KoolImpl implements KoolReusablePair { @Override //manual opt-in: public

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-27 Thread Peter Levart
On 11/27/2013 08:40 AM, David Holmes wrote: On 27/11/2013 2:16 AM, David Chase wrote: On 2013-11-26, at 8:12 AM, David Chase david.r.ch...@oracle.com wrote: On 2013-11-26, at 7:32 AM, David Holmes david.hol...@oracle.com wrote: On 26/11/2013 10:16 PM, David Chase wrote: On 2013-11-26, at

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-27 Thread Peter Levart
On 11/27/2013 11:03 AM, David Holmes wrote: Hi Peter, On 27/11/2013 7:20 PM, Peter Levart wrote: On 11/27/2013 08:40 AM, David Holmes wrote: On 27/11/2013 2:16 AM, David Chase wrote: On 2013-11-26, at 8:12 AM, David Chase david.r.ch...@oracle.com wrote: On 2013-11-26, at 7:32 AM, David

Re: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

2013-11-27 Thread Peter Levart
On 11/27/2013 02:40 PM, David Chase wrote: On 2013-11-27, at 6:53 AM, Peter Levart peter.lev...@gmail.com wrote: Ah, I have misunderstood the back-porting issue. It was not about not having new class but about which existing class to use as a host that might not exist in older version

Re: 8029281: Synchronization issues in Logger and LogManager

2013-11-27 Thread Peter Levart
Hi Daniel, I have started looking at the LogManager change first, and here's the 1st race I found... The new method LoggerWeakRef.dispose() can be called from 3 places: - LoggerContext.addLocalLogger - LoggerContext.findLogger - LogManager.drainLoggerRefQueueBounded which is called from

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-11-28 Thread Peter Levart
On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: The problem is that we use a logger in CustomerFormatter and this causes Logger.log call Logger.log itself. As FileHandler.publish and StreamHandler.publish is synchronized, but the iteration to call publish method for all handlers in Logger.log is

Re: 8029281: Synchronization issues in Logger and LogManager

2013-12-02 Thread Peter Levart
://cr.openjdk.java.net/~dfuchs/webrev_8029281/webrev.01/ It has passed all jdk_core tests and running the new tests in a loop hasn't triggered any of the issues that appeared before the fix. -- daniel On 11/28/13 3:26 PM, Daniel Fuchs wrote: On 11/27/13 10:34 PM, Peter Levart wrote: Hi Daniel, I

Theoretical data race on java.util.logging.Handler.sealed

2013-12-03 Thread Peter Levart
Hi, While browsing the code of java.util.logging.Handler, I noticed a theoretical possibility that a security check in a j.u.l.StreamHandler be circumvented using a data race. There is a plain boolean instance field 'sealed' in j.u.l.Handler that is pre-initialized to 'true' in field

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-03 Thread Peter Levart
On 12/03/2013 09:51 AM, Peter Levart wrote: Hi, While browsing the code of java.util.logging.Handler, I noticed a theoretical possibility that a security check in a j.u.l.StreamHandler be circumvented using a data race. There is a plain boolean instance field 'sealed' in j.u.l.Handler

Re: RFR [6968459] JNDI timeout fails before timeout is reached

2013-12-03 Thread Peter Levart
On 11/29/2013 09:06 PM, Ivan Gerasimov wrote: Thank you Alan for the reply! On 29.11.2013 21:03, Alan Bateman wrote: On 19/11/2013 17:58, Ivan Gerasimov wrote: Hello all! Would you please help review a fix for the bug? https://bugs.openjdk.java.net/browse/JDK-6968459 It was reported that

Re: RFR [6968459] JNDI timeout fails before timeout is reached

2013-12-03 Thread Peter Levart
On 12/03/2013 03:35 PM, Ivan Gerasimov wrote: Hi Peter! Thank you for your review! You are right, the patch changed the behavior of the code. I've reverted back all the unnecessary changes. This should minimize the risk. I've also made another correction: After decrementing the remaining

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-12-05 Thread Peter Levart
On 12/05/2013 07:54 AM, Shi Jun Zhang wrote: On 11/30/2013 12:05 AM, Daniel Fuchs wrote: On 11/29/13 4:56 PM, Alan Bateman wrote: On 29/11/2013 10:08, Daniel Fuchs wrote: However, removing or just moving the lock around might well introduce new unknown issues - so it will need to be

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-08 Thread Peter Levart
On 12/04/2013 12:27 AM, Mandy Chung wrote: On 12/3/2013 1:44 AM, Peter Levart wrote: On 12/03/2013 09:51 AM, Peter Levart wrote: Hi, While browsing the code of java.util.logging.Handler, I noticed a theoretical possibility that a security check in a j.u.l.StreamHandler be circumvented

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-12-09 Thread Peter Levart
On 12/09/2013 08:02 AM, Shi Jun Zhang wrote: Peter, I think you are misunderstanding this problem. This deadlock is not related to the formatter synchronization, we can make CustomerFormatter.format not synchronized and not call super.format, the deadlock still happens. I'm not saying that

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-12-09 Thread Peter Levart
On 12/09/2013 09:28 AM, Peter Levart wrote: On 12/09/2013 08:02 AM, Shi Jun Zhang wrote: Peter, I think you are misunderstanding this problem. This deadlock is not related to the formatter synchronization, we can make CustomerFormatter.format not synchronized and not call super.format

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-12-09 Thread Peter Levart
On 12/09/2013 09:51 AM, Shi Jun Zhang wrote: On 12/9/2013 4:28 PM, Peter Levart wrote: On 12/09/2013 08:02 AM, Shi Jun Zhang wrote: Peter, I think you are misunderstanding this problem. This deadlock is not related to the formatter synchronization, we can make CustomerFormatter.format

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-12-09 Thread Peter Levart
On 12/09/2013 10:50 AM, Shi Jun Zhang wrote: On 12/9/2013 4:40 PM, Peter Levart wrote: On 12/09/2013 09:28 AM, Peter Levart wrote: On 12/09/2013 08:02 AM, Shi Jun Zhang wrote: Peter, I think you are misunderstanding this problem. This deadlock is not related to the formatter synchronization

Re: Deadlock between FileHandler and ConsoleHandler when using customized formatter

2013-12-09 Thread Peter Levart
On 12/09/2013 11:12 AM, Daniel Fuchs wrote: On 12/9/13 9:58 AM, Peter Levart wrote: On 12/09/2013 09:51 AM, Shi Jun Zhang wrote: On 12/9/2013 4:28 PM, Peter Levart wrote: On 12/09/2013 08:02 AM, Shi Jun Zhang wrote: Peter, I think you are misunderstanding this problem. This deadlock

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-14 Thread Peter Levart
Hi Mandy, On 12/13/2013 12:37 AM, Mandy Chung wrote: Hi Peter, On 12/8/2013 11:19 AM, Peter Levart wrote: H Mandy, I created an issue for it nevertheless: https://bugs.openjdk.java.net/browse/JDK-8029781 You're right, doPrivileged() is a more straight-forward approach than 'sealed

Re: Review request for 8021368: Launch of Java Web Start app fails with ClassCircularityError exception

2013-12-14 Thread Peter Levart
On 12/12/2013 07:29 PM, Mandy Chung wrote: JDK-8021368: Launch of Java Web Start app fails with ClassCircularityError exception in 7u25 https://bugs.openjdk.java.net/browse/JDK-8021368 This is a fix for 7u60 only. It's a regression in 7u25 due to JDK-8010117 where it calls Class.getMethod

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-14 Thread Peter Levart
to ConfigureActions(s) that follow the overloaded constructors of various Handlers. Regards, Peter On 12/14/2013 12:25 PM, Peter Levart wrote: Hi Mandy, On 12/13/2013 12:37 AM, Mandy Chung wrote: Hi Peter, On 12/8/2013 11:19 AM, Peter Levart wrote: H Mandy, I created an issue

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-17 Thread Peter Levart
On 12/17/2013 11:29 AM, Daniel Fuchs wrote: On 12/16/13 10:14 PM, Mandy Chung wrote: On 12/14/2013 9:38 AM, Peter Levart wrote: Hi, Daniel reminded me of a couple of issues the 4th revision of the patch would have when backporting to 7u. So here's another variant that tries to be more

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-17 Thread Peter Levart
...@oracle.com To: peter.lev...@gmail.com Subject: Re: Theoretical data race on java.util.logging.Handler.sealed CC: core-libs-dev@openjdk.java.net On 12/14/2013 9:38 AM, Peter Levart wrote: Hi, Daniel reminded me of a couple of issues the 4th revision of the patch would have when backporting

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-17 Thread Peter Levart
@openjdk.java.net On 12/14/2013 9:38 AM, Peter Levart wrote: Hi, Daniel reminded me of a couple of issues the 4th revision of the patch would have when backporting to 7u. So here's another variant that tries to be more backport-friendly: http://cr.openjdk.java.net/~plevart/jdk8-tl

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-17 Thread Peter Levart
On 12/17/2013 11:02 PM, Daniel Fuchs wrote: On 12/17/13 6:02 PM, Peter Levart wrote: On 12/17/2013 05:26 PM, Mandy Chung wrote: This is a good point. The patch for JDK 8 and above uses limited doPrivileged that only grants LoggingPermission(control) access even though the system class has

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-18 Thread Peter Levart
On 12/18/2013 12:05 PM, Daniel Fuchs wrote: But then we have another problem with doPrivileged approach, since it is even more restrictive than 'sealed' field approach. Currently the Handler's subclass that overrides a setter and calls super, works: @Override public void

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-18 Thread Peter Levart
On 12/17/2013 06:43 PM, Mandy Chung wrote: Can you check what methods are called by the constructors whose access are denied in the current implementation but granted in the patch? I have to take another look to make sure but I believe they only calls the methods in the handler classes that

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-18 Thread Peter Levart
On 12/17/2013 06:43 PM, Mandy Chung wrote: Can you check what methods are called by the constructors whose access are denied in the current implementation but granted in the patch? I have to take another look to make sure but I believe they only calls the methods in the handler classes that

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-19 Thread Peter Levart
On 12/18/2013 11:55 PM, Mandy Chung wrote: On 12/18/2013 9:03 AM, Peter Levart wrote: Hi Mandy, Daniel, Here's yet another variant that reduces the doPrivileged code to just Handler's setters. This way no LogManager methods are invoked under elevated privilege: http://cr.openjdk.java.net

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2013-12-21 Thread Peter Levart
Hi David, Is it possible to get the test output when it fails? It can fail in two different ways. I can't look at the bug (not authorized)... On 12/20/2013 10:54 AM, Chris Hegarty wrote: On 20 Dec 2013, at 04:33, Mandy Chung mandy.ch...@oracle.com wrote: Hi Srikalyan, Maybe you can get

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-22 Thread Peter Levart
Hi Mandy, On 12/19/2013 10:38 PM, Mandy Chung wrote: On 12/19/13 7:49 AM, Peter Levart wrote: Hi Mandy, Daniel, I didn't like the package-protected getters either. So here's another variant that replaces Handler.configure() method with a package-protected constructor which is chained from

Re: (reflect) Accessing members of inner annotations types

2014-01-03 Thread Peter Levart
I think the problem is as follows... Annotations are implemented as Java dynamic Proxy classes. The generated proxy class for a package-private interface is created in the same package as the interface so that it has access to the interface. The top level interface can be package private, but

Re: (reflect) Accessing members of inner annotations types

2014-01-03 Thread Peter Levart
On 01/03/2014 03:52 PM, Peter Levart wrote: This is would be all right until such proxy class (com.sun.proxy.$Proxy1 in our example) has to access some package-private types in some specific package. This happens in your Named.List annotation implementation class. It implements a member

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-07 Thread Peter Levart
On 01/07/2014 03:15 AM, srikalyan chandrashekar wrote: Sure David will give that a try, we have so far attempted to 1. Print state data(as per the test creator peter.levart's inputs), Hi Kalyan, Have you been able to reproduce the OOME in that set-up? What was the result? Regards, Peter

Re: Theoretical data race on java.util.logging.Handler.sealed

2014-01-07 Thread Peter Levart
Hi Mandy, Daniel, Thanks for reviews. I just pushed this change to jdk9-dev/jdk ... Regards, Peter On 12/23/2013 05:50 AM, Mandy Chung wrote: On 12/22/2013 5:23 AM, Peter Levart wrote: Hi Mandy, On 12/19/2013 10:38 PM, Mandy Chung wrote: On 12/19/13 7:49 AM, Peter Levart wrote: Hi Mandy

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-08 Thread Peter Levart
On 01/08/2014 07:30 AM, David Holmes wrote: On 8/01/2014 4:19 PM, David Holmes wrote: On 8/01/2014 7:33 AM, srikalyan chandrashekar wrote: Hi David, TraceExceptions with fastdebug build produced some nice trace http://cr.openjdk.java.net/%7Esrikchan/OOME_exception_trace.log . The native method

Re: (reflect) Accessing members of inner annotations types

2014-01-08 Thread Peter Levart
On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: Hi Peter, On 2014-01-03, Peter Levart wrote: On 01/03/2014 03:52 PM, Peter Levart wrote: This is would be all right until such proxy class (com.sun.proxy.$Proxy1 in our example) has to access some package-private types in some specific

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-10 Thread Peter Levart
() returns, so it may well be caught after that - in which case this was not a failing run. I also can't reproduce the problem :( David On 8/01/2014 10:34 PM, Peter Levart wrote: On 01/08/2014 07:30 AM, David Holmes wrote: On 8/01/2014 4:19 PM, David Holmes wrote: On 8/01/2014 7:33 AM, srikalyan

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-10 Thread Peter Levart
On 01/10/2014 09:31 AM, Peter Levart wrote: Since we suspect there's something wrong with exception handling in interpreter, I devised a hypothetical reproducer that tries to simulate ReferenceHandler in many aspects, but doesn't require to be a ReferenceHandler: http://cr.openjdk.java.net

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-11 Thread Peter Levart
--- Thanks kalyan On 01/10/2014 02:57 AM, Peter Levart wrote: On 01/10/2014 09:31 AM, Peter Levart wrote: Since we suspect there's something wrong with exception handling in interpreter, I devised a hypothetical reproducer that tries to simulate ReferenceHandler in many aspects, but doesn't require

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-17 Thread Peter Levart
() in ReferenceHandler makes sense to me. Why would we need this? David - --- Thanks kalyan On 01/13/2014 03:57 PM, srikalyan wrote: On 1/11/14, 6:15 AM, Peter Levart wrote: On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote: Hi Peter the version you provided ran indefinitely(i put a 10

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-17 Thread Peter Levart
On 01/17/2014 02:00 PM, Peter Levart wrote: On 01/17/2014 05:38 AM, David Holmes wrote: On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: Hi David, the disassembled code is also attached to the bug. Per my Sorry missed that. analysis the exception was thrown when Reference Handler

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-17 Thread Peter Levart
On 01/17/2014 02:13 PM, Peter Levart wrote: // Fast path for cleaners boolean isCleaner = false; try { isCleaner = r instanceof Cleaner; } catch (OutofMemoryError oome) { continue; } if (isCleaner) { ((Cleaner)r).clean(); continue; } Hi David, Kalyan, I've caught-up now. Just

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-20 Thread Peter Levart
On 01/20/2014 02:51 AM, David Holmes wrote: Hi Peter, On 17/01/2014 11:24 PM, Peter Levart wrote: On 01/17/2014 02:13 PM, Peter Levart wrote: // Fast path for cleaners boolean isCleaner = false; try { isCleaner = r instanceof Cleaner; } catch (OutofMemoryError oome) { continue

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-20 Thread Peter Levart
that other threads dont' get enough CPU time to proceed and clean things up (we hope other threads will also get OOME and release things as their stacks unwind...). Regards, Peter Thanks, David On 20/01/2014 6:42 PM, Peter Levart wrote: On 01/20/2014 09:00 AM, Peter Levart wrote: On 01/20/2014 02

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread Peter Levart
the OOMEInReferenceHandler test with this code and report any failure. Thanks, Peter On 01/21/2014 08:57 AM, David Holmes wrote: On 21/01/2014 4:54 PM, Peter Levart wrote: On 01/21/2014 03:22 AM, David Holmes wrote: Hi Peter, I do not see Cleaner being loaded prior to the main class

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread Peter Levart
On 01/21/2014 08:57 AM, David Holmes wrote: [Loaded java.util.TimeZone from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfo from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile from

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread Peter Levart
On 01/21/2014 07:54 AM, Peter Levart wrote: *[Loaded sun.misc.Cleaner from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]* [Loaded java.io.ByteArrayInputStream from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar] [Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule from

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-21 Thread Peter Levart
java.lang.Class object is allocated on heap. Regards, Peter Please correct if i am missing something here. Meanwhile i will give the version of Reference Handler you both agreed on a try. -- Thanks kalyan Ph: (408)-585-8040 On 1/21/14, 7:24 AM, Peter Levart wrote: On 01/21/2014 07:54 AM

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-24 Thread Peter Levart
(not heap). The class_mirror is a Java object not meta-data. David -- Thanks kalyan Ph: (408)-585-8040 On 1/21/14, 2:31 PM, Peter Levart wrote: On 01/21/2014 07:17 PM, srikalyan wrote: Hi Peter/David, catching up after long weekend. Why would there be an OOME in object heap due to class

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-24 Thread Peter Levart
On 01/22/2014 03:19 AM, David Holmes wrote: Hi Peter, On 22/01/2014 12:00 AM, Peter Levart wrote: Hi, David, Kalyan, Summing up the discussion, I propose the following patch for ReferenceHandler: http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/webrev.01/ I can live

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-26 Thread Peter Levart
, Kalyan? If I get a go also from David, I'll commit this to jdk9/dev... Regards, Peter -- Thanks kalyan On 1/24/14 4:05 PM, Peter Levart wrote: On 01/24/2014 02:53 AM, srikalyan chandrashekar wrote: Hi David, yes thats right, only benefit i see is we can avoid assignment to 'r' if pending

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-28 Thread Peter Levart
On 01/28/2014 03:17 AM, David Holmes wrote: On 27/01/2014 5:07 AM, Peter Levart wrote: On 01/25/2014 05:35 AM, srikalyan chandrashekar wrote: Hi Peter, if you are a committer would you like to take this further (OR) perhaps david could sponsor this change. Hi, Here's new webrev that takes

Re: RFR(s): 8023541 Race condition in rmid initialization

2014-01-29 Thread Peter Levart
Hi Stuart, My eye was caught by the following new method: 328 private synchronized void awaitInitialized() { 329 try { 330 while (!initialized) { 331 wait(); 332 } 333 } catch (InterruptedException ie) {

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-29 Thread Peter Levart
On 01/28/2014 04:46 PM, Alan Bateman wrote: On 28/01/2014 08:44, Peter Levart wrote: Yes, I tried that too and it results in even more unsafe casts. It's odd yes, since the compile-time error is not present when building via OpenJDK build system make files (using make images in top

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-30 Thread Peter Levart
On 01/30/2014 03:46 PM, Alan Bateman wrote: On 29/01/2014 19:10, Mandy Chung wrote: On 1/29/2014 5:09 AM, Peter Levart wrote: Since I don't know what should be the correct behaviour of javac, I can leave the Reference.java changes as proposed since it compiles in both cases. Or should I

RFR - 6857566 (bf) DirectByteBuffer garbage creation can outpace reclamation

2014-02-05 Thread Peter Levart
Hi, I'm proposing a patch for the following issue: https://bugs.openjdk.java.net/browse/JDK-6857566 The patch is basically the same as developed and tested as part of the following discussion 3 months ago: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021547.html

Re: ObjectIn/OutputStream improvements

2014-02-05 Thread Peter Levart
On 02/05/2014 04:11 PM, Chris Hegarty wrote: Thanks stuart, Mike, and Paul. - Why not have getClassSignature() return an interned string? (that's if interning is actually essential. Are we sure it's not just overhead?) I didn’t want to change the existing use of interning here, just refactor

Re: RFR - 6857566 (bf) DirectByteBuffer garbage creation can outpace reclamation

2014-02-20 Thread Peter Levart
On 02/05/2014 11:21 AM, Alan Bateman wrote: On 05/02/2014 08:08, Peter Levart wrote: Hi, I'm proposing a patch for the following issue: https://bugs.openjdk.java.net/browse/JDK-6857566 The patch is basically the same as developed and tested as part of the following discussion 3 months

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-20 Thread Peter Levart
On 02/20/2014 11:20 AM, David Holmes wrote: Hi Brian, On 20/02/2014 7:44 AM, Brian Burkhalter wrote: This patch concerns cleaning up some ugly internal deprecations. Issue:https://bugs.openjdk.java.net/browse/JDK-8035279 Webrev:http://cr.openjdk.java.net/~bpb/8035279/webrev.00/ All

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-21 Thread Peter Levart
On 02/21/2014 10:06 AM, Paul Sandoz wrote: I think we should try and use zero, as John says (alas @Stable is package private to j.l.invoke), and replace 0 with another value such as MIN_VALUE if one is unsure of the bounds: int lsb; if ((lsb = lowestSetBit) == 0) { ...

Re: [7u backport] RFR: 7122142: (ann) Race condition between isAnnotationPresent and getAnnotations

2014-02-24 Thread Peter Levart
Hi Dmeetry, On 02/22/2014 01:22 PM, dmeetry degrave wrote: Hi all, I would like to ask for a review of combined back port for 7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it also integrates the changes from 8005232, 7185456, 8022721

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-26 Thread Peter Levart
On 02/25/2014 09:38 PM, Brian Burkhalter wrote: On Feb 20, 2014, at 1:42 AM, Paul Sandoz wrote: Not sure the static powerCache field, in the original code, needs to be volatile either: 1137 private static volatile BigInteger[][] powerCache; Is there consensus on whether volatile is

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-26 Thread Peter Levart
On 02/26/2014 09:54 PM, Martin Buchholz wrote: I don't recall having added this particular wart to test/java/lang/ProcessBuilder/Basic.java, and history suggests that others did that. It does seem that being able to tell whether a java object monitor is currently locked is useful for debugging

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-26 Thread Peter Levart
On 02/27/2014 08:29 AM, Peter Levart wrote: On 02/26/2014 09:54 PM, Martin Buchholz wrote: I don't recall having added this particular wart to test/java/lang/ProcessBuilder/Basic.java, and history suggests that others did that. It does seem that being able to tell whether a java object monitor

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread Peter Levart
On 02/27/2014 08:41 AM, David Holmes wrote: On 27/02/2014 5:30 PM, Peter Levart wrote: On 02/27/2014 08:29 AM, Peter Levart wrote: On 02/26/2014 09:54 PM, Martin Buchholz wrote: I don't recall having added this particular wart to test/java/lang/ProcessBuilder/Basic.java, and history suggests

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-02-27 Thread Peter Levart
On 02/27/2014 10:58 AM, David Holmes wrote: On 27/02/2014 6:38 PM, Peter Levart wrote: On 02/27/2014 08:41 AM, David Holmes wrote: On 27/02/2014 5:30 PM, Peter Levart wrote: On 02/27/2014 08:29 AM, Peter Levart wrote: On 02/26/2014 09:54 PM, Martin Buchholz wrote: I don't recall having

Re: JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

2014-02-27 Thread Peter Levart
On 02/27/2014 09:22 AM, Paul Sandoz wrote: On Feb 27, 2014, at 12:51 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Feb 26, 2014, at 1:53 PM, Paul Sandoz wrote: Thanks for the suggestion, Paul. Assuming it is correct, in what way would this be a better approach? (I apologize

Re: rationale for swallowing exceptions in Class#getEnumConstantsShared

2014-02-28 Thread Peter Levart
On 02/28/2014 04:56 PM, Jochen Theodorou wrote: Hi, we stumbled here about a strange error involving enums generated from our compiler and that did make me see getEnumConstantsShared() in java.lang.Class. Now the implementation more or less says, that if calling values() fails in any way,

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-03-03 Thread Peter Levart
On 03/04/2014 05:09 AM, David Holmes wrote: On 4/03/2014 1:45 PM, David Holmes wrote: On 3/03/2014 10:56 PM, David M. Lloyd wrote: Yes, that would necessarily be the contract of a Monitors class, just as it is part of the contract of Lock today. If your argument is that it shouldn't be

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

2014-03-03 Thread Peter Levart
On 03/04/2014 08:01 AM, Peter Levart wrote: On 03/04/2014 05:09 AM, David Holmes wrote: On 4/03/2014 1:45 PM, David Holmes wrote: On 3/03/2014 10:56 PM, David M. Lloyd wrote: Yes, that would necessarily be the contract of a Monitors class, just as it is part of the contract of Lock today

Re: How to close a Process and having shutdown hooks called ?

2014-03-04 Thread Peter Levart
On 03/04/2014 02:09 PM, LE PICARD NICOLAS wrote: I didn't know for jdk8 functions destroy and the new one destroyForcibly... And Jonathan was right in his previous answer, I was looking for a solution in Java, I mean a portable one like in Process class, like the destroyGracefully. I am

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

2014-03-04 Thread Peter Levart
On 03/04/2014 01:14 AM, Brian Burkhalter wrote: - add AtomicReferenceFieldUpdater-type constant for stringCache initialization Hi Brian, By using volatile read and CAS, there's still a chance that multiple concurrent threads will be invoking the layoutChars(true) concurrently, but you

Re: JEP 193: Enhanced Volatiles

2014-03-05 Thread Peter Levart
On 03/05/2014 05:55 PM, Jeroen Frijters wrote: Brian Goetz wrote: I suspect you were expecting this response: we don't add language semantics through annotations. Technically, we're not adding language semantics. The JVM is the one interpreting the annotations. And the JVM is the one

Re: Review 8035808: Eliminate dependency to GetPropertyAction and other sun.security.action convenient classes

2014-03-07 Thread Peter Levart
On 03/07/2014 12:31 PM, Alan Bateman wrote: On 06/03/2014 21:10, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035808/webrev.00/ This patch converts the use of sun.security.action.GetPropertyAction tolambda (PrivilegedActionString) () -

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

2014-03-11 Thread Peter Levart
Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do with hiding the call frames in stack traces that are part of LambdaForm invocation chain. In this case, method: private static Object[] prepend(Object elem, Object[] array)

Re: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems

2014-03-11 Thread Peter Levart
On 03/10/2014 10:12 PM, Brian Burkhalter wrote: This issue (https://bugs.openjdk.java.net/browse/JDK-8029770) concerns improving preference handling (java.util.prefs.Preferences) on systems other than Mac OS X and Windows, essentially Unix systems other than OS X. It would be good to obtain

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

2014-03-11 Thread Peter Levart
On 3/11/14 3:35 PM, Peter Levart wrote: Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do with hiding the call frames in stack traces that are part of LambdaForm invocation chain. In this case, method: private static Object

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

2014-03-11 Thread Peter Levart
to be thrown from the invocation of the MH... Regards, Peter Best regards, Vladimir Ivanov Regards, Peter There's not much value in it in this particular case, but I decided to reduce possible noise. Best regards, Vladimir Ivanov On 3/11/14 3:35 PM, Peter Levart wrote: Hi, Excuse my

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

2014-03-12 Thread Peter Levart
On 03/11/2014 06:07 PM, Mike Duigou wrote: You are making stringCache volatile - performance penalty on ARM PPC. It is understood that the volatile is not free. For this purpose it was believed that the performance cost was a fair trade off to avoid the heap pollution. Regardless of the

  1   2   3   4   5   6   7   8   9   10   >