From david.holmes at oracle.com Fri Nov 1 00:38:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Nov 2013 10:38:39 +1000 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272AB6C.5030300@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> Message-ID: <5272F80F.4070006@oracle.com> Hi Mandy, On 1/11/2013 5:11 AM, Mandy Chung wrote: > Updated webrev that has a new > test/lib/testlibrary/ThreadStateController.java and also change to use > AtomicInteger: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ Sorry but I don't see how this works - and that applies to the old version too! (Which I know I've looked at before so this is somewhat unsettling for me :( ). First I found it confusing to track which thread was which in the refactoring (which in itself is a good idea). Inside ThreadStateController "myThread" doesn't mean anything - that comes from the calling context - I suggest changing to refer to "this thread" or "the current thread" as appropriate. eg "Have the current thread wait until this thread is about to block" or whatever is needed. Looking at an actual test we have eg: myThread.goWaiting(); ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); First: why is checkThreadState static rather than just an instance method? So goWaiting is supposed to tell myThread to go to a "waiting" state so that the main thread can then verify that. Lets assume for arguments sake that the thread is currently RUNNABLE so it is currently looping around in run() doing the little math exercise. goWaiting does: public void goWaiting() { System.out.println("Waiting myThread to go waiting."); setState(WAITING); // wait for MyThread to get to just before wait on object. phaser.arriveAndAwaitAdvance(); } and setState does: case WAITING: case TIMED_WAITING: state = newState; synchronized (lock) { lock.notify(); } break; so as soon as we update "state" myThread is capable of changing what it is doing in run() to: case WAITING: { synchronized (lock) { // signal main thread. phaser.arrive(); System.out.println(" myThread is going to wait."); try { lock.wait(); } catch (InterruptedException e) { // ignore interrupted.incrementAndGet(); } } break; so now we have a race between the two threads to see who can grab the lock first. If it is the main thread then we issue a notify when nothing is waiting and so the subsequent wait() by myThread will potentially wait forever. At least in that case the main thread will see that it is waiting! If "myThread" wins the race it will wait after signalling the phaser and the main thread will then issue the notify allowing myThread to proceed (and do what? process the WAITING case again??). So there is no guarantee that myThread will be waiting when the main thread checks the state! Similarly for issuing the unpark in the parking cases. AFAICS the basic approach here should be: - tell myThread to go to state X - wait until myThread should be in state X - verify myThread is in state X - allow myThread to escape from state X but this code does the last step second. ??? David ----- > Mandy > > On 10/31/2013 11:22 AM, Mandy Chung wrote: >> >> On 10/31/2013 11:01 AM, Martin Buchholz wrote: >>> + iterations++; >>> >>> Using ++ on a volatile int looks racy. Using an AtomicInteger is >>> strictly more reliable. >>> >> >> Oh that's right. Will fix that. I don't really like duplicating the >> code in these 2 tests and I am going to refactor it and add the shared >> code in the testlibrary. Will send out a revised webrev. >> >> Mandy >> >>> >>> On Thu, Oct 31, 2013 at 10:53 AM, Mandy Chung >> > wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8022208 >>> >>> Webrev at: >>> >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.00/ >>> >>> >>> The retry loop in checking the thread state assumes that the >>> thread state is in RUNNABLE state which isn't always the case (it >>> could be any other state). The fix is to remove that check and >>> the thread should be a daemon thread so that the test can >>> terminate if any exception is thrown. >>> >>> jdk/test/java/lang/management/ThreadMXBean/ThreadStateTest.java >>> is a similar test that performs additional validation on the >>> ThreadMXBean API. It should also be fixed as a daemon thread I >>> take the opportunity to change it to use >>> java.util.concurrent.Phaser instead of the utility class. >>> >>> Mandy >>> >>> >> > From mandy.chung at oracle.com Fri Nov 1 03:32:06 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2013 20:32:06 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272F80F.4070006@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> Message-ID: <527320B6.50008@oracle.com> On 10/31/2013 5:38 PM, David Holmes wrote: > Hi Mandy, > > On 1/11/2013 5:11 AM, Mandy Chung wrote: >> Updated webrev that has a new >> test/lib/testlibrary/ThreadStateController.java and also change to use >> AtomicInteger: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ > > Sorry but I don't see how this works - and that applies to the old > version too! (Which I know I've looked at before so this is somewhat > unsettling for me :( ). > > First I found it confusing to track which thread was which in the > refactoring (which in itself is a good idea). Inside > ThreadStateController "myThread" doesn't mean anything - that comes > from the calling context - I suggest changing to refer to "this > thread" or "the current thread" as appropriate. eg "Have the current > thread wait until this thread is about to block" or whatever is needed. > I wasn't happy with "myThread" too and should rename it. > Looking at an actual test we have eg: > > myThread.goWaiting(); > ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); > > First: why is checkThreadState static rather than just an instance > method? > Yes it can. > So goWaiting is supposed to tell myThread to go to a "waiting" state > so that the main thread can then verify that. Lets assume for > arguments sake that the thread is currently RUNNABLE so it is > currently looping around in run() doing the little math exercise. > goWaiting does: > > public void goWaiting() { > System.out.println("Waiting myThread to go waiting."); > setState(WAITING); > // wait for MyThread to get to just before wait on object. > phaser.arriveAndAwaitAdvance(); > } > > and setState does: > > case WAITING: > case TIMED_WAITING: > state = newState; > synchronized (lock) { > lock.notify(); > } > break; > > > so as soon as we update "state" myThread is capable of changing what > it is doing in run() to: > > case WAITING: { > synchronized (lock) { > // signal main thread. > phaser.arrive(); > System.out.println(" myThread is going to wait."); > try { > lock.wait(); > } catch (InterruptedException e) { > // ignore > interrupted.incrementAndGet(); > } > } > break; > > so now we have a race between the two threads to see who can grab the > lock first. If it is the main thread then we issue a notify when > nothing is waiting and so the subsequent wait() by myThread will > potentially wait forever. At least in that case the main thread will > see that it is waiting! > > If "myThread" wins the race it will wait after signalling the phaser > and the main thread will then issue the notify allowing myThread to > proceed (and do what? process the WAITING case again??). So there is > no guarantee that myThread will be waiting when the main thread checks > the state! > > Similarly for issuing the unpark in the parking cases. > > AFAICS the basic approach here should be: > - tell myThread to go to state X > - wait until myThread should be in state X > - verify myThread is in state X > - allow myThread to escape from state X > > but this code does the last step second. > > ??? > I was looking at the intermittent failures and fix the problem I identified. What you said above is definitely potential race that I didn't have analyzed the waiting state thoroughly. It's time to revisit the whole test and see if there is a better way to code this. thanks for the review. Mandy From tristan.yan at oracle.com Fri Nov 1 05:22:28 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 31 Oct 2013 22:22:28 -0700 (PDT) Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Message-ID: Hi Everyone I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my research, it looks like the issue of fixed port was already addressed by Stuart Marks in other RMI tests which are Java based. I would like to reuse his solution, however it does not work for shell based tests. Given this, 1. Fixing the shell based test to address this bug may not be the best solution 2. My recommendation would be to convert this shell script test into Java based test and re-use the dynamic port allocation solution by Stuart Marks to address the issue 3. Also this test was written with server/client mode in shell script. In the past there have been sync issues between server/client which caused the test to fail. If we convert the shell script into Java based test, it would avoid using "sleep 10" mechanism to allow for server and client to start up and also give us better control in synchronizing server and client. Please let me know if you have any comments or suggestions. Thank you Tristan From staffan.larsen at oracle.com Fri Nov 1 09:09:04 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 01 Nov 2013 09:09:04 +0000 Subject: hg: jdk8/tl/jdk: 8027692: Remove java/lang/management/MemoryMXBean/LowMemoryTest2.sh from ProblemList.txt Message-ID: <20131101090942.EDA7B628D9@hg.openjdk.java.net> Changeset: c35f6df5bce9 Author: sla Date: 2013-11-01 10:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c35f6df5bce9 8027692: Remove java/lang/management/MemoryMXBean/LowMemoryTest2.sh from ProblemList.txt Reviewed-by: stefank, alanb ! test/ProblemList.txt From andreas.lundblad at oracle.com Fri Nov 1 09:55:55 2013 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 1 Nov 2013 10:55:55 +0100 Subject: RFR: 8006730: remove workaround tests when jtreg updated Message-ID: <20131101095555.GB3311@e6430> Hi, Please review the fix for JDK-8006730 below. Description: Several tests have been added in test/tools/doclint/{html,tidy,tool} making the dummy-tests, AAA.java obsolete. This patch removes the AAA.java "tests". Link to web review: http://cr.openjdk.java.net/~alundblad/8006730 Link to bug reports: http://bugs.openjdk.java.net/browse/JDK-8006730 -- Andreas Lundblad From Sergey.Bylokhov at oracle.com Fri Nov 1 11:18:24 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 01 Nov 2013 15:18:24 +0400 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests Message-ID: <52738E00.2070806@oracle.com> Hello. Please review the fix for jdk 8. Most of tests in the sound area, and some tests in the client, java.lang, security, jmx etc has incorrect copyright. According to the http://openjdk.java.net/faq "GPL v2 + the Classpath exception for the class libraries and those parts of the virtual machine that expose public APIs" But currently our tests mix gpl+cp and gpl or has no header at all. Tests with "/nodynamiccopyright/", with other company's copyright, or other gpl templates were not updated. Also it would be good if in the faq we explicitly mention about copyright of the tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8027696 Webrev can be found at: http://cr.openjdk.java.net/~serb/8027696/webrev.00 -- Best regards, Sergey. From sean.mullan at oracle.com Fri Nov 1 12:58:33 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 01 Nov 2013 08:58:33 -0400 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <52738E00.2070806@oracle.com> References: <52738E00.2070806@oracle.com> Message-ID: <5273A579.8080801@oracle.com> The security tests look fine. --Sean On 11/01/2013 07:18 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > Most of tests in the sound area, and some tests in the client, > java.lang, security, jmx etc has incorrect copyright. > According to the http://openjdk.java.net/faq > "GPL v2 + the Classpath exception for the class libraries and those > parts of the virtual machine that expose public APIs" > > But currently our tests mix gpl+cp and gpl or has no header at all. > Tests with "/nodynamiccopyright/", with other company's copyright, or > other gpl templates were not updated. > > Also it would be good if in the faq we explicitly mention about > copyright of the tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027696 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8027696/webrev.00 > From staffan.larsen at oracle.com Fri Nov 1 14:14:56 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 01 Nov 2013 14:14:56 +0000 Subject: hg: jdk8/tl/jdk: 8027705: com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. Message-ID: <20131101141514.DF43A628DC@hg.openjdk.java.net> Changeset: c59ccad6eb72 Author: sla Date: 2013-11-01 15:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c59ccad6eb72 8027705: com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. Reviewed-by: dcubed ! test/com/sun/jdi/JdbMethodExitTest.sh ! test/com/sun/jdi/ShellScaffold.sh From tristan.yan at oracle.com Fri Nov 1 14:17:15 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 01 Nov 2013 22:17:15 +0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java Message-ID: <5273B7EB.4070206@oracle.com> /Hi Everyone / /I am working on bug https://bugs.openjdk.java.net/browse/JDK-8025198. Root cause for this bug is //there is a race condition on below code. //there is a very small chance that when 11th thread finishes allStarted.countDown() and before check the count, 10th thread does countDown, then 2nd to 11th threads go into wait allStarted and last thread can't get the execution because the BlockingQueue is full. / / allStarted.countDown(); // // if (allStarted.getCount() < getCorePoolSize()) // / /I am going to fixed above code as below// // lock.lock();// // boolean lessThanCorePoolSize = false;// // try{// // allStarted.countDown();// // lessThanCorePoolSize = allStarted.getCount() < getCorePoolSize();// // } finally {// // lock.unlock();// // }// // if (lessThanCorePoolSize) // /// // /Please let me know if you have any comments or suggestions.// // //Tristan// / From stuart.marks at oracle.com Fri Nov 1 15:58:29 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 01 Nov 2013 08:58:29 -0700 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: References: Message-ID: <5273CFA5.4070803@oracle.com> On 10/31/13 10:22 PM, Tristan Yan wrote: > I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based > on my research, it looks like the issue of fixed port was already addressed > by Stuart Marks in other RMI tests which are Java based. I would like to > reuse his solution, however it does not work for shell based tests. (Darryl Mocek did the unique port work for the RMI tests.) Was the patch attached to your message? If so, it didn't get through. Most OpenJDK mailing lists strip off attachments before forwarding the message to the recipients. > 2. My recommendation would be to convert this shell script test into Java > based test and re-use the dynamic port allocation solution by Stuart Marks to > address the issue > > 3. Also this test was written with server/client mode in shell script. In the > past there have been sync issues between server/client which caused the test > to fail. If we convert the shell script into Java based test, it would avoid > using "sleep 10" mechanism to allow for server and client to start up and > also give us better control in synchronizing server and client. (Background for interested readers.) In general, yes, it's quite difficult to make reliable shell tests, especially for multi-process tests like this one. There is the unique port issue, and there is also the issue of how long for the client to wait until the server is ready. Error handling is also a problem, for example, if one of the JVMs gets an unexpected exception, it's easy for shell tests to mishandle this case. They might hang or erroneously report success. -- If this is a rewrite, it's probably fairly large, so you need to upload it somewhere (e.g., cr.openjdk.java.net) and then post a link to it. Thanks. s'marks From tristan.yan at oracle.com Fri Nov 1 16:18:16 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Sat, 02 Nov 2013 00:18:16 +0800 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <5273CFA5.4070803@oracle.com> References: <5273CFA5.4070803@oracle.com> Message-ID: <5273D448.2050808@oracle.com> Hi Everyone http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ Description: 1. Convert shell script test to Java program test. 2. Using random server port by reusing Darryl Mocek's work to replace fixed server port. 3. Using java Process class to start client process. 4. Also convert other shell script test runSerialBench.sh to java program test also Thank you Tristan On 01/11/2013 23:58, Stuart Marks wrote: > On 10/31/13 10:22 PM, Tristan Yan wrote: >> I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. >> Based >> on my research, it looks like the issue of fixed port was already >> addressed >> by Stuart Marks in other RMI tests which are Java based. I would like to >> reuse his solution, however it does not work for shell based tests. > > (Darryl Mocek did the unique port work for the RMI tests.) > > Was the patch attached to your message? If so, it didn't get through. > Most OpenJDK mailing lists strip off attachments before forwarding the > message to the recipients. > >> 2. My recommendation would be to convert this shell script test into >> Java >> based test and re-use the dynamic port allocation solution by Stuart >> Marks to >> address the issue >> >> 3. Also this test was written with server/client mode in shell >> script. In the >> past there have been sync issues between server/client which caused >> the test >> to fail. If we convert the shell script into Java based test, it >> would avoid >> using "sleep 10" mechanism to allow for server and client to start up >> and >> also give us better control in synchronizing server and client. > > (Background for interested readers.) In general, yes, it's quite > difficult to make reliable shell tests, especially for multi-process > tests like this one. There is the unique port issue, and there is also > the issue of how long for the client to wait until the server is > ready. Error handling is also a problem, for example, if one of the > JVMs gets an unexpected exception, it's easy for shell tests to > mishandle this case. They might hang or erroneously report success. > > -- > > If this is a rewrite, it's probably fairly large, so you need to > upload it somewhere (e.g., cr.openjdk.java.net) and then post a link > to it. > > Thanks. > > s'marks From paul.sandoz at oracle.com Fri Nov 1 16:34:58 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 Nov 2013 17:34:58 +0100 Subject: RFR 8027316 Distinct operation on an unordered stream should not be a barrier In-Reply-To: <61F4AD8F-DADE-4375-AA78-B3E8AF6847F7@oracle.com> References: <61F4AD8F-DADE-4375-AA78-B3E8AF6847F7@oracle.com> Message-ID: <51701781-8A5C-4A74-94CB-E5364A797D32@oracle.com> On Oct 30, 2013, at 5:54 PM, Henry Jen wrote: > Looks good to me. > > In the test, > >> Integer one = Stream.iterate(1, i -> i + 1).unordered().parallel().distinct().findAny().get(); >> assertEquals(one.intValue(), 1); > > The implementation is probably make sure this will return 1, but is that what we spec to do? I sort of think it can have various values depends on how many working threads and their scheduling. > Doh! you are correct, sorry, i made a silly mistake and had this in my head "Stream.iterate(1, i -> i + 1).parallel().distinct().findFirst().get()" when i responded. This test is failing in some cases exactly for the reasons you give. Paul. From paul.sandoz at oracle.com Fri Nov 1 17:57:03 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 Nov 2013 18:57:03 +0100 Subject: RFR 8027712 DistinctOpTest fails for unordered test Message-ID: Hi, This is a "eating humble pie and should of correctly listened to Henry in review" kind of email :-) The changes to DistinctOpTest recently committed result in a test failure, since one of the tests is incorrectly asserting on a particular element, which is non-determinisitic process [*]. See below for a patch that fixes the test. Paul. [*] Somewhat interesting how this can arise given the sequential nature of the source and the way it is split. Intuitively one would expect that the first F/J leaf task is more likely to complete before the second, but we alternate forking of left/right tasks when splitting. The first leaf task gets forked and the next leaf task gets computed directly on the same thread that forked the first leaf task. Thus setting the common pool parallelism to 0 (or running on a single core machine) will consistently make the test fail, and this probably explains why it was caught so soon. hg qdiff diff -r 18c111c17231 test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java --- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java Thu Oct 31 11:59:04 2013 +0100 +++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java Fri Nov 01 18:42:08 2013 +0100 @@ -54,10 +54,14 @@ // These tests should short-circuit, otherwise will fail with a time-out // or an OOME - Integer one = Stream.iterate(1, i -> i + 1).unordered().parallel().distinct().findAny().get(); - assertEquals(one.intValue(), 1); + // Note that since the streams are unordered and any element is requested + // (a non-deterministic process) the only assertion that can be made is + // that an element should be found - Optional oi = ThreadLocalRandom.current().ints().boxed().parallel().distinct().findAny(); + Optional oi = Stream.iterate(1, i -> i + 1).unordered().parallel().distinct().findAny(); + assertTrue(oi.isPresent()); + + oi = ThreadLocalRandom.current().ints().boxed().parallel().distinct().findAny(); assertTrue(oi.isPresent()); } From mandy.chung at oracle.com Fri Nov 1 18:15:39 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 01 Nov 2013 11:15:39 -0700 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass Message-ID: <5273EFCB.7010200@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/ This fixes the finalization implementation to invoke the finalize method via shared secret so that it will call the same method as the bytecode invocation. The current implementation uses JNI_GetMethodID to find the finalize method of a given instance. JNI_GetMethodID returns the private finalize method which gets invoked during finalization (which is different than the method looked up via invokevirtual). If there is a static method matching the name and descriptor, it will throw NoSuchMethodError even if the base class has a matching instance method. JDK-8027270 is filed for this JNI_GetMethodID issue. This change replaces the JNI call to the finalize method with the shared secret as Jeroen suggests [1]. This will resolve this bug independent of JDK-8027270 and also avoid the overhead of the JNI calls. The behavioral change with this fix should rarely impact any existing application. It would only impact code that defines a finalize method in a base class and also a private finalize method in a subclass. The only way to have a private finalize method is to write to the bytecode directly. thanks Mandy P.S. I would love to use Martin's beloved GcFinalization utility that we can extend our testlibrary in the future. The new regression test is simple enough that a counter would do its work. [1] http://weblog.ikvm.net/PermaLink.aspx?guid=87432f77-7e58-4f37-9f6d-d5bac453c7d6 [2] https://bugs.openjdk.java.net/browse/JDK-8027351 From henry.jen at oracle.com Fri Nov 1 11:20:50 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 01 Nov 2013 04:20:50 -0700 Subject: RFR 8027712 DistinctOpTest fails for unordered test In-Reply-To: References: Message-ID: <52738E92.2070504@oracle.com> Change looks good to me(not a reviewer). Cheers, Henry On 11/01/2013 10:57 AM, Paul Sandoz wrote: > Hi, > > This is a "eating humble pie and should of correctly listened to Henry in review" kind of email :-) > > The changes to DistinctOpTest recently committed result in a test failure, since one of the tests is incorrectly asserting on a particular element, which is non-determinisitic process [*]. > > See below for a patch that fixes the test. > > Paul. > > [*] Somewhat interesting how this can arise given the sequential nature of the source and the way it is split. Intuitively one would expect that the first F/J leaf task is more likely to complete before the second, but we alternate forking of left/right tasks when splitting. The first leaf task gets forked and the next leaf task gets computed directly on the same thread that forked the first leaf task. Thus setting the common pool parallelism to 0 (or running on a single core machine) will consistently make the test fail, and this probably explains why it was caught so soon. > > hg qdiff > diff -r 18c111c17231 test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java > --- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java Thu Oct 31 11:59:04 2013 +0100 > +++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java Fri Nov 01 18:42:08 2013 +0100 > @@ -54,10 +54,14 @@ > // These tests should short-circuit, otherwise will fail with a time-out > // or an OOME > > - Integer one = Stream.iterate(1, i -> i + 1).unordered().parallel().distinct().findAny().get(); > - assertEquals(one.intValue(), 1); > + // Note that since the streams are unordered and any element is requested > + // (a non-deterministic process) the only assertion that can be made is > + // that an element should be found > > - Optional oi = ThreadLocalRandom.current().ints().boxed().parallel().distinct().findAny(); > + Optional oi = Stream.iterate(1, i -> i + 1).unordered().parallel().distinct().findAny(); > + assertTrue(oi.isPresent()); > + > + oi = ThreadLocalRandom.current().ints().boxed().parallel().distinct().findAny(); > assertTrue(oi.isPresent()); > } > > From joe.darcy at oracle.com Fri Nov 1 18:31:15 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 01 Nov 2013 11:31:15 -0700 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: References: Message-ID: <5273F373.5010106@oracle.com> Hi Tristan, Without commenting on the specifics of this test, in my estimation we should strongly favor rewriting shell tests as Java programs, as has already largely been done in the langtools area: "Shelling Tests" https://blogs.oracle.com/jjg/entry/shelling_tests -Joe On 10/31/2013 10:22 PM, Tristan Yan wrote: > Hi Everyone > > > > I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my research, it looks like the issue of fixed port was already addressed by Stuart Marks in other RMI tests which are Java based. I would like to reuse his solution, however it does not work for shell based tests. Given this, > > > > 1. Fixing the shell based test to address this bug may not be the best solution > > 2. My recommendation would be to convert this shell script test into Java based test and re-use the dynamic port allocation solution by Stuart Marks to address the issue > > 3. Also this test was written with server/client mode in shell script. In the past there have been sync issues between server/client which caused the test to fail. If we convert the shell script into Java based test, it would avoid using "sleep 10" mechanism to allow for server and client to start up and also give us better control in synchronizing server and client. > > > > Please let me know if you have any comments or suggestions. > > > > Thank you > > > > Tristan > > From vicente.romero at oracle.com Fri Nov 1 19:09:26 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 01 Nov 2013 19:09:26 +0000 Subject: hg: jdk8/tl/langtools: 8027660: javac crash while creating LVT entry for a local variable defined in an inner block Message-ID: <20131101190930.08985628E7@hg.openjdk.java.net> Changeset: cc80c03c41e4 Author: vromero Date: 2013-11-01 19:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc80c03c41e4 8027660: javac crash while creating LVT entry for a local variable defined in an inner block Reviewed-by: jjg Contributed-by: vicente.romero at oracle.com, jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! test/tools/javac/flow/LVTHarness.java + test/tools/javac/flow/tests/TestCaseLocalInInnerBlock.java From martinrb at google.com Fri Nov 1 19:59:44 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 1 Nov 2013 12:59:44 -0700 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <5273B7EB.4070206@oracle.com> References: <5273B7EB.4070206@oracle.com> Message-ID: Hi Tristan, I'm having unexpected trouble discovering the author's intent in some of this code... :-( It would be useful if you posted your changes in the form of a diff (diff -u) or a webrev. What do you mean "the BlockingQueue is full"? Isn't it unbounded? (Tristan is also my son's name!) On Fri, Nov 1, 2013 at 7:17 AM, Tristan Yan wrote: > /Hi Everyone > > / > > /I am working on bug https://bugs.openjdk.java.net/browse/JDK-8025198. > Root cause for this bug is //there is a race condition on below code. > //there is a very small chance that when 11th thread finishes > allStarted.countDown() and before check the count, 10th thread does > countDown, then 2nd to 11th threads go into wait allStarted and last thread > can't get the execution because the BlockingQueue is full. / > > / allStarted.countDown(); // > // if (allStarted.getCount() < getCorePoolSize()) // > / > > /I am going to fixed above code as below// > // lock.lock();// > // boolean lessThanCorePoolSize = false;// > // try{// > // allStarted.countDown();// > // lessThanCorePoolSize = allStarted.getCount() < > getCorePoolSize();// > // } finally {// > // lock.unlock();// > // }// > // if (lessThanCorePoolSize) // > /// > > // > > /Please let me know if you have any comments or suggestions.// > // > //Tristan// > / > From martinrb at google.com Fri Nov 1 20:01:53 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 1 Nov 2013 13:01:53 -0700 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: <5273B7EB.4070206@oracle.com> Message-ID: Including a jstack output extract might be useful for diagnosis. I have never seen this test fail. Is there a hint that might allow me to reproduce it? From mark.reinhold at oracle.com Fri Nov 1 20:37:42 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 01 Nov 2013 13:37:42 -0700 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5273EFCB.7010200@oracle.com> References: <5273EFCB.7010200@oracle.com> Message-ID: <20131101133742.799770@eggemoggin.niobe.net> 2013/11/1 4:15 -0700, mandy.chung at 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 JavaLangAccess object every single time. Is it worth caching that earlier, maybe when the finalize thread starts, since it will never change? - Mark From mandy.chung at oracle.com Fri Nov 1 21:11:20 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 01 Nov 2013 14:11:20 -0700 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <20131101133742.799770@eggemoggin.niobe.net> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> Message-ID: <527418F8.5040507@oracle.com> On 11/1/13 1:37 PM, mark.reinhold at oracle.com wrote: > 2013/11/1 4:15 -0700, mandy.chung at 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 > JavaLangAccess object every single time. Is it worth caching that > earlier, maybe when the finalize thread starts, since it will never > change? I was expecting that would get optimized during runtime and it's a simple getter method. It's a good suggestion to cache it at the finalize thread start time and here is the revised webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ Thanks for the review. Mandy From jan.lahoda at oracle.com Fri Nov 1 20:48:45 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 01 Nov 2013 20:48:45 +0000 Subject: hg: jdk8/tl/langtools: 8027310: Annotation Processor crashes with NPE Message-ID: <20131101204857.4FF35628F2@hg.openjdk.java.net> Changeset: 8b4e1421a9b7 Author: jlahoda Date: 2013-11-01 21:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b4e1421a9b7 8027310: Annotation Processor crashes with NPE Summary: JCAnnotation.attribute is null when annotation type is unavailable Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/processing/errors/CrashOnNonExistingAnnotation/Processor.java + test/tools/javac/processing/errors/CrashOnNonExistingAnnotation/Source.java From dan.xu at oracle.com Fri Nov 1 21:40:15 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 01 Nov 2013 21:40:15 +0000 Subject: hg: jdk8/tl/jdk: 8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again Message-ID: <20131101214044.2D64662907@hg.openjdk.java.net> Changeset: 6a6faa00acc4 Author: dxu Date: 2013-11-01 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a6faa00acc4 8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again Reviewed-by: wetmore ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java From dan.xu at oracle.com Fri Nov 1 22:20:59 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 01 Nov 2013 15:20:59 -0700 Subject: RFR: JDK-8027612, , java/io/File/MaxPathLength.java fails intermittently in the clean-up stage Message-ID: <5274294B.3010101@oracle.com> Hi All, Please review a simple test fix. In the clean-up stage of MaxPathLength.java on windows platform, the delete operation may be interfered by anti-virus software or some Windows services, which will lead to the failure of recursive directory delete operations. In the change, the test will try its best to clean up testing folders. If it fails, it will just ignore that, continue the testing process, and let jtreg to handle the clean-up later. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8027612 Webrev: http://cr.openjdk.java.net/~dxu/8027612/webrev/ -Dan From chris.hegarty at oracle.com Fri Nov 1 22:55:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 1 Nov 2013 22:55:35 +0000 Subject: RFR: JDK-8027612, , java/io/File/MaxPathLength.java fails intermittently in the clean-up stage In-Reply-To: <5274294B.3010101@oracle.com> References: <5274294B.3010101@oracle.com> Message-ID: The changes look ok to me Dan. I know I have used a similar technique elsewhere to handle this situation. A minor point, and others may have a different opinion but, I don't think the @bug tag needs to list this bug number, since it is not testing a product bug. It is a testcase bug only. But it's not even worth discussing. -Chris > On 1 Nov 2013, at 22:20, Dan Xu wrote: > > Hi All, > > Please review a simple test fix. In the clean-up stage of MaxPathLength.java on windows platform, the delete operation may be interfered by anti-virus software or some Windows services, which will lead to the failure of recursive directory delete operations. In the change, the test will try its best to clean up testing folders. If it fails, it will just ignore that, continue the testing process, and let jtreg to handle the clean-up later. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027612 > Webrev: http://cr.openjdk.java.net/~dxu/8027612/webrev/ > > -Dan From dan.xu at oracle.com Fri Nov 1 23:38:55 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 01 Nov 2013 16:38:55 -0700 Subject: RFR: JDK-8027612, , java/io/File/MaxPathLength.java fails intermittently in the clean-up stage In-Reply-To: References: <5274294B.3010101@oracle.com> Message-ID: <52743B8F.2090203@oracle.com> Thanks for your review, Chris. I have removed the bug number in the latest one, http://cr.openjdk.java.net/~dxu/8027612/webrev.01/ -Dan On 11/01/2013 03:55 PM, Chris Hegarty wrote: > The changes look ok to me Dan. I know I have used a similar technique elsewhere to handle this situation. > > A minor point, and others may have a different opinion but, I don't think the @bug tag needs to list this bug number, since it is not testing a product bug. It is a testcase bug only. But it's not even worth discussing. > > -Chris > >> On 1 Nov 2013, at 22:20, Dan Xu wrote: >> >> Hi All, >> >> Please review a simple test fix. In the clean-up stage of MaxPathLength.java on windows platform, the delete operation may be interfered by anti-virus software or some Windows services, which will lead to the failure of recursive directory delete operations. In the change, the test will try its best to clean up testing folders. If it fails, it will just ignore that, continue the testing process, and let jtreg to handle the clean-up later. Thanks! >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8027612 >> Webrev: http://cr.openjdk.java.net/~dxu/8027612/webrev/ >> >> -Dan From brian.burkhalter at oracle.com Sat Nov 2 00:07:45 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 1 Nov 2013 17:07:45 -0700 Subject: [test-only] JDK 8 RFR 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size Message-ID: <6A8FBE00-5F4E-4E87-B4EB-637CCDF4873D@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8027625 Patch: --- a/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01 14:40:03 2013 -0700 +++ b/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01 17:03:04 2013 -0700 @@ -25,6 +25,7 @@ * @test * @bug 6371401 * @summary Tests of shiftLeft and shiftRight on Integer.MIN_VALUE + * @run main/othervm -Xmx512m ExtremeShiftingTests * @author Joseph D. Darcy */ import java.math.BigInteger; Thanks, Brian From dan.xu at oracle.com Sat Nov 2 00:27:51 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 01 Nov 2013 17:27:51 -0700 Subject: [test-only] JDK 8 RFR 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size In-Reply-To: <6A8FBE00-5F4E-4E87-B4EB-637CCDF4873D@oracle.com> References: <6A8FBE00-5F4E-4E87-B4EB-637CCDF4873D@oracle.com> Message-ID: <52744707.6070206@oracle.com> Looks good to me. -Dan On 11/01/2013 05:07 PM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: > > https://bugs.openjdk.java.net/browse/JDK-8027625 > > Patch: > > --- a/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01 14:40:03 2013 -0700 > +++ b/test/java/math/BigInteger/ExtremeShiftingTests.java Fri Nov 01 17:03:04 2013 -0700 > @@ -25,6 +25,7 @@ > * @test > * @bug 6371401 > * @summary Tests of shiftLeft and shiftRight on Integer.MIN_VALUE > + * @run main/othervm -Xmx512m ExtremeShiftingTests > * @author Joseph D. Darcy > */ > import java.math.BigInteger; > > Thanks, > > Brian From tristan.yan at oracle.com Sat Nov 2 01:48:59 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Sat, 02 Nov 2013 09:48:59 +0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: <5273B7EB.4070206@oracle.com> Message-ID: <52745A0B.8080600@oracle.com> This only happened when I tried a 1000 times loop run, see the jstack out put below: Also by using jmap/jhat, below values help me find the reason flakes.size() = 25 allStarted.state = 1 beforeExecuteCount.count = 1 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed mode): "Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007faf1d808000 nid=0x390b waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 nid=0x5d0b waiting on condition [0x000000019b530000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 nid=0x5507 waiting on condition [0x000000019ae1b000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 nid=0x6307 waiting on condition [0x000000019b227000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 nid=0x6107 waiting on condition [0x000000019b42d000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 nid=0x500b waiting on condition [0x000000019ad18000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 nid=0x5f03 waiting on condition [0x000000019b32a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 nid=0x540b waiting on condition [0x000000019ab12000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 nid=0x5107 waiting on condition [0x000000019af1e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 waiting on condition [0x000000019ac15000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 waiting on condition [0x000000019b124000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e9610> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) "Service Thread" #8 daemon prio=9 os_prio=31 tid=0x00007faf1c837000 nid=0x4b03 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007faf1c816000 nid=0x4903 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007faf1c809800 nid=0x4703 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007faf1c818000 nid=0x4503 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007faf1c078800 nid=0x4303 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 nid=0x2d03 in Object.wait() [0x00000001999be000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) - locked <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007faf1c810800 nid=0x2b03 in Object.wait() [0x00000001998bb000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x0000000168285c88> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 waiting on condition [0x000000010386e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001683e95e0> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at ThrowingTasks.realMain(ThrowingTasks.java:207) at ThrowingTasks.main(ThrowingTasks.java:267) "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 nid=0x2103 runnable "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 nid=0x2303 runnable "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 nid=0x2503 runnable "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 nid=0x2703 runnable "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 nid=0x4d03 waiting on condition JNI global references: 7 On 02/11/2013 04:01, Martin Buchholz wrote: > > > Including a jstack output extract might be useful for diagnosis. > > I have never seen this test fail. Is there a hint that might allow me > to reproduce it? From jeroen at sumatra.nl Sat Nov 2 08:38:57 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 2 Nov 2013 08:38:57 +0000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5273EFCB.7010200@oracle.com> References: <5273EFCB.7010200@oracle.com> Message-ID: Hi Mandy, Thank you. Patch looks good. Regards, Jeroen > -----Original Message----- > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- > bounces at openjdk.java.net] On Behalf Of Mandy Chung > Sent: Friday, November 1, 2013 19:16 > To: core-libs-dev at openjdk.java.net > Subject: JDK-8027351: (ref) Base's class finalize method not invoked if > a private finalize method exists in its subclass > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.00/ > > This fixes the finalization implementation to invoke the finalize method > via shared secret so that it will call the same method as the bytecode > invocation. > > The current implementation uses JNI_GetMethodID to find the finalize > method of a given instance. JNI_GetMethodID returns the private finalize > method which gets invoked during finalization (which is different than > the method looked up via invokevirtual). If there is a static method > matching the name and descriptor, it will throw NoSuchMethodError even > if the base class has a matching instance method. JDK-8027270 is filed > for this JNI_GetMethodID issue. > > This change replaces the JNI call to the finalize method with the shared > secret as Jeroen suggests [1]. This will resolve this bug independent > of JDK-8027270 and also avoid the overhead of the JNI calls. > > The behavioral change with this fix should rarely impact any existing > application. It would only impact code that defines a finalize method > in a base class and also a private finalize method in a subclass. The > only way to have a private finalize method is to write to the bytecode > directly. > > thanks > Mandy > P.S. I would love to use Martin's beloved GcFinalization utility that we > can extend our testlibrary in the future. The new regression test is > simple enough that a counter would do its work. > > [1] > http://weblog.ikvm.net/PermaLink.aspx?guid=87432f77-7e58-4f37-9f6d- > d5bac453c7d6 > [2] https://bugs.openjdk.java.net/browse/JDK-8027351 From jeroen at sumatra.nl Sat Nov 2 08:43:32 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Sat, 2 Nov 2013 08:43:32 +0000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <527418F8.5040507@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> Message-ID: <5fab148d9b3f47889cac02669758de6b@mane.sumatrasoftware.com> Hi Mandy (and Mark), The getter can be optimized away, the static field can't, so this is probably a tiny bit more expensive. Regards, Jeroen > -----Original Message----- > From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev- > bounces at openjdk.java.net] On Behalf Of Mandy Chung > Sent: Friday, November 1, 2013 22:11 > To: mark.reinhold at oracle.com > Cc: core-libs-dev at openjdk.java.net > Subject: Re: JDK-8027351: (ref) Base's class finalize method not invoked > if a private finalize method exists in its subclass > > On 11/1/13 1:37 PM, mark.reinhold at oracle.com wrote: > > 2013/11/1 4:15 -0700, mandy.chung at 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 > > JavaLangAccess object every single time. Is it worth caching that > > earlier, maybe when the finalize thread starts, since it will never > > change? > > I was expecting that would get optimized during runtime and it's a > simple getter method. It's a good suggestion to cache it at the finalize > thread start time and here is the revised webrev: > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ > > Thanks for the review. > Mandy From Alan.Bateman at oracle.com Sat Nov 2 09:03:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 02 Nov 2013 09:03:04 +0000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <527418F8.5040507@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> Message-ID: <5274BFC8.9090707@oracle.com> On 01/11/2013 21:11, Mandy Chung wrote: > > I was expecting that would get optimized during runtime and it's a > simple getter method. It's a good suggestion to cache it at the > finalize thread start time and here is the revised webrev: > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ This looks good. A small typo in ensureAccessAvailable, "ntil" -> "until". Also the continue isn't needed. On the finalizer thread now waiting for the system classes to be initialized then this is probably a good thing (although I can imagine subtle changes for corner cases, say where an agent is playing with fire and instrumenting classes early in the startup). -Alan. From Alan.Bateman at oracle.com Sat Nov 2 09:04:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 02 Nov 2013 09:04:02 +0000 Subject: [test-only] JDK 8 RFR 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size In-Reply-To: <6A8FBE00-5F4E-4E87-B4EB-637CCDF4873D@oracle.com> References: <6A8FBE00-5F4E-4E87-B4EB-637CCDF4873D@oracle.com> Message-ID: <5274C002.7040800@oracle.com> On 02/11/2013 00:07, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: > > https://bugs.openjdk.java.net/browse/JDK-8027625 > > Patch: Thanks for that, this test has been failing with OOME in some environments since the recent change. -Alan. From peter.levart at gmail.com Sat Nov 2 10:41:45 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 02 Nov 2013 11:41:45 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <527418F8.5040507@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> Message-ID: <5274D6E9.30707@gmail.com> On 11/01/2013 10:11 PM, Mandy Chung wrote: > On 11/1/13 1:37 PM, mark.reinhold at oracle.com wrote: >> 2013/11/1 4:15 -0700, mandy.chung at 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 >> JavaLangAccess object every single time. Is it worth caching that >> earlier, maybe when the finalize thread starts, since it will never >> change? > > I was expecting that would get optimized during runtime and it's a > simple getter method. It's a good suggestion to cache it at the > finalize thread start time and here is the revised webrev: > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ > > Thanks for the review. > Mandy > Hi Mandy, FWIW, I don't know if you gain anything by caching static field in a static field, performance wise.It looks nicer at use site though. If performance was really extremely important in this use case (which I think is not) then "jla" should be a local variable inside FinalizerThread.run() (and possibly in the anonymous Runnables too) and passed as an argument to Finalizer.runFinalizer(). Looking at code once more, I see a possible data race. Is it remotely possible, that either Finalizer.runFinalization() or Finalizer.runAllFinalizers() is executed and new secondary finalizer thread spawned and executed before FinalizerThread manages to call ensureAccessAvailable(), therefore executing the Finalizer.runFinalizer() methods before static Finalizer.jla is initialized? Even though jla field was initialized, what guarantees it's value being visible in spawned secondary finalizer threads? FinalizerThread is started in Finalizer's static initializer, yes, but ensureAccessAvailable() is called by FinalizerThread after it starts... Considering all this, it might be safer to just ready the SharedSecrets field every time it's needed. Regards, Peter From Alan.Bateman at oracle.com Sat Nov 2 11:37:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 02 Nov 2013 11:37:35 +0000 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <52738E00.2070806@oracle.com> References: <52738E00.2070806@oracle.com> Message-ID: <5274E3FF.3070807@oracle.com> On 01/11/2013 11:18, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 8. > Most of tests in the sound area, and some tests in the client, > java.lang, security, jmx etc has incorrect copyright. > According to the http://openjdk.java.net/faq > "GPL v2 + the Classpath exception for the class libraries and those > parts of the virtual machine that expose public APIs" > > But currently our tests mix gpl+cp and gpl or has no header at all. > Tests with "/nodynamiccopyright/", with other company's copyright, or > other gpl templates were not updated. > > Also it would be good if in the faq we explicitly mention about > copyright of the tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027696 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8027696/webrev.00 > Thanks for doing this. I sampled a few of the files in the webrev and the changes mostly look okay. The only thing is that I'm not sure about is the dates that you've put on tests that were missing a header. For example, test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java was added in 2013 but the header proposed in the webrev has 2012. Does your script to fix up these headers look at the hg log to get the date range? I see you've changed jdk/test/Makefile to have the GPL header. I don't know what the right header is for that (as the rest of the Makefiles have the GPL + Classpath exception). One other question is whether this is a one-off effort by yourself or whether this is part of an effort to keep us in check on a continuous basis. Periodically David Katleman brings up malformed headers on jdk8-dev. I assume these are caught by something that checks the headers on a weekly or continuous basis. Maybe there is an opportunity to combine efforts and also have these scripts run on a continuous basis on jdk8/tl, jdk8/awt and the other forests that collect changes. -Alan. From Sergey.Bylokhov at oracle.com Sat Nov 2 15:53:25 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 02 Nov 2013 19:53:25 +0400 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <5274E3FF.3070807@oracle.com> References: <52738E00.2070806@oracle.com> <5274E3FF.3070807@oracle.com> Message-ID: <52751FF5.5070503@oracle.com> On 02.11.2013 15:37, Alan Bateman wrote: > On 01/11/2013 11:18, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 8. >> Most of tests in the sound area, and some tests in the client, >> java.lang, security, jmx etc has incorrect copyright. >> According to the http://openjdk.java.net/faq >> "GPL v2 + the Classpath exception for the class libraries and those >> parts of the virtual machine that expose public APIs" >> >> But currently our tests mix gpl+cp and gpl or has no header at all. >> Tests with "/nodynamiccopyright/", with other company's copyright, or >> other gpl templates were not updated. >> >> Also it would be good if in the faq we explicitly mention about >> copyright of the tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8027696 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8027696/webrev.00 >> > Thanks for doing this. I sampled a few of the files in the webrev and > the changes mostly look okay. > > The only thing is that I'm not sure about is the dates that you've put > on tests that were missing a header. For example, > test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java > was added in 2013 but the header proposed in the webrev has 2012. Does > your script to fix up these headers look at the hg log to get the date > range? After the absent headers were added, I manually verify them and looks like in this case my eye was hackneyed and I change it to 2012. I'll additionally recheck them again. > > I see you've changed jdk/test/Makefile to have the GPL header. I don't > know what the right header is for that (as the rest of the Makefiles > have the GPL + Classpath exception). I would be good to have one rule for all files under tests directory. > > One other question is whether this is a one-off effort by yourself or > whether this is part of an effort to keep us in check on a continuous > basis. Periodically David Katleman brings up malformed headers on > jdk8-dev. I assume these are caught by something that checks the > headers on a weekly or continuous basis. Maybe there is an opportunity > to combine efforts and also have these scripts run on a continuous > basis on jdk8/tl, jdk8/awt and the other forests that collect changes. It is one time effort. My main goal was to update tests in sound and client area. > > -Alan. -- Best regards, Sergey. From peter.levart at gmail.com Sat Nov 2 21:58:08 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 02 Nov 2013 22:58:08 +0100 Subject: Assorted annotation optimizations Message-ID: <52757570.5010503@gmail.com> 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: AnnotationInvocationHandler.invoke(): Use reference comparison among interned strings instead of equals() to dispatch the invocation and use Method.getParameterCount() instead of Method.getParameterTypes() to avoid creating Class[] array for each invocation. AnnotationInvocationHandler.toStringImpl(): Use StringBuilder instead of StringBuffer AnnotationInvocationHandler.equalsImpl(): Don't call asOneOfUs(o) in a loop for each member and restructure the code to have basically two independent implementations: the one based on memberValues map if the other annotation is "OneOfUs" (the common case) and the one based on AnnotationType.members() map of member methods. Caching of member methods privately in each AnnotationInvocationHandler instance is not needed - use the AnnotationType.members() map instead - this improves annotation instance footprint too. AnnotationInvocationHandler.getMemberValue(): new static package-private method used in AnnotationSupport for fast retrieval of shared value array in container annotations. AnnotationSupport.getDirectlyAndIndirectlyPresent(): minimize number of garbage objects and array copies. This method delegates to getSharedIndirectlyPresent() which might return a shared array which is only cloned if needed. AnnotationSupport.getSharedIndirectlyPresent(): private method instead of getIndirectlyPresent() that may return a shared array. AnnotationSupport.getSharedValueArray(): private method that may return a shared array. This method is based on new AnnotationInvocationHandler.getMemberValue() method and now also incorporates a call to checkTypes(). AnnotationSupport.getValueArray(): now based on getSharedValueArray() and cloneArray() AnnotationSupport.cloneArray(): new private method which clones the array AnnotationSupport.newArray(): new private constructor for annotation arrays (to localize @SuppressWarnings("unchecked")) AnnotationType constructor: member Methods are now all made setAccessible(true) in advance so that "value" member method for container annotations doesn't need to be made setAccessible(true) each time a container of a particular type is flattened. All in all these changes make common operations such as retrieving the annotation member values and obtaining repeatable annotations faster and with less produced garbage objects. Here are the results of some micro-benchmarks: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationOptimizations/test/perf_results.txt These results are obtained with the following test: http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationOptimizations/test/AnnotationDispatchPerfTest.java http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationOptimizations/test/si/pele/microbench/TestRunner.java In short: - Invoking Annotation.annotationType() is 6x faster - Retrieving a scalar member value is 2x faster - Annotation.equals for annotation with 3 int members is 2.5x faster - Class.getDeclaredAnnotationsByType for direct-only case is 2x faster - Class.getDeclaredAnnotationsByType for in-direct-only case is 2.2x faster - Class.getDeclaredAnnotationsByType for mixed case is 1.7x faster So what do you think? Regards, Peter From martinrb at google.com Sun Nov 3 04:46:35 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 2 Nov 2013 21:46:35 -0700 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <52745A0B.8080600@oracle.com> References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> Message-ID: I think the author of this test was sleep-deprived by baby Tristan back in 2007.[image: Inline image 1] I tried and failed to find a single synchronizer that properly does what we are trying to do with allStarted here. Too bad CountDownLatch.countDown doesn't return the count. Best to introduce another synchronizer. I propose this fix: diff --git a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java @@ -136,6 +136,7 @@ } static final CountDownLatch allStarted = new CountDownLatch(flakes.size()); + static final AtomicInteger taskSerial = new AtomicInteger(0); static final CountDownLatch allContinue = new CountDownLatch(1); static class PermissiveSecurityManger extends SecurityManager { @@ -164,7 +165,8 @@ } @Override protected void beforeExecute(Thread t, Runnable r) { allStarted.countDown(); - if (allStarted.getCount() < getCorePoolSize()) + // Get last core pool cohort to start in unison + if (flakes.size() - taskSerial.incrementAndGet() < getCorePoolSize()) try { allContinue.await(); } catch (InterruptedException x) { unexpected(x); } beforeExecuteCount.getAndIncrement(); On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan wrote: > This only happened when I tried a 1000 times loop run, see the jstack > out put below: > Also by using jmap/jhat, below values help me find the reason > flakes.size() = 25 > allStarted.state = 1 > beforeExecuteCount.count = 1 > > Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed mode): > > "Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007faf1d808000 > nid=0x390b waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 nid=0x5d0b > waiting on condition [0x000000019b530000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 nid=0x5507 > waiting on condition [0x000000019ae1b000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 nid=0x6307 > waiting on condition [0x000000019b227000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 nid=0x6107 > waiting on condition [0x000000019b42d000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 nid=0x500b > waiting on condition [0x000000019ad18000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 nid=0x5f03 > waiting on condition [0x000000019b32a000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 nid=0x540b > waiting on condition [0x000000019ab12000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 nid=0x5107 > waiting on condition [0x000000019af1e000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 waiting > on condition [0x000000019ac15000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 waiting > on condition [0x000000019b124000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Service Thread" #8 daemon prio=9 os_prio=31 tid=0x00007faf1c837000 > nid=0x4b03 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007faf1c816000 > nid=0x4903 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007faf1c809800 > nid=0x4703 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007faf1c818000 > nid=0x4503 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007faf1c078800 > nid=0x4303 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 nid=0x2d03 > in Object.wait() [0x00000001999be000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) > - locked <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) > > "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007faf1c810800 > nid=0x2b03 in Object.wait() [0x00000001998bb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x0000000168285c88> (a java.lang.ref.Reference$Lock) > at java.lang.Object.wait(Object.java:502) > at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) > - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) > > "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 waiting on > condition [0x000000010386e000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e95e0> (a > java.util.concurrent.CountDownLatch$Sync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks.realMain(ThrowingTasks.java:207) > at ThrowingTasks.main(ThrowingTasks.java:267) > > "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable > > "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 > nid=0x2103 runnable > > "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 > nid=0x2303 runnable > > "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 > nid=0x2503 runnable > > "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 > nid=0x2703 runnable > > "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 nid=0x4d03 > waiting on condition > > JNI global references: 7 > > > On 02/11/2013 04:01, Martin Buchholz wrote: > > > > Including a jstack output extract might be useful for diagnosis. > > I have never seen this test fail. Is there a hint that might allow me > to reproduce it? > > > From john.r.rose at oracle.com Sun Nov 3 08:08:40 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 03 Nov 2013 08:08:40 +0000 Subject: hg: jdk8/tl/jdk: 8024635: Caching MethodType's descriptor string improves lambda linkage performance Message-ID: <20131103080921.8CA856294D@hg.openjdk.java.net> Changeset: adcc01f5bc93 Author: jrose Date: 2013-11-02 20:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adcc01f5bc93 8024635: Caching MethodType's descriptor string improves lambda linkage performance Summary: Better interpreted and compiled performance of operations in MethodType important to LambdaMetafactory. Reviewed-by: jrose, twisti, mchung Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java From tristan.yan at oracle.com Mon Nov 4 00:49:19 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 04 Nov 2013 08:49:19 +0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> Message-ID: <5276EF0F.8090107@oracle.com> Thank you Martin I had code change. I took the similar way as you do here. Please review the code change for JDK-8025198. Description: Race condition exists in the test ThrowingTasks.java. We should sync CountDownLatch.countDown and CountDownLatch.getCount. http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.01/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java.sdiff.html Thank you Tristan On 11/03/2013 12:46 PM, Martin Buchholz wrote: > I think the author of this test was sleep-deprived by baby Tristan > back in 2007.Inline image 1 > > I tried and failed to find a single synchronizer that properly does > what we are trying to do with allStarted here. Too bad > CountDownLatch.countDown doesn't return the count. Best to introduce > another synchronizer. I propose this fix: > > diff --git > a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > @@ -136,6 +136,7 @@ > } > static final CountDownLatch allStarted = new > CountDownLatch(flakes.size()); > + static final AtomicInteger taskSerial = new AtomicInteger(0); > static final CountDownLatch allContinue = new CountDownLatch(1); > static class PermissiveSecurityManger extends SecurityManager { > @@ -164,7 +165,8 @@ > } > @Override protected void beforeExecute(Thread t, Runnable r) { > allStarted.countDown(); > - if (allStarted.getCount() < getCorePoolSize()) > + // Get last core pool cohort to start in unison > + if (flakes.size() - taskSerial.incrementAndGet() < getCorePoolSize()) > try { allContinue.await(); } > catch (InterruptedException x) { unexpected(x); } > beforeExecuteCount.getAndIncrement(); > > > > On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan > wrote: > > This only happened when I tried a 1000 times loop run, see the > jstack out put below: > Also by using jmap/jhat, below values help me find the reason > flakes.size() = 25 > allStarted.state = 1 > beforeExecuteCount.count = 1 > > Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed > mode): > > "Attach Listener" #32 daemon prio=9 os_prio=31 > tid=0x00007faf1d808000 nid=0x390b waiting on condition > [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 > nid=0x5d0b waiting on condition [0x000000019b530000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 > nid=0x5507 waiting on condition [0x000000019ae1b000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 > nid=0x6307 waiting on condition [0x000000019b227000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 > nid=0x6107 waiting on condition [0x000000019b42d000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 > nid=0x500b waiting on condition [0x000000019ad18000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 > nid=0x5f03 waiting on condition [0x000000019b32a000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 > nid=0x540b waiting on condition [0x000000019ab12000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 > nid=0x5107 waiting on condition [0x000000019af1e000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 > waiting on condition [0x000000019ac15000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 > waiting on condition [0x000000019b124000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e9610> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at > ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:744) > > "Service Thread" #8 daemon prio=9 os_prio=31 > tid=0x00007faf1c837000 nid=0x4b03 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 > tid=0x00007faf1c816000 nid=0x4903 waiting on condition > [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 > tid=0x00007faf1c809800 nid=0x4703 waiting on condition > [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 > tid=0x00007faf1c818000 nid=0x4503 waiting on condition > [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Signal Dispatcher" #4 daemon prio=9 os_prio=31 > tid=0x00007faf1c078800 nid=0x4303 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 > nid=0x2d03 in Object.wait() [0x00000001999be000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x0000000168286218> (a > java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) > - locked <0x0000000168286218> (a > java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) > at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) > > "Reference Handler" #2 daemon prio=10 os_prio=31 > tid=0x00007faf1c810800 nid=0x2b03 in Object.wait() > [0x00000001998bb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x0000000168285c88> (a java.lang.ref.Reference$Lock) > at java.lang.Object.wait(Object.java:502) > at > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) > - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) > > "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 > waiting on condition [0x000000010386e000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000001683e95e0> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) > at > java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) > at ThrowingTasks.realMain(ThrowingTasks.java:207) > at ThrowingTasks.main(ThrowingTasks.java:267) > > "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable > > "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 > nid=0x2103 runnable > > "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 > nid=0x2303 runnable > > "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 > nid=0x2503 runnable > > "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 > nid=0x2703 runnable > > "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 > nid=0x4d03 waiting on condition > > JNI global references: 7 > > > On 02/11/2013 04:01, Martin Buchholz wrote: >> >> >> Including a jstack output extract might be useful for diagnosis. >> >> I have never seen this test fail. Is there a hint that might >> allow me to reproduce it? > > From david.holmes at oracle.com Mon Nov 4 01:09:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 11:09:08 +1000 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <5276EF0F.8090107@oracle.com> References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> Message-ID: <5276F3B4.7080606@oracle.com> Hi Tristan, On 4/11/2013 10:49 AM, Tristan Yan wrote: > Thank you Martin > I had code change. I took the similar way as you do here. > > Please review the code change for JDK-8025198. > Description: > Race condition exists in the test ThrowingTasks.java. We should sync > CountDownLatch.countDown and CountDownLatch.getCount. Locking access to a CountDownLatch just seems inherently wrong. I get that it is the atomicity of the two calls that we want, but this still seems unpleasant. I've looked at Martin's suggested fix and confess that I am struggling to understand what exactly are we trying to achieve with this synchronization ?? Thanks, David > http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.01/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java.sdiff.html > > > Thank you > Tristan > > > On 11/03/2013 12:46 PM, Martin Buchholz wrote: >> I think the author of this test was sleep-deprived by baby Tristan >> back in 2007.Inline image 1 >> >> I tried and failed to find a single synchronizer that properly does >> what we are trying to do with allStarted here. Too bad >> CountDownLatch.countDown doesn't return the count. Best to introduce >> another synchronizer. I propose this fix: >> >> diff --git >> a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> @@ -136,6 +136,7 @@ >> } >> static final CountDownLatch allStarted = new >> CountDownLatch(flakes.size()); >> + static final AtomicInteger taskSerial = new AtomicInteger(0); >> static final CountDownLatch allContinue = new CountDownLatch(1); >> static class PermissiveSecurityManger extends SecurityManager { >> @@ -164,7 +165,8 @@ >> } >> @Override protected void beforeExecute(Thread t, Runnable r) { >> allStarted.countDown(); >> - if (allStarted.getCount() < getCorePoolSize()) >> + // Get last core pool cohort to start in unison >> + if (flakes.size() - taskSerial.incrementAndGet() < getCorePoolSize()) >> try { allContinue.await(); } >> catch (InterruptedException x) { unexpected(x); } >> beforeExecuteCount.getAndIncrement(); >> >> >> >> On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan > > wrote: >> >> This only happened when I tried a 1000 times loop run, see the >> jstack out put below: >> Also by using jmap/jhat, below values help me find the reason >> flakes.size() = 25 >> allStarted.state = 1 >> beforeExecuteCount.count = 1 >> >> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed >> mode): >> >> "Attach Listener" #32 daemon prio=9 os_prio=31 >> tid=0x00007faf1d808000 nid=0x390b waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 >> nid=0x5d0b waiting on condition [0x000000019b530000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 >> nid=0x5507 waiting on condition [0x000000019ae1b000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 >> nid=0x6307 waiting on condition [0x000000019b227000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 >> nid=0x6107 waiting on condition [0x000000019b42d000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 >> nid=0x500b waiting on condition [0x000000019ad18000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 >> nid=0x5f03 waiting on condition [0x000000019b32a000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 >> nid=0x540b waiting on condition [0x000000019ab12000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 >> nid=0x5107 waiting on condition [0x000000019af1e000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 >> waiting on condition [0x000000019ac15000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 >> waiting on condition [0x000000019b124000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:744) >> >> "Service Thread" #8 daemon prio=9 os_prio=31 >> tid=0x00007faf1c837000 nid=0x4b03 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 >> tid=0x00007faf1c816000 nid=0x4903 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 >> tid=0x00007faf1c809800 nid=0x4703 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 >> tid=0x00007faf1c818000 nid=0x4503 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=31 >> tid=0x00007faf1c078800 nid=0x4303 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 >> nid=0x2d03 in Object.wait() [0x00000001999be000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x0000000168286218> (a >> java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) >> - locked <0x0000000168286218> (a >> java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) >> at >> java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) >> >> "Reference Handler" #2 daemon prio=10 os_prio=31 >> tid=0x00007faf1c810800 nid=0x2b03 in Object.wait() >> [0x00000001998bb000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x0000000168285c88> (a >> java.lang.ref.Reference$Lock) >> at java.lang.Object.wait(Object.java:502) >> at >> java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) >> - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >> >> "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 >> waiting on condition [0x000000010386e000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e95e0> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> >> at >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at ThrowingTasks.realMain(ThrowingTasks.java:207) >> at ThrowingTasks.main(ThrowingTasks.java:267) >> >> "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable >> >> "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 >> nid=0x2103 runnable >> >> "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 >> nid=0x2303 runnable >> >> "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 >> nid=0x2503 runnable >> >> "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 >> nid=0x2703 runnable >> >> "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 >> nid=0x4d03 waiting on condition >> >> JNI global references: 7 >> >> >> On 02/11/2013 04:01, Martin Buchholz wrote: >>> >>> >>> Including a jstack output extract might be useful for diagnosis. >>> >>> I have never seen this test fail. Is there a hint that might >>> allow me to reproduce it? >> >> > From david.holmes at oracle.com Mon Nov 4 01:32:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 11:32:30 +1000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <527418F8.5040507@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> Message-ID: <5276F92E.5030405@oracle.com> Hi Mandy, On 2/11/2013 7:11 AM, Mandy Chung wrote: > On 11/1/13 1:37 PM, mark.reinhold at oracle.com wrote: >> 2013/11/1 4:15 -0700, mandy.chung at 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 >> JavaLangAccess object every single time. Is it worth caching that >> earlier, maybe when the finalize thread starts, since it will never >> change? > > I was expecting that would get optimized during runtime and it's a > simple getter method. It's a good suggestion to cache it at the finalize > thread start time and here is the revised webrev: > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ I'm missing something basic - how did you get this to compile: public void invokeFinalize(Object o) throws Throwable { o.finalize(); } given finalize is protected ?? 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'? 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 could be problematic. Overall I think a safer approach may be to fix the native JNI code so that if it gets a private version of finalize() it looks up the method in the superclass. David > Thanks for the review. > Mandy > From martinrb at google.com Mon Nov 4 03:38:32 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 3 Nov 2013 19:38:32 -0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <5276EF0F.8090107@oracle.com> References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> Message-ID: Tristan, I think your change it correct. There are some stylistic improvements I would make: - make lock final - make lessThanCorePoolSize "blank final"; final boolean lessThanCorePoolSize; - add spaces after // and before { On Sun, Nov 3, 2013 at 4:49 PM, Tristan Yan wrote: > Thank you Martin > I had code change. I took the similar way as you do here. > > Please review the code change for JDK-8025198. > Description: > Race condition exists in the test ThrowingTasks.java. We should sync > CountDownLatch.countDown and CountDownLatch.getCount. > > > http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.01/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java.sdiff.html > > Thank you > Tristan > > > > On 11/03/2013 12:46 PM, Martin Buchholz wrote: > > I think the author of this test was sleep-deprived by baby Tristan back in > 2007.[image: Inline image 1] > > I tried and failed to find a single synchronizer that properly does what > we are trying to do with allStarted here. Too bad CountDownLatch.countDown > doesn't return the count. Best to introduce another synchronizer. I > propose this fix: > > diff --git > a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > @@ -136,6 +136,7 @@ > } > > static final CountDownLatch allStarted = new > CountDownLatch(flakes.size()); > + static final AtomicInteger taskSerial = new AtomicInteger(0); > static final CountDownLatch allContinue = new CountDownLatch(1); > > static class PermissiveSecurityManger extends SecurityManager { > @@ -164,7 +165,8 @@ > } > @Override protected void beforeExecute(Thread t, Runnable r) { > allStarted.countDown(); > - if (allStarted.getCount() < getCorePoolSize()) > + // Get last core pool cohort to start in unison > + if (flakes.size() - taskSerial.incrementAndGet() < > getCorePoolSize()) > try { allContinue.await(); } > catch (InterruptedException x) { unexpected(x); } > beforeExecuteCount.getAndIncrement(); > > > > On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan wrote: > >> This only happened when I tried a 1000 times loop run, see the jstack >> out put below: >> Also by using jmap/jhat, below values help me find the reason >> flakes.size() = 25 >> allStarted.state = 1 >> beforeExecuteCount.count = 1 >> >> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed mode): >> >> "Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007faf1d808000 >> nid=0x390b waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 nid=0x5d0b >> waiting on condition [0x000000019b530000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 nid=0x5507 >> waiting on condition [0x000000019ae1b000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 nid=0x6307 >> waiting on condition [0x000000019b227000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 nid=0x6107 >> waiting on condition [0x000000019b42d000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 nid=0x500b >> waiting on condition [0x000000019ad18000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 nid=0x5f03 >> waiting on condition [0x000000019b32a000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 nid=0x540b >> waiting on condition [0x000000019ab12000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 nid=0x5107 >> waiting on condition [0x000000019af1e000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 >> waiting on condition [0x000000019ac15000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 >> waiting on condition [0x000000019b124000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Service Thread" #8 daemon prio=9 os_prio=31 tid=0x00007faf1c837000 >> nid=0x4b03 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007faf1c816000 >> nid=0x4903 waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007faf1c809800 >> nid=0x4703 waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007faf1c818000 >> nid=0x4503 waiting on condition [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007faf1c078800 >> nid=0x4303 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 nid=0x2d03 >> in Object.wait() [0x00000001999be000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x0000000168286218> (a >> java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) >> - locked <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) >> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) >> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) >> >> "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007faf1c810800 >> nid=0x2b03 in Object.wait() [0x00000001998bb000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >> at java.lang.Object.wait(Object.java:502) >> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) >> - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >> >> "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 waiting on >> condition [0x000000010386e000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e95e0> (a >> java.util.concurrent.CountDownLatch$Sync) >> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at ThrowingTasks.realMain(ThrowingTasks.java:207) >> at ThrowingTasks.main(ThrowingTasks.java:267) >> >> "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable >> >> "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 >> nid=0x2103 runnable >> >> "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 >> nid=0x2303 runnable >> >> "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 >> nid=0x2503 runnable >> >> "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 >> nid=0x2703 runnable >> >> "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 nid=0x4d03 >> waiting on condition >> >> JNI global references: 7 >> >> >> On 02/11/2013 04:01, Martin Buchholz wrote: >> >> >> >> Including a jstack output extract might be useful for diagnosis. >> >> I have never seen this test fail. Is there a hint that might allow me >> to reproduce it? >> >> >> > > From martinrb at google.com Mon Nov 4 03:42:02 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 3 Nov 2013 19:42:02 -0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <5276F3B4.7080606@oracle.com> References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> <5276F3B4.7080606@oracle.com> Message-ID: On Sun, Nov 3, 2013 at 5:09 PM, David Holmes wrote: > > Locking access to a CountDownLatch just seems inherently wrong. I get that > it is the atomicity of the two calls that we want, but this still seems > unpleasant. I've looked at Martin's suggested fix and confess that I am > struggling to understand what exactly are we trying to achieve with this > synchronization ?? > I was scratching my head trying to understand the author's intent as well. The idea IIRC was to have the last cohort of pool-size threads all start executing "as concurrently as possible" to try to tickle any races. Perhaps that was indeed able to help repro some bug back in 2007. From david.holmes at oracle.com Mon Nov 4 03:47:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 13:47:46 +1000 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> <5276F3B4.7080606@oracle.com> Message-ID: <527718E2.1070800@oracle.com> On 4/11/2013 1:42 PM, Martin Buchholz wrote: > On Sun, Nov 3, 2013 at 5:09 PM, David Holmes wrote: > >> >> Locking access to a CountDownLatch just seems inherently wrong. I get that >> it is the atomicity of the two calls that we want, but this still seems >> unpleasant. I've looked at Martin's suggested fix and confess that I am >> struggling to understand what exactly are we trying to achieve with this >> synchronization ?? >> > > I was scratching my head trying to understand the author's intent as well. > > The idea IIRC was to have the last cohort of pool-size threads all start > executing "as concurrently as possible" to try to tickle any races. In that case Tristan's locking scheme is likely to be counter-productive due to the forced serialization. David > Perhaps that was indeed able to help repro some bug back in 2007. > From tristan.yan at oracle.com Mon Nov 4 04:14:22 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 04 Nov 2013 12:14:22 +0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> Message-ID: <52771F1E.3060701@oracle.com> Thank you Martin I updated the code as below http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.02/ Thank you On 11/04/2013 11:38 AM, Martin Buchholz wrote: > Tristan, I think your change it correct. > There are some stylistic improvements I would make: > - make lock final > - make lessThanCorePoolSize "blank final"; final boolean > lessThanCorePoolSize; > - add spaces after // and before { > > > On Sun, Nov 3, 2013 at 4:49 PM, Tristan Yan > wrote: > > Thank you Martin > I had code change. I took the similar way as you do here. > > Please review the code change for JDK-8025198. > Description: > Race condition exists in the test ThrowingTasks.java. We should > sync CountDownLatch.countDown and CountDownLatch.getCount. > > http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.01/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java.sdiff.html > > > Thank you > Tristan > > > > On 11/03/2013 12:46 PM, Martin Buchholz wrote: >> I think the author of this test was sleep-deprived by baby >> Tristan back in 2007.Inline image 1 >> >> I tried and failed to find a single synchronizer that properly >> does what we are trying to do with allStarted here. Too bad >> CountDownLatch.countDown doesn't return the count. Best to >> introduce another synchronizer. I propose this fix: >> >> diff --git >> a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> @@ -136,6 +136,7 @@ >> } >> static final CountDownLatch allStarted = new >> CountDownLatch(flakes.size()); >> + static final AtomicInteger taskSerial = new AtomicInteger(0); >> static final CountDownLatch allContinue = new CountDownLatch(1); >> static class PermissiveSecurityManger extends SecurityManager { >> @@ -164,7 +165,8 @@ >> } >> @Override protected void beforeExecute(Thread t, >> Runnable r) { >> allStarted.countDown(); >> - if (allStarted.getCount() < getCorePoolSize()) >> + // Get last core pool cohort to start in unison >> + if (flakes.size() - taskSerial.incrementAndGet() < >> getCorePoolSize()) >> try { allContinue.await(); } >> catch (InterruptedException x) { unexpected(x); } >> beforeExecuteCount.getAndIncrement(); >> >> >> >> On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan >> > wrote: >> >> This only happened when I tried a 1000 times loop run, see >> the jstack out put below: >> Also by using jmap/jhat, below values help me find the reason >> flakes.size() = 25 >> allStarted.state = 1 >> beforeExecuteCount.count = 1 >> >> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 >> mixed mode): >> >> "Attach Listener" #32 daemon prio=9 os_prio=31 >> tid=0x00007faf1d808000 nid=0x390b waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 >> nid=0x5d0b waiting on condition [0x000000019b530000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 >> nid=0x5507 waiting on condition [0x000000019ae1b000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 >> nid=0x6307 waiting on condition [0x000000019b227000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 >> nid=0x6107 waiting on condition [0x000000019b42d000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 >> nid=0x500b waiting on condition [0x000000019ad18000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 >> nid=0x5f03 waiting on condition [0x000000019b32a000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 >> nid=0x540b waiting on condition [0x000000019ab12000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 >> nid=0x5107 waiting on condition [0x000000019af1e000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 >> nid=0x5807 waiting on condition [0x000000019ac15000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 >> nid=0x5b03 waiting on condition [0x000000019b124000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e9610> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at >> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:744) >> >> "Service Thread" #8 daemon prio=9 os_prio=31 >> tid=0x00007faf1c837000 nid=0x4b03 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 >> tid=0x00007faf1c816000 nid=0x4903 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 >> tid=0x00007faf1c809800 nid=0x4703 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 >> tid=0x00007faf1c818000 nid=0x4503 waiting on condition >> [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Signal Dispatcher" #4 daemon prio=9 os_prio=31 >> tid=0x00007faf1c078800 nid=0x4303 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> >> "Finalizer" #3 daemon prio=8 os_prio=31 >> tid=0x00007faf1c811000 nid=0x2d03 in Object.wait() >> [0x00000001999be000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x0000000168286218> (a >> java.lang.ref.ReferenceQueue$Lock) >> at >> java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) >> - locked <0x0000000168286218> (a >> java.lang.ref.ReferenceQueue$Lock) >> at >> java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) >> at >> java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) >> >> "Reference Handler" #2 daemon prio=10 os_prio=31 >> tid=0x00007faf1c810800 nid=0x2b03 in Object.wait() >> [0x00000001998bb000] >> java.lang.Thread.State: WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0x0000000168285c88> (a >> java.lang.ref.Reference$Lock) >> at java.lang.Object.wait(Object.java:502) >> at >> java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) >> - locked <0x0000000168285c88> (a >> java.lang.ref.Reference$Lock) >> >> "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 >> waiting on condition [0x000000010386e000] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x00000001683e95e0> (a >> java.util.concurrent.CountDownLatch$Sync) >> at >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >> at >> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >> at ThrowingTasks.realMain(ThrowingTasks.java:207) >> at ThrowingTasks.main(ThrowingTasks.java:267) >> >> "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 >> runnable >> >> "GC task thread#0 (ParallelGC)" os_prio=31 >> tid=0x00007faf1c80d000 nid=0x2103 runnable >> >> "GC task thread#1 (ParallelGC)" os_prio=31 >> tid=0x00007faf1c012000 nid=0x2303 runnable >> >> "GC task thread#2 (ParallelGC)" os_prio=31 >> tid=0x00007faf1c80e000 nid=0x2503 runnable >> >> "GC task thread#3 (ParallelGC)" os_prio=31 >> tid=0x00007faf1c013000 nid=0x2703 runnable >> >> "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 >> nid=0x4d03 waiting on condition >> >> JNI global references: 7 >> >> >> On 02/11/2013 04:01, Martin Buchholz wrote: >>> >>> >>> Including a jstack output extract might be useful for diagnosis. >>> >>> I have never seen this test fail. Is there a hint that >>> might allow me to reproduce it? >> >> > > From mandy.chung at oracle.com Mon Nov 4 04:15:02 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 03 Nov 2013 20:15:02 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5274D6E9.30707@gmail.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5274D6E9.30707@gmail.com> Message-ID: <52771F46.9060009@oracle.com> On 11/2/2013 3:41 AM, Peter Levart wrote: > > On 11/01/2013 10:11 PM, Mandy Chung wrote: >> On 11/1/13 1:37 PM, mark.reinhold at oracle.com wrote: >>> 2013/11/1 4:15 -0700, mandy.chung at 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 >>> JavaLangAccess object every single time. Is it worth caching that >>> earlier, maybe when the finalize thread starts, since it will never >>> change? >> >> I was expecting that would get optimized during runtime and it's a >> simple getter method. It's a good suggestion to cache it at the >> finalize thread start time and here is the revised webrev: >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ >> >> Thanks for the review. >> Mandy >> > > Hi Mandy, > > FWIW, I don't know if you gain anything by caching static field in a > static field, performance wise.It looks nicer at use site though. If > performance was really extremely important in this use case (which I > think is not) then "jla" should be a local variable inside > FinalizerThread.run() (and possibly in the anonymous Runnables too) > and passed as an argument to Finalizer.runFinalizer(). > > Looking at code once more, I see a possible data race. Is it remotely > possible, that either Finalizer.runFinalization() or > Finalizer.runAllFinalizers() is executed and new secondary finalizer > thread spawned and executed before FinalizerThread manages to call > ensureAccessAvailable(), therefore executing the > Finalizer.runFinalizer() methods before static Finalizer.jla is > initialized? Finalizer.runFinalization() or Finalizer.runAllFinalizers() can only be called after the VM initialization completes. The Finalizer class is initialized (which creates and starts the Finalizer thread) before System.initializeSystemClass is called. At that point, the system class loader is not initialized yet. When it returns (i.e. set booted), it notifies the Finalizer thread. The Finalizer thread has a higher priority and I don't see in practice it won't get notified to set jla before the secondary finalizer thread starts (which will have to wait the main entry point starts). > Even though jla field was initialized, what guarantees it's value > being visible in spawned secondary finalizer threads? FinalizerThread > is started in Finalizer's static initializer, yes, but > ensureAccessAvailable() is called by FinalizerThread after it starts... > Good catch. Perhaps to make it less confusing, the secondary finalizer thread could call ensureAccessAvailable (with some modification). I'll revise the patch and send a new webrev out. Mandy > Considering all this, it might be safer to just ready the > SharedSecrets field every time it's needed. > > > Regards, Peter > From mandy.chung at oracle.com Mon Nov 4 04:45:27 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 03 Nov 2013 20:45:27 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5276F92E.5030405@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> Message-ID: <52772667.8080100@oracle.com> 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.reinhold at oracle.com wrote: >>> 2013/11/1 4:15 -0700, mandy.chung at 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 >>> JavaLangAccess object every single time. Is it worth caching that >>> earlier, maybe when the finalize thread starts, since it will never >>> change? >> >> I was expecting that would get optimized during runtime and it's a >> simple getter method. It's a good suggestion to cache it at the finalize >> thread start time and here is the revised webrev: >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ > > I'm missing something basic - how did you get this to compile: > > public void invokeFinalize(Object o) throws Throwable { > o.finalize(); > } > > given finalize is protected ?? > protected members can be accessed by the same package and subclasses. This is the implementation of JavaLangAccess in java.lang.System that is in the same package as java.lang.Object. > 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'? That sounds a good idea. Let me think about it and get back to this. > 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 could be problematic. Hmm... agents calling System.runFinalization during startup - like Alan described, the agent is playing fire. The potential issue that could happen is that during the VM initialization the heap is so small that triggers GC and also the startup code has finalizers and those objects with finalizers are awaiting for finalization in order for the sufficient memory to be freed up. The VM initialization couldn't get completed and the Finalizer thread is blocked and thus due to insufficient memory, eventually it would get out of memory. An agent instrumenting classes early in the startup and creates lots of objects and finalizers, that might also cause problem. I think it's good to have the secondary finalizer thread to call ensureAccessAvailable (with some modification to ensure jla is initialized). > > Overall I think a safer approach may be to fix the native JNI code so > that if it gets a private version of finalize() it looks up the method > in the superclass. There is other issue (e.g. static method with same name/descriptor) that JNI_GetMethodID has to resolve. This will be a bigger change in the VM that probably can't make jdk8. I think the proposed patch with slight change in the secondary finalizer thread is a relative safe approach (I wil revise the patch and send out another rev tomorrow). thanks Mandy From sundararajan.athijegannathan at oracle.com Mon Nov 4 05:01:48 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 04 Nov 2013 05:01:48 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131104050151.57EF26295C@hg.openjdk.java.net> Changeset: ae5f2130c3b9 Author: sundar Date: 2013-11-01 19:54 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ae5f2130c3b9 8027700: function redeclaration checks missing for declaration binding instantiation Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/script/basic/JDK-8015355.js + test/script/basic/JDK-8027700.js Changeset: 98bab0cdd7bf Author: attila Date: 2013-11-01 15:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/98bab0cdd7bf 8027236: Ensure ScriptObject and ConsString aren't visible to Java Reviewed-by: lagergren, sundar ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java + test/script/basic/JDK-8027236.js + test/script/basic/JDK-8027236.js.EXPECTED + test/src/jdk/nashorn/api/javaaccess/ConsStringTest.java Changeset: 144861e24260 Author: sundar Date: 2013-11-04 09:29 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/144861e24260 Merge From david.holmes at oracle.com Mon Nov 4 05:19:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 15:19:49 +1000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52772667.8080100@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> Message-ID: <52772E75.4030006@oracle.com> Hi Mandy, I'll wait for the updated webrev. FYI I wasn't suggesting any VM changes regarding GetMethodID. I assumed, incorrectly, that once you had the method ID you could query to see if it was private. That said if you called GetMethodID on Object.class and then did the CallVoidMethod(env, obj) would that actually work? (I hadn't realized JNI calling mechanism were so limited with regards to how to select the desired method.) Thanks, David On 4/11/2013 2:45 PM, 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.reinhold at oracle.com wrote: >>>> 2013/11/1 4:15 -0700, mandy.chung at 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 >>>> JavaLangAccess object every single time. Is it worth caching that >>>> earlier, maybe when the finalize thread starts, since it will never >>>> change? >>> >>> I was expecting that would get optimized during runtime and it's a >>> simple getter method. It's a good suggestion to cache it at the finalize >>> thread start time and here is the revised webrev: >>> >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ >> >> I'm missing something basic - how did you get this to compile: >> >> public void invokeFinalize(Object o) throws Throwable { >> o.finalize(); >> } >> >> given finalize is protected ?? >> > > protected members can be accessed by the same package and subclasses. > This is the implementation of JavaLangAccess in java.lang.System that is > in the same package as java.lang.Object. > >> 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'? > > That sounds a good idea. Let me think about it and get back to this. > >> 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 could be problematic. > > Hmm... agents calling System.runFinalization during startup - like Alan > described, the agent is playing fire. > > The potential issue that could happen is that during the VM > initialization the heap is so small that triggers GC and also the > startup code has finalizers and those objects with finalizers are > awaiting for finalization in order for the sufficient memory to be freed > up. The VM initialization couldn't get completed and the Finalizer > thread is blocked and thus due to insufficient memory, eventually it > would get out of memory. An agent instrumenting classes early in the > startup and creates lots of objects and finalizers, that might also > cause problem. > > I think it's good to have the secondary finalizer thread to call > ensureAccessAvailable (with some modification to ensure jla is > initialized). > >> >> Overall I think a safer approach may be to fix the native JNI code so >> that if it gets a private version of finalize() it looks up the method >> in the superclass. > > There is other issue (e.g. static method with same name/descriptor) that > JNI_GetMethodID has to resolve. This will be a bigger change in the VM > that probably can't make jdk8. > > I think the proposed patch with slight change in the secondary finalizer > thread is a relative safe approach (I wil revise the patch and send out > another rev tomorrow). > > thanks > Mandy From martinrb at google.com Mon Nov 4 06:40:31 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 3 Nov 2013 22:40:31 -0800 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <52771F1E.3060701@oracle.com> References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> <52771F1E.3060701@oracle.com> Message-ID: David and I might prefer a fix using AtomicInteger, but I don't think there's anything incorrect with your fix - approved. Especially if you have seen the flakiness has gone away. (I've never seen this test fail.) On Sun, Nov 3, 2013 at 8:14 PM, Tristan Yan wrote: > Thank you Martin > I updated the code as below > > http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.02/ > Thank you > > > > On 11/04/2013 11:38 AM, Martin Buchholz wrote: > > Tristan, I think your change it correct. > There are some stylistic improvements I would make: > - make lock final > - make lessThanCorePoolSize "blank final"; final boolean > lessThanCorePoolSize; > - add spaces after // and before { > > > On Sun, Nov 3, 2013 at 4:49 PM, Tristan Yan wrote: > >> Thank you Martin >> I had code change. I took the similar way as you do here. >> >> Please review the code change for JDK-8025198. >> Description: >> Race condition exists in the test ThrowingTasks.java. We should sync >> CountDownLatch.countDown and CountDownLatch.getCount. >> >> >> http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.01/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java.sdiff.html >> >> Thank you >> Tristan >> >> >> >> On 11/03/2013 12:46 PM, Martin Buchholz wrote: >> >> I think the author of this test was sleep-deprived by baby Tristan back >> in 2007.[image: Inline image 1] >> >> I tried and failed to find a single synchronizer that properly does >> what we are trying to do with allStarted here. Too bad >> CountDownLatch.countDown doesn't return the count. Best to introduce >> another synchronizer. I propose this fix: >> >> diff --git >> a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >> @@ -136,6 +136,7 @@ >> } >> >> static final CountDownLatch allStarted = new >> CountDownLatch(flakes.size()); >> + static final AtomicInteger taskSerial = new AtomicInteger(0); >> static final CountDownLatch allContinue = new CountDownLatch(1); >> >> static class PermissiveSecurityManger extends SecurityManager { >> @@ -164,7 +165,8 @@ >> } >> @Override protected void beforeExecute(Thread t, Runnable r) { >> allStarted.countDown(); >> - if (allStarted.getCount() < getCorePoolSize()) >> + // Get last core pool cohort to start in unison >> + if (flakes.size() - taskSerial.incrementAndGet() < >> getCorePoolSize()) >> try { allContinue.await(); } >> catch (InterruptedException x) { unexpected(x); } >> beforeExecuteCount.getAndIncrement(); >> >> >> >> On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan wrote: >> >>> This only happened when I tried a 1000 times loop run, see the jstack >>> out put below: >>> Also by using jmap/jhat, below values help me find the reason >>> flakes.size() = 25 >>> allStarted.state = 1 >>> beforeExecuteCount.count = 1 >>> >>> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed mode): >>> >>> "Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007faf1d808000 >>> nid=0x390b waiting on condition [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 nid=0x5d0b >>> waiting on condition [0x000000019b530000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 nid=0x5507 >>> waiting on condition [0x000000019ae1b000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 nid=0x6307 >>> waiting on condition [0x000000019b227000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 nid=0x6107 >>> waiting on condition [0x000000019b42d000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 nid=0x500b >>> waiting on condition [0x000000019ad18000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 nid=0x5f03 >>> waiting on condition [0x000000019b32a000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 nid=0x540b >>> waiting on condition [0x000000019ab12000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 nid=0x5107 >>> waiting on condition [0x000000019af1e000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 >>> waiting on condition [0x000000019ac15000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 >>> waiting on condition [0x000000019b124000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e9610> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at >>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:744) >>> >>> "Service Thread" #8 daemon prio=9 os_prio=31 tid=0x00007faf1c837000 >>> nid=0x4b03 runnable [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007faf1c816000 >>> nid=0x4903 waiting on condition [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007faf1c809800 >>> nid=0x4703 waiting on condition [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007faf1c818000 >>> nid=0x4503 waiting on condition [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007faf1c078800 >>> nid=0x4303 runnable [0x0000000000000000] >>> java.lang.Thread.State: RUNNABLE >>> >>> "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 >>> nid=0x2d03 in Object.wait() [0x00000001999be000] >>> java.lang.Thread.State: WAITING (on object monitor) >>> at java.lang.Object.wait(Native Method) >>> - waiting on <0x0000000168286218> (a >>> java.lang.ref.ReferenceQueue$Lock) >>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) >>> - locked <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) >>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) >>> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) >>> >>> "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007faf1c810800 >>> nid=0x2b03 in Object.wait() [0x00000001998bb000] >>> java.lang.Thread.State: WAITING (on object monitor) >>> at java.lang.Object.wait(Native Method) >>> - waiting on <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >>> at java.lang.Object.wait(Object.java:502) >>> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) >>> - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >>> >>> "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 waiting on >>> condition [0x000000010386e000] >>> java.lang.Thread.State: WAITING (parking) >>> at sun.misc.Unsafe.park(Native Method) >>> - parking to wait for <0x00000001683e95e0> (a >>> java.util.concurrent.CountDownLatch$Sync) >>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>> at >>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>> at ThrowingTasks.realMain(ThrowingTasks.java:207) >>> at ThrowingTasks.main(ThrowingTasks.java:267) >>> >>> "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable >>> >>> "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 >>> nid=0x2103 runnable >>> >>> "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 >>> nid=0x2303 runnable >>> >>> "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 >>> nid=0x2503 runnable >>> >>> "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 >>> nid=0x2703 runnable >>> >>> "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 nid=0x4d03 >>> waiting on condition >>> >>> JNI global references: 7 >>> >>> >>> On 02/11/2013 04:01, Martin Buchholz wrote: >>> >>> >>> >>> Including a jstack output extract might be useful for diagnosis. >>> >>> I have never seen this test fail. Is there a hint that might allow me >>> to reproduce it? >>> >>> >>> >> >> > > From peter.levart at gmail.com Mon Nov 4 06:52:02 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Nov 2013 07:52:02 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52772667.8080100@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> Message-ID: <52774412.6010802@gmail.com> 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.reinhold at oracle.com wrote: >>>> 2013/11/1 4:15 -0700, mandy.chung at 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 >>>> JavaLangAccess object every single time. Is it worth caching that >>>> earlier, maybe when the finalize thread starts, since it will never >>>> change? >>> >>> I was expecting that would get optimized during runtime and it's a >>> simple getter method. It's a good suggestion to cache it at the >>> finalize >>> thread start time and here is the revised webrev: >>> >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ >> >> I'm missing something basic - how did you get this to compile: >> >> public void invokeFinalize(Object o) throws Throwable { >> o.finalize(); >> } >> >> given finalize is protected ?? >> > > protected members can be accessed by the same package and subclasses. > This is the implementation of JavaLangAccess in java.lang.System that > is in the same package as java.lang.Object. > >> 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'? > > That sounds a good idea. Let me think about it and get back to this. > >> 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 could be problematic. > > Hmm... agents calling System.runFinalization during startup - like > Alan described, the agent is playing fire. Hi Mandy, Isn't System.runFinalization() just a "hint"? Like System.gc() for example... *

* Calling this method suggests that the Java Virtual Machine expend * effort toward running the finalize methods of objects * that have been found to be discarded but whose finalize * methods have not yet been run. When control returns from the * method call, the Java Virtual Machine has made a *best effort* to * complete all outstanding finalizations. *

Couldn't the request just be ignored when called before VM.isBooted() ? The finalizers will be executed nevertheless asynchronously later by the finalizer thread... Regards, Peter > > The potential issue that could happen is that during the VM > initialization the heap is so small that triggers GC and also the > startup code has finalizers and those objects with finalizers are > awaiting for finalization in order for the sufficient memory to be > freed up. The VM initialization couldn't get completed and the > Finalizer thread is blocked and thus due to insufficient memory, > eventually it would get out of memory. An agent instrumenting classes > early in the startup and creates lots of objects and finalizers, that > might also cause problem. > > I think it's good to have the secondary finalizer thread to call > ensureAccessAvailable (with some modification to ensure jla is > initialized). > >> >> Overall I think a safer approach may be to fix the native JNI code so >> that if it gets a private version of finalize() it looks up the >> method in the superclass. > > There is other issue (e.g. static method with same name/descriptor) > that JNI_GetMethodID has to resolve. This will be a bigger change in > the VM that probably can't make jdk8. > > I think the proposed patch with slight change in the secondary > finalizer thread is a relative safe approach (I wil revise the patch > and send out another rev tomorrow). > > thanks > Mandy From david.holmes at oracle.com Mon Nov 4 06:59:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 16:59:28 +1000 Subject: RFR for JDK-8025198 Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: <5273B7EB.4070206@oracle.com> <52745A0B.8080600@oracle.com> <5276EF0F.8090107@oracle.com> <52771F1E.3060701@oracle.com> Message-ID: <527745D0.4020500@oracle.com> On 4/11/2013 4:40 PM, Martin Buchholz wrote: > David and I might prefer a fix using AtomicInteger, but I don't think > there's anything incorrect with your fix - approved. Especially if you > have seen the flakiness has gone away. (I've never seen this test fail.) +1 David > > On Sun, Nov 3, 2013 at 8:14 PM, Tristan Yan wrote: > >> Thank you Martin >> I updated the code as below >> >> http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.02/ >> Thank you >> >> >> >> On 11/04/2013 11:38 AM, Martin Buchholz wrote: >> >> Tristan, I think your change it correct. >> There are some stylistic improvements I would make: >> - make lock final >> - make lessThanCorePoolSize "blank final"; final boolean >> lessThanCorePoolSize; >> - add spaces after // and before { >> >> >> On Sun, Nov 3, 2013 at 4:49 PM, Tristan Yan wrote: >> >>> Thank you Martin >>> I had code change. I took the similar way as you do here. >>> >>> Please review the code change for JDK-8025198. >>> Description: >>> Race condition exists in the test ThrowingTasks.java. We should sync >>> CountDownLatch.countDown and CountDownLatch.getCount. >>> >>> >>> http://cr.openjdk.java.net/~ewang/tristan/JDK-8025198/webrev.01/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java.sdiff.html >>> >>> Thank you >>> Tristan >>> >>> >>> >>> On 11/03/2013 12:46 PM, Martin Buchholz wrote: >>> >>> I think the author of this test was sleep-deprived by baby Tristan back >>> in 2007.[image: Inline image 1] >>> >>> I tried and failed to find a single synchronizer that properly does >>> what we are trying to do with allStarted here. Too bad >>> CountDownLatch.countDown doesn't return the count. Best to introduce >>> another synchronizer. I propose this fix: >>> >>> diff --git >>> a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >>> b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >>> --- a/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >>> +++ b/test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java >>> @@ -136,6 +136,7 @@ >>> } >>> >>> static final CountDownLatch allStarted = new >>> CountDownLatch(flakes.size()); >>> + static final AtomicInteger taskSerial = new AtomicInteger(0); >>> static final CountDownLatch allContinue = new CountDownLatch(1); >>> >>> static class PermissiveSecurityManger extends SecurityManager { >>> @@ -164,7 +165,8 @@ >>> } >>> @Override protected void beforeExecute(Thread t, Runnable r) { >>> allStarted.countDown(); >>> - if (allStarted.getCount() < getCorePoolSize()) >>> + // Get last core pool cohort to start in unison >>> + if (flakes.size() - taskSerial.incrementAndGet() < >>> getCorePoolSize()) >>> try { allContinue.await(); } >>> catch (InterruptedException x) { unexpected(x); } >>> beforeExecuteCount.getAndIncrement(); >>> >>> >>> >>> On Fri, Nov 1, 2013 at 6:48 PM, Tristan Yan wrote: >>> >>>> This only happened when I tried a 1000 times loop run, see the jstack >>>> out put below: >>>> Also by using jmap/jhat, below values help me find the reason >>>> flakes.size() = 25 >>>> allStarted.state = 1 >>>> beforeExecuteCount.count = 1 >>>> >>>> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b56 mixed mode): >>>> >>>> "Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007faf1d808000 >>>> nid=0x390b waiting on condition [0x0000000000000000] >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> "Thread-22" #31 prio=5 os_prio=31 tid=0x00007faf1d07b000 nid=0x5d0b >>>> waiting on condition [0x000000019b530000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-21" #30 prio=5 os_prio=31 tid=0x00007faf1d80c800 nid=0x5507 >>>> waiting on condition [0x000000019ae1b000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-20" #29 prio=5 os_prio=31 tid=0x00007faf1c10b000 nid=0x6307 >>>> waiting on condition [0x000000019b227000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-18" #27 prio=5 os_prio=31 tid=0x00007faf1c10a000 nid=0x6107 >>>> waiting on condition [0x000000019b42d000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-14" #23 prio=5 os_prio=31 tid=0x00007faf1d80c000 nid=0x500b >>>> waiting on condition [0x000000019ad18000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-13" #22 prio=5 os_prio=31 tid=0x00007faf1c108800 nid=0x5f03 >>>> waiting on condition [0x000000019b32a000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-12" #21 prio=5 os_prio=31 tid=0x00007faf1d80b000 nid=0x540b >>>> waiting on condition [0x000000019ab12000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-10" #19 prio=5 os_prio=31 tid=0x00007faf1d80a800 nid=0x5107 >>>> waiting on condition [0x000000019af1e000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-6" #14 prio=5 os_prio=31 tid=0x00007faf1d809800 nid=0x5807 >>>> waiting on condition [0x000000019ac15000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Thread-8" #16 prio=5 os_prio=31 tid=0x00007faf1d809000 nid=0x5b03 >>>> waiting on condition [0x000000019b124000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e9610> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at >>>> ThrowingTasks$CheckingExecutor.beforeExecute(ThrowingTasks.java:168) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1139) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:744) >>>> >>>> "Service Thread" #8 daemon prio=9 os_prio=31 tid=0x00007faf1c837000 >>>> nid=0x4b03 runnable [0x0000000000000000] >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> "C1 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007faf1c816000 >>>> nid=0x4903 waiting on condition [0x0000000000000000] >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007faf1c809800 >>>> nid=0x4703 waiting on condition [0x0000000000000000] >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007faf1c818000 >>>> nid=0x4503 waiting on condition [0x0000000000000000] >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007faf1c078800 >>>> nid=0x4303 runnable [0x0000000000000000] >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007faf1c811000 >>>> nid=0x2d03 in Object.wait() [0x00000001999be000] >>>> java.lang.Thread.State: WAITING (on object monitor) >>>> at java.lang.Object.wait(Native Method) >>>> - waiting on <0x0000000168286218> (a >>>> java.lang.ref.ReferenceQueue$Lock) >>>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142) >>>> - locked <0x0000000168286218> (a java.lang.ref.ReferenceQueue$Lock) >>>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158) >>>> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189) >>>> >>>> "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007faf1c810800 >>>> nid=0x2b03 in Object.wait() [0x00000001998bb000] >>>> java.lang.Thread.State: WAITING (on object monitor) >>>> at java.lang.Object.wait(Native Method) >>>> - waiting on <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >>>> at java.lang.Object.wait(Object.java:502) >>>> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) >>>> - locked <0x0000000168285c88> (a java.lang.ref.Reference$Lock) >>>> >>>> "main" #1 prio=5 os_prio=31 tid=0x00007faf1c800000 nid=0x1b03 waiting on >>>> condition [0x000000010386e000] >>>> java.lang.Thread.State: WAITING (parking) >>>> at sun.misc.Unsafe.park(Native Method) >>>> - parking to wait for <0x00000001683e95e0> (a >>>> java.util.concurrent.CountDownLatch$Sync) >>>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) >>>> at >>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) >>>> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) >>>> at ThrowingTasks.realMain(ThrowingTasks.java:207) >>>> at ThrowingTasks.main(ThrowingTasks.java:267) >>>> >>>> "VM Thread" os_prio=31 tid=0x00007faf1c066000 nid=0x2903 runnable >>>> >>>> "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007faf1c80d000 >>>> nid=0x2103 runnable >>>> >>>> "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007faf1c012000 >>>> nid=0x2303 runnable >>>> >>>> "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007faf1c80e000 >>>> nid=0x2503 runnable >>>> >>>> "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007faf1c013000 >>>> nid=0x2703 runnable >>>> >>>> "VM Periodic Task Thread" os_prio=31 tid=0x00007faf1c06c800 nid=0x4d03 >>>> waiting on condition >>>> >>>> JNI global references: 7 >>>> >>>> >>>> On 02/11/2013 04:01, Martin Buchholz wrote: >>>> >>>> >>>> >>>> Including a jstack output extract might be useful for diagnosis. >>>> >>>> I have never seen this test fail. Is there a hint that might allow me >>>> to reproduce it? >>>> >>>> >>>> >>> >>> >> >> From peter.levart at gmail.com Mon Nov 4 07:10:58 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Nov 2013 08:10:58 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52774412.6010802@gmail.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52774412.6010802@gmail.com> Message-ID: <52774882.4080001@gmail.com> 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'? >> >> That sounds a good idea. Let me think about it and get back to this. >> >>> 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 could be >>> problematic. >> >> Hmm... agents calling System.runFinalization during startup - like >> Alan described, the agent is playing fire. > > Hi Mandy, > > Isn't System.runFinalization() just a "hint"? Like System.gc() for > example... > > *

> * Calling this method suggests that the Java Virtual Machine expend > * effort toward running the finalize methods of objects > * that have been found to be discarded but whose > finalize > * methods have not yet been run. When control returns from the > * method call, the Java Virtual Machine has made a *best effort* to > * complete all outstanding finalizations. > *

> > Couldn't the request just be ignored when called before VM.isBooted() > ? The finalizers will be executed nevertheless asynchronously later by > the finalizer thread... ...if you do it like the following: /* Called by Runtime.runFinalization() */ static void runFinalization() { if (VM.isBooted()) { // ignore requests early in the VM boot-up sequence forkSecondaryFinalizer(new Runnable() { private volatile boolean running; public void run() { if (running) return; running = true; for (;;) { Finalizer f = (Finalizer)queue.poll(); if (f == null) break; f.runFinalizer(); } } }); } } *and* use the SharedSecrets.getJavaLangAccess() directly, the code also passes the formal proof of having no data races, since you have the following sequence: boot-up thread: write to SharedSecrets.javaLangAccess volatile write to VM.booted thread calling getJavaLangAccess(): volatile read from VM.booted read from SharedSecrets.javaLangAccess I still don't see any advantage of caching JavaLangAccess instance in a private static Finalizer.jla field other than to complicate synchronization. Regards, Peter From peter.levart at gmail.com Mon Nov 4 08:33:55 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Nov 2013 09:33:55 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52772667.8080100@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> Message-ID: <52775BF3.4020708@gmail.com> 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 could be problematic. > > Hmm... agents calling System.runFinalization during startup - like > Alan described, the agent is playing fire. > > The potential issue that could happen is that during the VM > initialization the heap is so small that triggers GC and also the > startup code has finalizers and those objects with finalizers are > awaiting for finalization in order for the sufficient memory to be > freed up. The VM initialization couldn't get completed and the > Finalizer thread is blocked and thus due to insufficient memory, > eventually it would get out of memory. An agent instrumenting classes > early in the startup and creates lots of objects and finalizers, that > might also cause problem. > > I think it's good to have the secondary finalizer thread to call > ensureAccessAvailable (with some modification to ensure jla is > initialized). Hi Mandy, What about the following helper class in java.lang package: package java.lang; import sun.misc.VM; import sun.reflect.CallerSensitive; import sun.reflect.Reflection; /** * Access to protected Object methods. Only accessible to system classes. */ public final class ObjectAccess { private static final ObjectAccess theInstance = new ObjectAccess(); @CallerSensitive public static ObjectAccess getInstance() { Class caller = Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(caller.getClassLoader())) throw new SecurityException("ObjectAccess"); return theInstance; } public void finalizeObject(Object o) throws Throwable { o.finalize(); } public Object cloneObject(Object o) throws CloneNotSupportedException { return o.clone(); } } ...is such code permissible to be executed in the Finalizer's static initializer even before VM.isBooted() ? Regards, Peter From Alan.Bateman at oracle.com Mon Nov 4 08:38:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Nov 2013 08:38:46 +0000 Subject: RFR: 8024876 : [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions In-Reply-To: <5272B564.5080308@oracle.com> References: <5272B564.5080308@oracle.com> Message-ID: <52775D16.6050008@oracle.com> On 31/10/2013 19:54, huizhe wang wrote: > A quick fix to remove path for the temporary output file so that it's > created in the working directory instead: > > http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/ Just reading this now and wondering about xslFilename - is that closed (as it's not obvious)? -Alan. From Alan.Bateman at oracle.com Mon Nov 4 08:48:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Nov 2013 08:48:12 +0000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52775BF3.4020708@gmail.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> Message-ID: <52775F4C.5040601@oracle.com> 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 to JavaLangAccess. -Alan. From peter.levart at gmail.com Mon Nov 4 10:03:32 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 04 Nov 2013 11:03:32 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52775F4C.5040601@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> Message-ID: <527770F4.1070305@gmail.com> 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 to JavaLangAccess. > > -Alan. The problem is that we would like Finalizers to be executed even before VM.isBooted(). Currently this is possible, because native code is used to access Object.finalize(). java.lang.Thread is initialized earlier, but initializing SharedSecrets.javaLangAccess in Thread's static initializer doesn't work (VM crashes). I think this is because SharedSecrets also initialize sun.misc.Unsafe via .getUnsafe() method and this needs the caller ClassLoader to check access... SharedSecrets is already too encumbered to be used that early in boot-up sequence. So what about the following simple class in sun.misc: package sun.misc; /** * Access to protected Object methods. */ public abstract class ObjectAccess { private static ObjectAccess theInstance; public static ObjectAccess getInstance() { return theInstance; } public static void setInstance(ObjectAccess instance) { theInstance = instance; } public abstract void finalizeObject(Object o) throws Throwable; } ...with the following initialization in java.lang.Thread: public class Thread implements Runnable { /* Make sure registerNatives is the first thing does. */ private static native void registerNatives(); static { registerNatives(); * sun.misc.ObjectAccess.setInstance(new ObjectAccess() {** ** @Override** ** public void finalizeObject(Object o) throws Throwable {** ** o.finalize();** ** }** ** });* } I tried executing JVM with these two changes and is seems to work - i.e. does not cause JVM to crash at startup. Regards, Peter From paul.sandoz at oracle.com Mon Nov 4 10:16:40 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 4 Nov 2013 11:16:40 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5274BFC8.9090707@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5274BFC8.9090707@oracle.com> Message-ID: <57DEB41B-ABD3-4E8A-B5F9-410150C49888@oracle.com> On Nov 2, 2013, at 10:03 AM, Alan Bateman wrote: > On 01/11/2013 21:11, Mandy Chung wrote: >> >> I was expecting that would get optimized during runtime and it's a simple getter method. It's a good suggestion to cache it at the finalize thread start time and here is the revised webrev: >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ > > This looks good. A small typo in ensureAccessAvailable, "ntil" -> "until". Also the continue isn't needed. > Plus there is other unmodified code that uses "continue" as well (#207 in patched code). On using a static field to hold JavaLangAccess. If Peter's suggestion is not applicable (splitting out finalization functionality from JavaLangAccess) then perhaps an alternative is: - ensureAccessAvailable returns JavaLangAccess (rename to getJavaLangAccess?) - runFinalizer accepts as a parameter JavaLangAccess Paul. > On the finalizer thread now waiting for the system classes to be initialized then this is probably a good thing (although I can imagine subtle changes for corner cases, say where an agent is playing with fire and instrumenting classes early in the startup). > From david.holmes at oracle.com Mon Nov 4 12:01:06 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 04 Nov 2013 12:01:06 +0000 Subject: hg: jdk8/tl/jdk: 8025198: Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java Message-ID: <20131104120130.640326296D@hg.openjdk.java.net> Changeset: d19ab5da83cc Author: dholmes Date: 2013-11-04 06:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc 8025198: Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java Reviewed-by: martin, dholmes Contributed-by: Tristan Yan ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk ! src/share/bin/java.c ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java From david.holmes at oracle.com Mon Nov 4 12:10:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 22:10:16 +1000 Subject: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: References: Message-ID: <52778EA8.7020800@oracle.com> My commit pulled in a bunch of local changes that should never have been pushed (the import commit failed due to whitespace and when I re-issued the commit I didn't restrict it to the single test file). Can anyone roll this back on the actual server? Thanks, David -------- Original Message -------- Subject: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java Date: Mon, 4 Nov 2013 12:03:22 +0000 (UTC) From: HG Updates (JBS) To: david.holmes at oracle.com [ https://bugs.openjdk.java.net/browse/JDK-8025198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HG Updates resolved JDK-8025198. -------------------------------- Resolved In Build: team Fix Version/s: 8 Resolution: Fixed URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc User: dholmes Date: 2013-11-04 12:01:30 +0000 > Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > ------------------------------------------------------------------------------------- > > Key: JDK-8025198 > URL: https://bugs.openjdk.java.net/browse/JDK-8025198 > Project: JDK > Issue Type: Bug > Components: core-libs > Affects Versions: 8 > Reporter: Amy Lu > Assignee: Tristan Yan > Labels: same-binary, sqebug, teststabilization > Fix For: 8 > > > TESTFAIL:java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java > java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java failing intermittently: > #section:main > ----------messages:(3/175)---------- > command: main -XX:-UseVMInterruptibleIO ThrowingTasks > reason: User specified action: run main/othervm -XX:-UseVMInterruptibleIO ThrowingTasks > elapsed time (seconds): 480.015 > ----------System.out:(0/0)---------- > ----------System.err:(0/0)---------- > result: Error. Program `/Users/aurora/sandbox_keepme/jdk/bin/java' interrupted! (timed out?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://bugs.openjdk.java.net/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira From Alan.Bateman at oracle.com Mon Nov 4 12:35:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Nov 2013 12:35:18 +0000 Subject: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <52778EA8.7020800@oracle.com> References: <52778EA8.7020800@oracle.com> Message-ID: <52779486.3000609@oracle.com> On 04/11/2013 12:10, David Holmes wrote: > My commit pulled in a bunch of local changes that should never have > been pushed (the import commit failed due to whitespace and when I > re-issued the commit I didn't restrict it to the single test file). > > Can anyone roll this back on the actual server? It might be simpler to just push another change that anti-deltas the launcher/other changes. That would get jdk8/tl fixed up before too many people are impacted. -Alan. From david.holmes at oracle.com Mon Nov 4 12:37:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 22:37:05 +1000 Subject: URGENT: RFR 8027755 Anti-delta incorrect push for 8025198 Message-ID: <527794F1.3000003@oracle.com> My commit for 8025198 dragged in unintended changes to: ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk ! src/share/bin/java.c See: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d19ab5da83cc This reverts those changes: http://cr.openjdk.java.net/~dholmes/8027755/webrev/ Thanks, David From david.holmes at oracle.com Mon Nov 4 12:37:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Nov 2013 22:37:47 +1000 Subject: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java In-Reply-To: <52779486.3000609@oracle.com> References: <52778EA8.7020800@oracle.com> <52779486.3000609@oracle.com> Message-ID: <5277951B.1040404@oracle.com> On 4/11/2013 10:35 PM, Alan Bateman wrote: > On 04/11/2013 12:10, David Holmes wrote: >> My commit pulled in a bunch of local changes that should never have >> been pushed (the import commit failed due to whitespace and when I >> re-issued the commit I didn't restrict it to the single test file). >> >> Can anyone roll this back on the actual server? > It might be simpler to just push another change that anti-deltas the > launcher/other changes. That would get jdk8/tl fixed up before too many > people are impacted. Okay RFR sent out to core-libs. Thanks Alan. Apologies for the mess and the noise. David > -Alan. From david.holmes at oracle.com Mon Nov 4 12:41:25 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 04 Nov 2013 12:41:25 +0000 Subject: hg: jdk8/tl/jdk: 8027755: Anti-delta incorrect push for 8025198 Message-ID: <20131104124146.37BAE6296E@hg.openjdk.java.net> Changeset: 23982079ad49 Author: dholmes Date: 2013-11-04 07:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23982079ad49 8027755: Anti-delta incorrect push for 8025198 Reviewed-by: alanb ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk ! src/share/bin/java.c From joel.franck at oracle.com Mon Nov 4 15:29:44 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 4 Nov 2013 16:29:44 +0100 Subject: Assorted annotation optimizations In-Reply-To: <52757570.5010503@gmail.com> References: <52757570.5010503@gmail.com> Message-ID: <8713B570-DC40-4C1A-BE6B-81ACB0972A21@oracle.com> Hi Peter, As always, thanks for doing this! On 2 nov 2013, at 22:58, Peter Levart wrote: > 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/ Skimming this, I think most (or all) of this is good. However now is not the time to do it. This should go into 9 and 8u as soon as they are open for fixes. FWIW I have also been toying with the idea of rewriting the storage of annotations in 9. IIRC you posted a patch with a very specific map for annotations. If we go down that road we should probably do a JEP. cheers /Joel From joel.franck at oracle.com Mon Nov 4 15:30:54 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 4 Nov 2013 16:30:54 +0100 Subject: RFR: 8016725: TEST_BUG: java/lang/reflect/Method/DefaultMethodModeling.java failing intermittently In-Reply-To: <5271A54E.8030408@oracle.com> References: <20131029102640.GA27098@e6430> <5271A54E.8030408@oracle.com> Message-ID: <7027F5A5-6694-4429-A02B-96DDEB8BF868@oracle.com> I'll sponsor this. cheers /Joel On 31 okt 2013, at 01:33, Joseph Darcy wrote: > Hi Andreas, > > Approved; thanks, > > -Joe > > On 10/29/2013 3:26 AM, Andreas Lundblad wrote: >> Hi, >> >> Please review the fix for JDK-8016725 below. >> >> Description: >> DefaultMethodModeling.java and Equals.java in >> jdk/test/java/lang/reflect/Method interfered with each other since >> both tests defines a class named 'A'. >> >> In this patch DefaultMethodModeling.java is moved to its own >> subdirectory. >> >> >> Link to web review: >> http://cr.openjdk.java.net/~alundblad/8016725/webrev.00 >> >> Link to bug report: >> https://bugs.openjdk.java.net/browse/JDK-8016725 >> >> -- Andreas Lundblad > From brian.burkhalter at oracle.com Mon Nov 4 16:06:07 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Mon, 04 Nov 2013 16:06:07 +0000 Subject: hg: jdk8/tl/jdk: 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size Message-ID: <20131104160626.8E14E62976@hg.openjdk.java.net> Changeset: 92fb6baaebc4 Author: bpb Date: 2013-11-04 08:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92fb6baaebc4 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size Summary: Add @run tag to specify heap size Reviewed-by: alanb, dxu ! test/java/math/BigInteger/ExtremeShiftingTests.java From michael.x.mcmahon at oracle.com Mon Nov 4 17:49:36 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 04 Nov 2013 17:49:36 +0000 Subject: hg: jdk8/tl/jdk: 8027687: The constructors of URLPermission class do not behave as described in javad Message-ID: <20131104174948.41A6662979@hg.openjdk.java.net> Changeset: 48449b5390fa Author: michaelm Date: 2013-11-04 17:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa 8027687: The constructors of URLPermission class do not behave as described in javad Reviewed-by: chegar, mduigou ! src/share/classes/java/net/HostPortrange.java ! src/share/classes/java/net/URLPermission.java ! test/java/net/URLPermission/URLPermissionTest.java From mark.reinhold at oracle.com Mon Nov 4 18:05:48 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 04 Nov 2013 10:05:48 -0800 Subject: hg: jdk8/tl/jdk: 8027687: The constructors of URLPermission class do not behave as described in javad In-Reply-To: <20131104174948.41A6662979@hg.openjdk.java.net> References: <20131104174948.41A6662979@hg.openjdk.java.net> Message-ID: <20131104100548.539058@eggemoggin.niobe.net> 2013/11/4 1:49 -0800, michael.x.mcmahon at oracle.com: > Changeset: 48449b5390fa > Author: michaelm > Date: 2013-11-04 17:47 +0000 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48449b5390fa > > 8027687: The constructors of URLPermission class do not behave as described in javad > Reviewed-by: chegar, mduigou What is "javad"? - Mark From robert.field at oracle.com Mon Nov 4 18:12:43 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 04 Nov 2013 18:12:43 +0000 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... Message-ID: <20131104181255.459946297B@hg.openjdk.java.net> 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 serialization fails once reflection proxy generation kicks in Reviewed-by: ksrini, briangoetz, jfranck Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java From joel.franck at oracle.com Mon Nov 4 18:48:27 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 04 Nov 2013 18:48:27 +0000 Subject: hg: jdk8/tl/jdk: 8016725: TEST_BUG: java/lang/reflect/Method/DefaultMethodModeling.java failing intermittently Message-ID: <20131104184839.09ABA6297C@hg.openjdk.java.net> Changeset: 78a0dcde6b67 Author: alundblad Date: 2013-11-04 15:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78a0dcde6b67 8016725: TEST_BUG: java/lang/reflect/Method/DefaultMethodModeling.java failing intermittently Summary: Moved DefaultMethodModeling.java to its own directory to avoid conflicts with Equals.java. Reviewed-by: darcy - test/java/lang/reflect/Method/DefaultMethodModeling.java + test/java/lang/reflect/Method/defaultMethodModeling/DefaultMethodModeling.java From mandy.chung at oracle.com Mon Nov 4 19:32:45 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 04 Nov 2013 11:32:45 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52774412.6010802@gmail.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52774412.6010802@gmail.com> Message-ID: <5277F65D.4000709@oracle.com> On 11/3/13 10:52 PM, Peter Levart wrote: > 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.reinhold at oracle.com wrote: >>>>> 2013/11/1 4:15 -0700, mandy.chung at 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 >>>>> JavaLangAccess object every single time. Is it worth caching that >>>>> earlier, maybe when the finalize thread starts, since it will never >>>>> change? >>>> >>>> I was expecting that would get optimized during runtime and it's a >>>> simple getter method. It's a good suggestion to cache it at the >>>> finalize >>>> thread start time and here is the revised webrev: >>>> >>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.01/ >>> >>> I'm missing something basic - how did you get this to compile: >>> >>> public void invokeFinalize(Object o) throws Throwable { >>> o.finalize(); >>> } >>> >>> given finalize is protected ?? >>> >> >> protected members can be accessed by the same package and >> subclasses. This is the implementation of JavaLangAccess in >> java.lang.System that is in the same package as java.lang.Object. >> >>> 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'? >> >> That sounds a good idea. Let me think about it and get back to this. >> >>> 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 could be >>> problematic. >> >> Hmm... agents calling System.runFinalization during startup - like >> Alan described, the agent is playing fire. > > Hi Mandy, > > Isn't System.runFinalization() just a "hint"? Like System.gc() for > example... > > *

> * Calling this method suggests that the Java Virtual Machine expend > * effort toward running the finalize methods of objects > * that have been found to be discarded but whose > finalize > * methods have not yet been run. When control returns from the > * method call, the Java Virtual Machine has made a *best effort* to > * complete all outstanding finalizations. > *

> > Couldn't the request just be ignored when called before VM.isBooted() > ? The finalizers will be executed nevertheless asynchronously later by > the finalizer thread... That's also what I thought about last night after I sent my reply. Mandy From joel.franck at oracle.com Mon Nov 4 19:36:04 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 4 Nov 2013 20:36:04 +0100 Subject: RFR: JDK-8027796: Refactor Core Reflection for Type Annotations Message-ID: <81B30411-8BD8-4A5A-BA97-C9A8D172DC3C@oracle.com> Hi Please review this small refactoring of the type annotations reflection code. This fix just makes the types final since the code wasn't designed for inheritance. webrev: http://cr.openjdk.java.net/~jfranck/8027796/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8027796 cheers /Joel From mandy.chung at oracle.com Mon Nov 4 20:04:43 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 04 Nov 2013 12:04:43 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <527770F4.1070305@gmail.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> Message-ID: <5277FDDB.3040508@oracle.com> Thank you all for the suggestions. Before the VM initialization is completed, any agent ought to be careful in what things it can do and what shouldn't do. I think it's reasonable to ignore System.runFinalization if it's called at early startup phase. I'm unclear if there is any use case that we really require finalization to happen before VM is booted (I can imagine other problems may happen). I change the runFinalization and runAllFinalizers methods to return if it's not booted and also change runFinalizer method to take JavaLangAccess to simplify the synchronization instead of caching it in the static field. http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/ David - I decided to leave VM.awaitBooted as it is. Having the callsite to call awaitBooted makes it explicit and clear that it's blocking and we will keep SharedSecrets.getJavaLangAccess method consistent with the other SharedSecrets methods that they are all getter methods. If any future change calls SharedSecrets.getJavaLangAccess before it's booted, it's a little easier to diagnose (NPE vs hangs). Peter - thanks for the ObjectAccess idea. I don't think supporting finalization to happen before VM is booted buys us anything and I would rather keep this change simple. Mandy From forax at univ-mlv.fr Mon Nov 4 21:37:31 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 04 Nov 2013 22:37:31 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <20131104181255.459946297B@hg.openjdk.java.net> References: <20131104181255.459946297B@hg.openjdk.java.net> Message-ID: <5278139B.1090508@univ-mlv.fr> On 11/04/2013 07:12 PM, robert.field at 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 serialization fails once reflection proxy generation kicks in > Reviewed-by: ksrini, briangoetz, jfranck > Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com > > ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java > ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java > ! src/share/classes/sun/reflect/misc/ReflectUtil.java > + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java > ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java > + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java > Note that while this fix is ok now, it introduced a performance regression, doing reflection on a functional method of an inner class is faster than doing reflection on the functional method of a lambda proxy. R?mi From huizhe.wang at oracle.com Mon Nov 4 22:32:55 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 04 Nov 2013 14:32:55 -0800 Subject: RFR: 8024876 : [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions In-Reply-To: <52775D16.6050008@oracle.com> References: <5272B564.5080308@oracle.com> <52775D16.6050008@oracle.com> Message-ID: <52782097.4000304@oracle.com> On 11/4/2013 12:38 AM, Alan Bateman wrote: > On 31/10/2013 19:54, huizhe wang wrote: >> A quick fix to remove path for the temporary output file so that it's >> created in the working directory instead: >> >> http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/ > Just reading this now and wondering about xslFilename - is that closed > (as it's not obvious)? It's closed, but outFilename was not. Since the behaviors are different among parsers, I've added them all in a try-with-resources statement. Please review: http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/ Thanks, Joe > > -Alan. From john.r.rose at oracle.com Mon Nov 4 22:56:30 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 4 Nov 2013 14:56:30 -0800 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5278139B.1090508@univ-mlv.fr> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278139B.1090508@univ-mlv.fr> Message-ID: On Nov 4, 2013, at 1:37 PM, Remi Forax wrote: > Note that while this fix is ok now, > it introduced a performance regression, doing reflection on a functional method of an inner class > is faster than doing reflection on the functional method of a lambda proxy. This particular fix didn't introduce a regression, it turned a throw (of NoClassDefFoundError) into correct but slow execution. Some keeping score might call that a speedup. 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: https://bugs.openjdk.java.net/browse/JDK-6824466 ? John From forax at univ-mlv.fr Mon Nov 4 23:29:21 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 05 Nov 2013 00:29:21 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: References: <20131104181255.459946297B@hg.openjdk.java.net> <5278139B.1090508@univ-mlv.fr> Message-ID: <52782DD1.3020902@univ-mlv.fr> On 11/04/2013 11:56 PM, John Rose wrote: > On Nov 4, 2013, at 1:37 PM, Remi Forax > wrote: > >> Note that while this fix is ok now, >> it introduced a performance regression, doing reflection on a >> functional method of an inner class >> is faster than doing reflection on the functional method of a lambda >> proxy. > > This particular fix didn't introduce a regression, it turned a throw > (of NoClassDefFoundError) into correct but slow execution. Some > keeping score might call that a speedup. :) > > 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: > https://bugs.openjdk.java.net/browse/JDK-6824466 I remember writing a code like that a long time ago, to see if it was possible, as far as I remember, the main issue was to be able to say, please compiler compile this method handle chain into a blob that I can reuse. > > ? John regards, R?mi From dan.xu at oracle.com Mon Nov 4 23:48:23 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Mon, 04 Nov 2013 23:48:23 +0000 Subject: hg: jdk8/tl/jdk: 8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage Message-ID: <20131104234835.23B0562A32@hg.openjdk.java.net> Changeset: 6d1f3ba68db2 Author: dxu Date: 2013-11-04 15:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1f3ba68db2 8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage Reviewed-by: chegar ! test/java/io/File/MaxPathLength.java From david.holmes at oracle.com Tue Nov 5 02:03:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Nov 2013 12:03:08 +1000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5277FDDB.3040508@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> Message-ID: <527851DC.9020908@oracle.com> Hi Mandy, This all seems quite reasonable to me. Two minor nits: 1. The "delay ntil" typo in Finalizer.java is still present. 2. In VM.java. booted need not be volatile now that it is only accessed within a locked region. Also awaitBooted might as well be void as it can only ever return true. Thanks, David On 5/11/2013 6:04 AM, Mandy Chung wrote: > Thank you all for the suggestions. > > Before the VM initialization is completed, any agent ought to be careful > in what things it can do and what shouldn't do. I think it's reasonable > to ignore System.runFinalization if it's called at early startup phase. > I'm unclear if there is any use case that we really require finalization > to happen before VM is booted (I can imagine other problems may happen). > I change the runFinalization and runAllFinalizers methods to return if > it's not booted and also change runFinalizer method to take > JavaLangAccess to simplify the synchronization instead of caching it in > the static field. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/ > > David - I decided to leave VM.awaitBooted as it is. Having the callsite > to call awaitBooted makes it explicit and clear that it's blocking and > we will keep SharedSecrets.getJavaLangAccess method consistent with the > other SharedSecrets methods that they are all getter methods. If any > future change calls SharedSecrets.getJavaLangAccess before it's booted, > it's a little easier to diagnose (NPE vs hangs). > > Peter - thanks for the ObjectAccess idea. I don't think supporting > finalization to happen before VM is booted buys us anything and I would > rather keep this change simple. > > Mandy From mandy.chung at oracle.com Tue Nov 5 02:21:30 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 04 Nov 2013 18:21:30 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <527851DC.9020908@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> Message-ID: <5278562A.90209@oracle.com> 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 > accessed within a locked region. Also awaitBooted might as well be > void as it can only ever return true. > Fixed. Revised webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ Thanks for the review. Mandy > Thanks, > David > > On 5/11/2013 6:04 AM, Mandy Chung wrote: >> Thank you all for the suggestions. >> >> Before the VM initialization is completed, any agent ought to be careful >> in what things it can do and what shouldn't do. I think it's reasonable >> to ignore System.runFinalization if it's called at early startup phase. >> I'm unclear if there is any use case that we really require finalization >> to happen before VM is booted (I can imagine other problems may happen). >> I change the runFinalization and runAllFinalizers methods to return if >> it's not booted and also change runFinalizer method to take >> JavaLangAccess to simplify the synchronization instead of caching it in >> the static field. >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/ >> >> David - I decided to leave VM.awaitBooted as it is. Having the callsite >> to call awaitBooted makes it explicit and clear that it's blocking and >> we will keep SharedSecrets.getJavaLangAccess method consistent with the >> other SharedSecrets methods that they are all getter methods. If any >> future change calls SharedSecrets.getJavaLangAccess before it's booted, >> it's a little easier to diagnose (NPE vs hangs). >> >> Peter - thanks for the ObjectAccess idea. I don't think supporting >> finalization to happen before VM is booted buys us anything and I would >> rather keep this change simple. >> >> Mandy From david.holmes at oracle.com Tue Nov 5 02:29:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Nov 2013 12:29:32 +1000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278562A.90209@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> Message-ID: <5278580C.6030804@oracle.com> On 5/11/2013 12:21 PM, 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 >> accessed within a locked region. Oops my bad! The accessor wasn't synchronized but now is. Your call whether to leave as is or revert to previous. Sorry - and thanks. David ----- Also awaitBooted might as well be >> void as it can only ever return true. >> > > Fixed. Revised webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ > > Thanks for the review. > Mandy > >> Thanks, >> David >> >> On 5/11/2013 6:04 AM, Mandy Chung wrote: >>> Thank you all for the suggestions. >>> >>> Before the VM initialization is completed, any agent ought to be careful >>> in what things it can do and what shouldn't do. I think it's reasonable >>> to ignore System.runFinalization if it's called at early startup phase. >>> I'm unclear if there is any use case that we really require finalization >>> to happen before VM is booted (I can imagine other problems may happen). >>> I change the runFinalization and runAllFinalizers methods to return if >>> it's not booted and also change runFinalizer method to take >>> JavaLangAccess to simplify the synchronization instead of caching it in >>> the static field. >>> >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/ >>> >>> David - I decided to leave VM.awaitBooted as it is. Having the callsite >>> to call awaitBooted makes it explicit and clear that it's blocking and >>> we will keep SharedSecrets.getJavaLangAccess method consistent with the >>> other SharedSecrets methods that they are all getter methods. If any >>> future change calls SharedSecrets.getJavaLangAccess before it's booted, >>> it's a little easier to diagnose (NPE vs hangs). >>> >>> Peter - thanks for the ObjectAccess idea. I don't think supporting >>> finalization to happen before VM is booted buys us anything and I would >>> rather keep this change simple. >>> >>> Mandy > From mandy.chung at oracle.com Tue Nov 5 02:54:20 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 04 Nov 2013 18:54:20 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278580C.6030804@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <5278580C.6030804@oracle.com> Message-ID: <52785DDC.70200@oracle.com> On 11/4/2013 6:29 PM, David Holmes wrote: >>> 2. In VM.java. booted need not be volatile now that it is only >>> accessed within a locked region. > > Oops my bad! The accessor wasn't synchronized but now is. Your call > whether to leave as is or revert to previous. I'm fine with making isBooted() to a synchronized method since I expect the contention on this method is very low and that makes access of the booted field using the consistent synchronization. Mandy From mandy.chung at oracle.com Tue Nov 5 03:20:53 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 04 Nov 2013 19:20:53 -0800 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272F80F.4070006@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> Message-ID: <52786415.7090205@oracle.com> David, Rereading your comment and I think you misread the switch statement (see my comments below). In any case, I revisited ThreadStateController.java and looked int the potential races and have done further cleanup. Here is the updated webrev. http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.02/ I'll let them run longer to see if it can uncover any race. How does this version look? Mandy On 10/31/2013 5:38 PM, David Holmes wrote: > Hi Mandy, > > On 1/11/2013 5:11 AM, Mandy Chung wrote: >> Updated webrev that has a new >> test/lib/testlibrary/ThreadStateController.java and also change to use >> AtomicInteger: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ > > Sorry but I don't see how this works - and that applies to the old > version too! (Which I know I've looked at before so this is somewhat > unsettling for me :( ). > > First I found it confusing to track which thread was which in the > refactoring (which in itself is a good idea). Inside > ThreadStateController "myThread" doesn't mean anything - that comes > from the calling context - I suggest changing to refer to "this > thread" or "the current thread" as appropriate. eg "Have the current > thread wait until this thread is about to block" or whatever is needed. > > Looking at an actual test we have eg: > > myThread.goWaiting(); > ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); > > First: why is checkThreadState static rather than just an instance > method? > I'm happy with the new version of ThreadStateController.java with the above cleanup. > So goWaiting is supposed to tell myThread to go to a "waiting" state > so that the main thread can then verify that. Lets assume for > arguments sake that the thread is currently RUNNABLE so it is > currently looping around in run() doing the little math exercise. > goWaiting does: > > public void goWaiting() { > System.out.println("Waiting myThread to go waiting."); > setState(WAITING); > // wait for MyThread to get to just before wait on object. > phaser.arriveAndAwaitAdvance(); > } > > and setState does: > > case WAITING: > case TIMED_WAITING: > state = newState; > synchronized (lock) { > lock.notify(); > } > break; The switch statement is looking at the current state (i.e. RUNNABLE). The above WAITING and TIMED_WAITING cases indicate that this thread is in waiting and thus the request to transition to another state has first to notify this thread so that it can proceed with the state transition. > > > so as soon as we update "state" myThread is capable of changing what > it is doing in run() to: > > case WAITING: { > synchronized (lock) { > // signal main thread. > phaser.arrive(); > System.out.println(" myThread is going to wait."); > try { > lock.wait(); > } catch (InterruptedException e) { > // ignore > interrupted.incrementAndGet(); > } > } > break; > > so now we have a race between the two threads to see who can grab the > lock first. If it is the main thread then we issue a notify when > nothing is waiting and so the subsequent wait() by myThread will > potentially wait forever. At least in that case the main thread will > see that it is waiting! > If this thread is currently in WAITING state, the main thread calls goTimedWaiting, before it notifies this thread, this thread gets waken up due to spurious wakeup or interrupt, then the race depending on who grabs the lock first as you described above will happen. > If "myThread" wins the race it will wait after signalling the phaser > and the main thread will then issue the notify allowing myThread to > proceed (and do what? process the WAITING case again??). So there is > no guarantee that myThread will be waiting when the main thread checks > the state! > > Similarly for issuing the unpark in the parking cases. > > AFAICS the basic approach here should be: > - tell myThread to go to state X > - wait until myThread should be in state X > - verify myThread is in state X That's what the test does. > - allow myThread to escape from state X Is this really needed? This would require the main thread to notify myThread the verification is done. The test currently goes to the new state for validation and it seems to me that this isn't needed. Mandy From david.holmes at oracle.com Tue Nov 5 04:42:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Nov 2013 14:42:30 +1000 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <52786415.7090205@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> <52786415.7090205@oracle.com> Message-ID: <52787736.1090904@oracle.com> Hi Mandy, On 5/11/2013 1:20 PM, Mandy Chung wrote: > David, > > Rereading your comment and I think you misread the switch statement (see Yes I did - many times - sorry. > my comments below). In any case, I revisited ThreadStateController.java > and looked int the potential races and have done further cleanup. Here > is the updated webrev. > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.02/ > > I'll let them run longer to see if it can uncover any race. How does > this version look? This looks good to me. One nit that caused me some confusion - it took me a while to realize that in transitionTo eg: 221 public void transitionTo(Thread.State tstate) throws InterruptedException { 222 switch (tstate) { 223 case RUNNABLE: 224 nextState(RUNNABLE); 225 break; The case value, eg RUNNABLE, and the arg to nextState, eg RUNNABLE, are two completely different values! Can I suggest using S_xxx for the int states (why not an enum?). Typo: awaitArrive should be awaitAdvance Thanks, David > Mandy > > On 10/31/2013 5:38 PM, David Holmes wrote: >> Hi Mandy, >> >> On 1/11/2013 5:11 AM, Mandy Chung wrote: >>> Updated webrev that has a new >>> test/lib/testlibrary/ThreadStateController.java and also change to use >>> AtomicInteger: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ >> >> Sorry but I don't see how this works - and that applies to the old >> version too! (Which I know I've looked at before so this is somewhat >> unsettling for me :( ). >> >> First I found it confusing to track which thread was which in the >> refactoring (which in itself is a good idea). Inside >> ThreadStateController "myThread" doesn't mean anything - that comes >> from the calling context - I suggest changing to refer to "this >> thread" or "the current thread" as appropriate. eg "Have the current >> thread wait until this thread is about to block" or whatever is needed. >> >> Looking at an actual test we have eg: >> >> myThread.goWaiting(); >> ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); >> >> First: why is checkThreadState static rather than just an instance >> method? >> > > I'm happy with the new version of ThreadStateController.java with the > above cleanup. > >> So goWaiting is supposed to tell myThread to go to a "waiting" state >> so that the main thread can then verify that. Lets assume for >> arguments sake that the thread is currently RUNNABLE so it is >> currently looping around in run() doing the little math exercise. >> goWaiting does: >> >> public void goWaiting() { >> System.out.println("Waiting myThread to go waiting."); >> setState(WAITING); >> // wait for MyThread to get to just before wait on object. >> phaser.arriveAndAwaitAdvance(); >> } >> >> and setState does: >> >> case WAITING: >> case TIMED_WAITING: >> state = newState; >> synchronized (lock) { >> lock.notify(); >> } >> break; > > The switch statement is looking at the current state (i.e. RUNNABLE). > > The above WAITING and TIMED_WAITING cases indicate that this thread is > in waiting and thus the request to transition to another state has first > to notify this thread so that it can proceed with the state transition. > > >> >> >> so as soon as we update "state" myThread is capable of changing what >> it is doing in run() to: >> >> case WAITING: { >> synchronized (lock) { >> // signal main thread. >> phaser.arrive(); >> System.out.println(" myThread is going to wait."); >> try { >> lock.wait(); >> } catch (InterruptedException e) { >> // ignore >> interrupted.incrementAndGet(); >> } >> } >> break; >> >> so now we have a race between the two threads to see who can grab the >> lock first. If it is the main thread then we issue a notify when >> nothing is waiting and so the subsequent wait() by myThread will >> potentially wait forever. At least in that case the main thread will >> see that it is waiting! >> > > If this thread is currently in WAITING state, the main thread calls > goTimedWaiting, before it notifies this thread, this thread gets waken > up due to spurious wakeup or interrupt, then the race depending on who > grabs the lock first as you described above will happen. > >> If "myThread" wins the race it will wait after signalling the phaser >> and the main thread will then issue the notify allowing myThread to >> proceed (and do what? process the WAITING case again??). So there is >> no guarantee that myThread will be waiting when the main thread checks >> the state! >> >> Similarly for issuing the unpark in the parking cases. >> >> AFAICS the basic approach here should be: >> - tell myThread to go to state X >> - wait until myThread should be in state X >> - verify myThread is in state X > > That's what the test does. > >> - allow myThread to escape from state X > > Is this really needed? This would require the main thread to notify > myThread the verification is done. The test currently goes to the new > state for validation and it seems to me that this isn't needed. > > Mandy From sundararajan.athijegannathan at oracle.com Tue Nov 5 04:39:17 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 05 Nov 2013 04:39:17 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20131105043919.E62D762A4D@hg.openjdk.java.net> Changeset: dcedc753fd09 Author: sundar Date: 2013-11-04 18:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dcedc753fd09 8027753: Support ScriptObject to JSObject, ScriptObjectMirror, Map, Bindings auto-conversion as well as explicit wrap, unwrap Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java + test/script/basic/JDK-8027753.js + test/script/basic/JDK-8027753.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java Changeset: b0d4ef6fb2db Author: sundar Date: 2013-11-05 09:13 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b0d4ef6fb2db Merge From peter.levart at gmail.com Tue Nov 5 07:26:41 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Nov 2013 08:26:41 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278562A.90209@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> Message-ID: <52789DB1.2090604@gmail.com> 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 >> accessed within a locked region. Also awaitBooted might as well be >> void as it can only ever return true. >> > > Fixed. Revised webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ Hi Mandy, Just a nit. You are assigning SharedSecrets.getJavaLangAccess() to a local 'jla' variable declared outside Runnables, which makes it effectively a final field. You could declare and assign the 'jla' inside run() methods of both Runnables, just before the loop - like it is done in the FinalizerThread... Regards, Peter P.S. I'm curious about the strange seemingly unneeded code fragments in FinalizerThread and both Runnables. For example: 169 forkSecondaryFinalizer(new Runnable() { 170*private volatile boolean running;* 171 public void run() { 172*if (running)* 173*return;* 174*running = true;* The FinalizerThread and each Runnable instance is only executed once. Why these checks then? Does anybody know? Regards, Peter > > Thanks for the review. > Mandy > >> Thanks, >> David >> >> On 5/11/2013 6:04 AM, Mandy Chung wrote: >>> Thank you all for the suggestions. >>> >>> Before the VM initialization is completed, any agent ought to be >>> careful >>> in what things it can do and what shouldn't do. I think it's >>> reasonable >>> to ignore System.runFinalization if it's called at early startup phase. >>> I'm unclear if there is any use case that we really require >>> finalization >>> to happen before VM is booted (I can imagine other problems may >>> happen). >>> I change the runFinalization and runAllFinalizers methods to return if >>> it's not booted and also change runFinalizer method to take >>> JavaLangAccess to simplify the synchronization instead of caching it in >>> the static field. >>> >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.02/ >>> >>> David - I decided to leave VM.awaitBooted as it is. Having the >>> callsite >>> to call awaitBooted makes it explicit and clear that it's blocking and >>> we will keep SharedSecrets.getJavaLangAccess method consistent with the >>> other SharedSecrets methods that they are all getter methods. If any >>> future change calls SharedSecrets.getJavaLangAccess before it's booted, >>> it's a little easier to diagnose (NPE vs hangs). >>> >>> Peter - thanks for the ObjectAccess idea. I don't think supporting >>> finalization to happen before VM is booted buys us anything and I would >>> rather keep this change simple. >>> >>> Mandy > From peter.levart at gmail.com Tue Nov 5 08:25:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Nov 2013 09:25:57 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <20131104181255.459946297B@hg.openjdk.java.net> References: <20131104181255.459946297B@hg.openjdk.java.net> Message-ID: <5278AB95.6000707@gmail.com> 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 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 accessor: - for classic declaring class - as is / unchanged - for anonymous declaring class - just create and return NativeMethodAccessorImpl without a parent Then in NativeMethodAccessorImpl (and same for constructor), modify the inflation checking logic: if (*parent != null && *++numInvocations > ReflectionFactory.inflationThreshold()) { MethodAccessorImpl acc = (MethodAccessorImpl) new MethodAccessorGenerator(). generateMethod(method.getDeclaringClass(), method.getName(), method.getParameterTypes(), method.getReturnType(), method.getExceptionTypes(), method.getModifiers()); parent.setDelegate(acc); } Regards, Peter On 11/04/2013 07:12 PM, robert.field at 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 serialization fails once reflection proxy generation kicks in > Reviewed-by: ksrini, briangoetz, jfranck > Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com > > ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java > ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java > ! src/share/classes/sun/reflect/misc/ReflectUtil.java > + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java > ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java > + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java > From Alan.Bateman at oracle.com Tue Nov 5 08:36:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 08:36:08 +0000 Subject: RFR: 8024876 : [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions In-Reply-To: <52782097.4000304@oracle.com> References: <5272B564.5080308@oracle.com> <52775D16.6050008@oracle.com> <52782097.4000304@oracle.com> Message-ID: <5278ADF8.9000206@oracle.com> On 04/11/2013 22:32, huizhe wang wrote: > : > > It's closed, but outFilename was not. Since the behaviors are > different among parsers, I've added them all in a try-with-resources > statement. > > Please review: > http://cr.openjdk.java.net/~joehw/jdk8/8024876/webrev/ Thanks, that makes it clear. (I see that 8024876 has already been pushed so this update will need a new bug). -Alan. From paul.sandoz at oracle.com Tue Nov 5 08:52:28 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Nov 2013 09:52:28 +0100 Subject: RFR: JDK-8027796: Refactor Core Reflection for Type Annotations In-Reply-To: <81B30411-8BD8-4A5A-BA97-C9A8D172DC3C@oracle.com> References: <81B30411-8BD8-4A5A-BA97-C9A8D172DC3C@oracle.com> Message-ID: <57FC26A3-2AFD-4F15-A912-AE3521F2D812@oracle.com> On Nov 4, 2013, at 8:36 PM, Joel Borggr?n-Franck wrote: > Hi > > Please review this small refactoring of the type annotations reflection code. This fix just makes the types final since the code wasn't designed for inheritance. > > webrev: http://cr.openjdk.java.net/~jfranck/8027796/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8027796 > +1 FWIW (take it or leave it) the "final" on AnnotatedTypeFactory.buildAnnotatedType is redundant since AnnotatedTypeFactory is final and thus cannot be overridden with another class that shadows the static method. Paul. From peter.levart at gmail.com Tue Nov 5 08:55:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Nov 2013 09:55:24 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <20131104181255.459946297B@hg.openjdk.java.net> References: <20131104181255.459946297B@hg.openjdk.java.net> Message-ID: <5278B27C.30303@gmail.com> On 11/04/2013 07:12 PM, robert.field at 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 serialization fails once reflection proxy generation kicks in > Reviewed-by: ksrini, briangoetz, jfranck > Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com > > ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java > ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java > ! src/share/classes/sun/reflect/misc/ReflectUtil.java > + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java > ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java > + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java > Hi Robert, I also propose a much faster variant of: + /** + * Checks if {@code Class cls} is a VM-anonymous class + * as defined by {@link sun.misc.Unsafe#defineAnonymousClass} + * (not to be confused with a Java Language anonymous inner class). + */ + public static boolean isVMAnonymousClass(Class cls) { + return cls.getSimpleName().contains("/"); + } The following: public static boolean isVMAnonymousClassFAST(Class cls) { String name = cls.getName(); for (int i = name.length() - 1; i >= 0; i--) { char c = name.charAt(i); if (c == '.') return false; if (c == '/') return true; } return false; // root package } It's about 12..25x faster for typical class names and doesn't produce any garbage. Regards, Peter From konstantin.shefov at oracle.com Tue Nov 5 09:10:22 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Tue, 05 Nov 2013 09:10:22 +0000 Subject: hg: jdk8/tl/nashorn: 8027708: NASHORN TEST: Create Nashorn test that draws image step-by-step using JavaFX canvas. Message-ID: <20131105091023.DAE5162A58@hg.openjdk.java.net> Changeset: bda654c6d59c Author: kshefov Date: 2013-11-05 13:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bda654c6d59c 8027708: NASHORN TEST: Create Nashorn test that draws image step-by-step using JavaFX canvas. Reviewed-by: jlaskey, lagergren ! make/build.xml ! make/project.properties ! test/script/jfx.js ! test/script/jfx/flyingimage.js ! test/script/jfx/flyingimage/flyingimage.png ! test/script/jfx/flyingimage/golden/linux.png ! test/script/jfx/flyingimage/golden/macosx.png ! test/script/jfx/flyingimage/golden/windows.png ! test/script/jfx/kaleidoscope.js ! test/script/jfx/kaleidoscope/golden/linux.png ! test/script/jfx/kaleidoscope/golden/macosx.png ! test/script/jfx/kaleidoscope/golden/windows.png + test/script/jfx/spread.js + test/script/jfx/spread/golden/linux.png + test/script/jfx/spread/golden/macosx.png + test/script/jfx/spread/golden/windows.png From brian.goetz at oracle.com Tue Nov 5 09:10:23 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 5 Nov 2013 09:10:23 +0000 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5278B27C.30303@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> Message-ID: <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> Ineexof(char) sounds like as fast and simpler? Sent from my iPhone On Nov 5, 2013, at 8:55 AM, Peter Levart wrote: > On 11/04/2013 07:12 PM, robert.field at 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 serialization fails once reflection proxy generation kicks in >> Reviewed-by: ksrini, briangoetz, jfranck >> Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com >> >> ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java >> ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java >> ! src/share/classes/sun/reflect/misc/ReflectUtil.java >> + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java >> ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java >> + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java >> > Hi Robert, > > I also propose a much faster variant of: > > + /** > + * Checks if {@code Class cls} is a VM-anonymous class > + * as defined by {@link sun.misc.Unsafe#defineAnonymousClass} > + * (not to be confused with a Java Language anonymous inner class). > + */ > + public static boolean isVMAnonymousClass(Class cls) { > + return cls.getSimpleName().contains("/"); > + } > > > The following: > > public static boolean isVMAnonymousClassFAST(Class cls) { > String name = cls.getName(); > for (int i = name.length() - 1; i >= 0; i--) { > char c = name.charAt(i); > if (c == '.') return false; > if (c == '/') return true; > } > return false; // root package > } > > It's about 12..25x faster for typical class names and doesn't produce any garbage. > > > Regards, Peter > From paul.sandoz at oracle.com Tue Nov 5 09:11:35 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Nov 2013 10:11:35 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278562A.90209@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> Message-ID: <6DD23F9D-4EA7-4844-8D53-17F7BFF57A33@oracle.com> On Nov 5, 2013, at 3:21 AM, Mandy Chung wrote: >> 2. In VM.java. booted need not be volatile now that it is only accessed within a locked region. Also awaitBooted might as well be void as it can only ever return true. >> > > Fixed. Revised webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ > The booted field is also accessed directly from within other areas of the VM class e.g.: 272 // This method can only be invoked during system initialization. 273 public static void saveAndRemoveProperties(Properties props) { 274 if (booted) 275 throw new IllegalStateException("System initialization has completed"); 323 public static void initializeOSEnvironment() { 324 if (!booted) { 325 OSEnvironment.initialize(); 326 } 327 } Paul. From amy.lu at oracle.com Tue Nov 5 09:26:49 2013 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 05 Nov 2013 17:26:49 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) Message-ID: <5278B9D9.8010505@oracle.com> Following bugs have been fixed, related tests should be removed from ProblemList: 8021230 (CODETOOLS-7900208 has been promoted in jtreg 4.1 b07) java/lang/ThreadLocal/ThreadLocalSupplierTest.java generic-all JDK-8026502 java/lang/invoke/MethodHandleConstants.java generic-all JDK-8014719 sun/net/www/http/HttpClient/ProxyTest.java generic-all JDK-8009438 sun/security/pkcs11/Secmod/AddPrivateKey.java linux-all sun/security/pkcs11/Secmod/TrustAnchors.java linux-all JDK-8026772 sun/util/resources/TimeZone/Bug6317929.java generic-all Please review ProblemList.txt changes: https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html Thanks, Amy From peter.levart at gmail.com Tue Nov 5 09:28:31 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Nov 2013 10:28:31 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5278B27C.30303@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> Message-ID: <5278BA3F.3070602@gmail.com> Hi John, Speaking of names, the following test: package pkg; public class Test { public static void main(String[] args) { Runnable r = () -> {}; Class c = r.getClass(); Class ac = java.lang.reflect.Array.newInstance(c, 0).getClass(); System.out.println("c: " + c.getName() + " / " + c.getSimpleName()); System.out.println("ac: " + ac.getName() + " / " + ac.getSimpleName()); } } Prints: c: pkg.Test$$Lambda$1/798154996 / Test$$Lambda$1/798154996 ac: [Lpkg.Test$$Lambda$1; / Test$$Lambda$1/798154996[] I think the array class name is missing 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.field at 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 serialization fails once reflection proxy generation kicks in >> Reviewed-by: ksrini, briangoetz, jfranck >> Contributed-by:joel.franck at oracle.com,brian.goetz at oracle.com,robert.field at oracle.com >> >> ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java >> ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java >> ! src/share/classes/sun/reflect/misc/ReflectUtil.java >> + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java >> ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java >> + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java >> > Hi Robert, > > I also propose a much faster variant of: > > + /** > + * Checks if {@code Class cls} is a VM-anonymous class > + * as defined by {@link sun.misc.Unsafe#defineAnonymousClass} > + * (not to be confused with a Java Language anonymous inner class). > + */ > + public static boolean isVMAnonymousClass(Class cls) { > + return cls.getSimpleName().contains("/"); > + } > > > The following: > > public static boolean isVMAnonymousClassFAST(Class cls) { > String name = cls.getName(); > for (int i = name.length() - 1; i >= 0; i--) { > char c = name.charAt(i); > if (c == '.') return false; > if (c == '/') return true; > } > return false; // root package > } > > It's about 12..25x faster for typical class names and doesn't produce > any garbage. > > > Regards, Peter > From joel.franck at oracle.com Tue Nov 5 09:33:10 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 5 Nov 2013 10:33:10 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5278AB95.6000707@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278AB95.6000707@gmail.com> Message-ID: <167F01C3-5C73-470A-8E13-128DA317A9F0@oracle.com> Hi Peter, Narrowing this to core-libs-dev. On 5 nov 2013, at 09:25, Peter Levart wrote: > 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). > Thanks for catching this. > 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 accessor: > > - for classic declaring class - as is / unchanged > - for anonymous declaring class - just create and return NativeMethodAccessorImpl without a parent > > Then in NativeMethodAccessorImpl (and same for constructor), modify the inflation checking logic: > > if (parent != null && ++numInvocations > ReflectionFactory.inflationThreshold()) { > MethodAccessorImpl acc = (MethodAccessorImpl) > new MethodAccessorGenerator(). > generateMethod(method.getDeclaringClass(), > method.getName(), > method.getParameterTypes(), > method.getReturnType(), > method.getExceptionTypes(), > method.getModifiers()); > parent.setDelegate(acc); > } I don't like adding even more special cases to this check. IMHO a better way that we discussed and rejected, opting for a smaller change, is to create a NonInflatingMethodAccessor and just drop in one of those without a delegate for when creating the accessor for methods/ctors on anonymous classes. cheers /Joel From peter.levart at gmail.com Tue Nov 5 09:51:03 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Nov 2013 10:51:03 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <167F01C3-5C73-470A-8E13-128DA317A9F0@oracle.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278AB95.6000707@gmail.com> <167F01C3-5C73-470A-8E13-128DA317A9F0@oracle.com> Message-ID: <5278BF87.5020501@gmail.com> 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 accessor: >> > >> >- for classic declaring class - as is / unchanged >> >- for anonymous declaring class - just create and return NativeMethodAccessorImpl without a parent >> > >> >Then in NativeMethodAccessorImpl (and same for constructor), modify the inflation checking logic: >> > >> > if (parent != null && ++numInvocations > ReflectionFactory.inflationThreshold()) { >> > MethodAccessorImpl acc = (MethodAccessorImpl) >> > new MethodAccessorGenerator(). >> > generateMethod(method.getDeclaringClass(), >> > method.getName(), >> > method.getParameterTypes(), >> > method.getReturnType(), >> > method.getExceptionTypes(), >> > method.getModifiers()); >> > parent.setDelegate(acc); >> > } > I don't like adding even more special cases to this check. IMHO a better way that we discussed and rejected, opting for a smaller change, is to create a NonInflatingMethodAccessor and just drop in one of those without a delegate for when creating the accessor for methods/ctors on anonymous classes. Even better. I would name the new class NativeMethodAccessorImpl and the one doing inflation InflatingNativeMethodAccessorImpl which would extend NativeMethodAccessorImpl, override invoke() and call super.invoke()... This way, no native methods duplication is needed. invoke() is already an interface method with 2 implementations. Now it will have 3. Does this present any difference for dispatch optimization? Regards, Peter > > cheers > /Joel From chris.hegarty at oracle.com Tue Nov 5 10:01:36 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Nov 2013 10:01:36 +0000 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5278B9D9.8010505@oracle.com> References: <5278B9D9.8010505@oracle.com> Message-ID: <5278C200.4010802@oracle.com> Thanks Amy, The updates look good to me. Just to confirm, have you verified that the tests actually pass now? -Chris. On 05/11/2013 09:26, Amy Lu wrote: > Following bugs have been fixed, related tests should be removed from > ProblemList: > > 8021230 (CODETOOLS-7900208 > has been > promoted in jtreg 4.1 b07) > java/lang/ThreadLocal/ThreadLocalSupplierTest.java generic-all > > JDK-8026502 > java/lang/invoke/MethodHandleConstants.java generic-all > > JDK-8014719 > sun/net/www/http/HttpClient/ProxyTest.java generic-all > > JDK-8009438 > sun/security/pkcs11/Secmod/AddPrivateKey.java linux-all > sun/security/pkcs11/Secmod/TrustAnchors.java linux-all > > JDK-8026772 > sun/util/resources/TimeZone/Bug6317929.java generic-all > > > Please review ProblemList.txt changes: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html > > > Thanks, > Amy From Alan.Bateman at oracle.com Tue Nov 5 10:01:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 10:01:08 +0000 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5278B9D9.8010505@oracle.com> References: <5278B9D9.8010505@oracle.com> Message-ID: <5278C1E4.2070002@oracle.com> On 05/11/2013 09:26, Amy Lu wrote: > : > > Please review ProblemList.txt changes: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html > This looks okay to me although I'm not sure about sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej fixed the test and also excluded it, pending a decision/discussion on whether this test should be removed). Should we use the opportunity to add all the tests that are failing due to the exact math intrinsic (JDK-8027622)? -Alan. From Alan.Bateman at oracle.com Tue Nov 5 10:11:13 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 10:11:13 +0000 Subject: RFR 8027712 DistinctOpTest fails for unordered test In-Reply-To: References: Message-ID: <5278C441.4080103@oracle.com> On 01/11/2013 17:57, Paul Sandoz wrote: > Hi, > > This is a "eating humble pie and should of correctly listened to Henry in review" kind of email :-) > > The changes to DistinctOpTest recently committed result in a test failure, since one of the tests is incorrectly asserting on a particular element, which is non-determinisitic process [*]. > > See below for a patch that fixes the test. This looks okay to me too. It might be worth running all these tests with parallelism set to 0 in case anything else shows up. -Alan From joel.franck at oracle.com Tue Nov 5 10:11:49 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 5 Nov 2013 11:11:49 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5278BF87.5020501@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278AB95.6000707@gmail.com> <167F01C3-5C73-470A-8E13-128DA317A9F0@oracle.com> <5278BF87.5020501@gmail.com> Message-ID: <029C8D69-1223-45A3-A793-53009B2E279D@oracle.com> On 5 nov 2013, at 10:51, Peter Levart wrote: > 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 accessor: >>> > >>> >- for classic declaring class - as is / unchanged >>> >- for anonymous declaring class - just create and return NativeMethodAccessorImpl without a parent >>> > >>> >Then in NativeMethodAccessorImpl (and same for constructor), modify the inflation checking logic: >>> > >>> > if (parent != null && ++numInvocations > ReflectionFactory.inflationThreshold()) { >>> > MethodAccessorImpl acc = (MethodAccessorImpl) >>> > new MethodAccessorGenerator(). >>> > generateMethod(method.getDeclaringClass(), >>> > method.getName(), >>> > method.getParameterTypes(), >>> > method.getReturnType(), >>> > method.getExceptionTypes(), >>> > method.getModifiers()); >>> > parent.setDelegate(acc); >>> > } >> I don't like adding even more special cases to this check. IMHO a better way that we discussed and rejected, opting for a smaller change, is to create a NonInflatingMethodAccessor and just drop in one of those without a delegate for when creating the accessor for methods/ctors on anonymous classes. > > Even better. I would name the new class NativeMethodAccessorImpl and the one doing inflation InflatingNativeMethodAccessorImpl which would extend NativeMethodAccessorImpl, override invoke() and call super.invoke()... This way, no native methods duplication is needed. invoke() is already an interface method with 2 implementations. Now it will have 3. Does this present any difference for dispatch optimization? > FWIW i think the magic number is 4, but I don't know where I got that. Anyhow, this might be slightly controversial, but for all code I care about (reflective invocation of methods/ctors on non-VM-anonymous classes) the check happens exactly once as is. I think this should be good enough (but we seem to have other issues with noInflation=true) because the test crashes: diff -r 51b002381b35 src/share/classes/sun/reflect/ReflectionFactory.java --- a/src/share/classes/sun/reflect/ReflectionFactory.java Mon Nov 04 10:12:18 2013 -0800 +++ b/src/share/classes/sun/reflect/ReflectionFactory.java Tue Nov 05 11:07:53 2013 +0100 @@ -33,6 +33,7 @@ import java.security.AccessController; import java.security.Permission; import java.security.PrivilegedAction; +import sun.reflect.misc.ReflectUtil; /**

The master factory for all reflective objects, both those in java.lang.reflect (Fields, Methods, Constructors) as well as their @@ -144,7 +145,7 @@ public MethodAccessor newMethodAccessor(Method method) { checkInitted(); - if (noInflation) { + if (noInflation && !ReflectUtil.isVMAnonymousClass(method.getDeclaringClass())) { return new MethodAccessorGenerator(). generateMethod(method.getDeclaringClass(), method.getName(), @@ -181,7 +182,7 @@ return new BootstrapConstructorAccessorImpl(c); } - if (noInflation) { + if (noInflation && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())) { return new MethodAccessorGenerator(). generateConstructor(c.getDeclaringClass(), c.getParameterTypes(), diff -r 51b002381b35 test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java --- a/test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java Mon Nov 04 10:12:18 2013 -0800 +++ b/test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java Tue Nov 05 11:07:53 2013 +0100 @@ -27,6 +27,7 @@ * @summary Lambda serialization fails once reflection proxy generation kicks in * @author Robert Field * @run main/othervm RepetitiveLambdaSerialization + * @run main/othervm -Dsun.reflect.noInflation=true RepetitiveLambdaSerialization */ import java.io.*; diff -r 51b002381b35 test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java --- a/test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java Mon Nov 04 10:12:18 2013 -0800 +++ b/test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java Tue Nov 05 11:07:53 2013 +0100 @@ -30,6 +30,7 @@ * @compile -XDignore.symbol.file ManyNewInstanceAnonTest.java * @run main ClassFileInstaller ManyNewInstanceAnonTest * @run main/othervm -Xbootclasspath/a:. -Xverify:all ManyNewInstanceAnonTest + * @run main/othervm -Xbootclasspath/a:. -Xverify:all -Dsun.reflection.noInflation=true ManyNewInstanceAnonTest */ import java.io.ByteArrayOutputStream; import java.io.InputStream; cheers /Joel From chris.hegarty at oracle.com Tue Nov 5 10:23:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Nov 2013 10:23:09 +0000 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <52786415.7090205@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> <52786415.7090205@oracle.com> Message-ID: <5278C70D.8030207@oracle.com> On 05/11/2013 03:20, Mandy Chung wrote: > David, > > Rereading your comment and I think you misread the switch statement (see > my comments below). In any case, I revisited ThreadStateController.java > and looked int the potential races and have done further cleanup. Here > is the updated webrev. > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.02/ The latest webrev looks good to me. As the last person to touch java/lang/Thread/ThreadStateTest.java, retrofitting it with Phaser. I can only apologize for not updating java/lang/management/ThreadMXBean/ThreadStateTest.java then. Thanks for doing this now, as part of this bug. -Chris. > > I'll let them run longer to see if it can uncover any race. How does > this version look? > > Mandy > > On 10/31/2013 5:38 PM, David Holmes wrote: >> Hi Mandy, >> >> On 1/11/2013 5:11 AM, Mandy Chung wrote: >>> Updated webrev that has a new >>> test/lib/testlibrary/ThreadStateController.java and also change to use >>> AtomicInteger: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ >> >> Sorry but I don't see how this works - and that applies to the old >> version too! (Which I know I've looked at before so this is somewhat >> unsettling for me :( ). >> >> First I found it confusing to track which thread was which in the >> refactoring (which in itself is a good idea). Inside >> ThreadStateController "myThread" doesn't mean anything - that comes >> from the calling context - I suggest changing to refer to "this >> thread" or "the current thread" as appropriate. eg "Have the current >> thread wait until this thread is about to block" or whatever is needed. >> >> Looking at an actual test we have eg: >> >> myThread.goWaiting(); >> ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); >> >> First: why is checkThreadState static rather than just an instance >> method? >> > > I'm happy with the new version of ThreadStateController.java with the > above cleanup. > >> So goWaiting is supposed to tell myThread to go to a "waiting" state >> so that the main thread can then verify that. Lets assume for >> arguments sake that the thread is currently RUNNABLE so it is >> currently looping around in run() doing the little math exercise. >> goWaiting does: >> >> public void goWaiting() { >> System.out.println("Waiting myThread to go waiting."); >> setState(WAITING); >> // wait for MyThread to get to just before wait on object. >> phaser.arriveAndAwaitAdvance(); >> } >> >> and setState does: >> >> case WAITING: >> case TIMED_WAITING: >> state = newState; >> synchronized (lock) { >> lock.notify(); >> } >> break; > > The switch statement is looking at the current state (i.e. RUNNABLE). > > The above WAITING and TIMED_WAITING cases indicate that this thread is > in waiting and thus the request to transition to another state has first > to notify this thread so that it can proceed with the state transition. > > >> >> >> so as soon as we update "state" myThread is capable of changing what >> it is doing in run() to: >> >> case WAITING: { >> synchronized (lock) { >> // signal main thread. >> phaser.arrive(); >> System.out.println(" myThread is going to wait."); >> try { >> lock.wait(); >> } catch (InterruptedException e) { >> // ignore >> interrupted.incrementAndGet(); >> } >> } >> break; >> >> so now we have a race between the two threads to see who can grab the >> lock first. If it is the main thread then we issue a notify when >> nothing is waiting and so the subsequent wait() by myThread will >> potentially wait forever. At least in that case the main thread will >> see that it is waiting! >> > > If this thread is currently in WAITING state, the main thread calls > goTimedWaiting, before it notifies this thread, this thread gets waken > up due to spurious wakeup or interrupt, then the race depending on who > grabs the lock first as you described above will happen. > >> If "myThread" wins the race it will wait after signalling the phaser >> and the main thread will then issue the notify allowing myThread to >> proceed (and do what? process the WAITING case again??). So there is >> no guarantee that myThread will be waiting when the main thread checks >> the state! >> >> Similarly for issuing the unpark in the parking cases. >> >> AFAICS the basic approach here should be: >> - tell myThread to go to state X >> - wait until myThread should be in state X >> - verify myThread is in state X > > That's what the test does. > >> - allow myThread to escape from state X > > Is this really needed? This would require the main thread to notify > myThread the verification is done. The test currently goes to the new > state for validation and it seems to me that this isn't needed. > > Mandy From Alan.Bateman at oracle.com Tue Nov 5 10:38:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 10:38:29 +0000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278562A.90209@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> Message-ID: <5278CAA5.5000608@oracle.com> On 05/11/2013 02:21, Mandy Chung wrote: > > Fixed. Revised webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ > I looked at the latest webrev. Having runFinalization and runAllFinalizers be a no-open during initialization is reasonable (it should never happen). I agree with Peter's suggestion to move the SharedSecrets.getJavaLangAccess() into the run methods. As regards the booted flag then there are a few places where VM.isBooted is used so it be better to leave it as volatile (it's only used in a few places to having it synchronized is unlikely to make an observable difference). -Alan. From paul.sandoz at oracle.com Tue Nov 5 10:59:50 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Nov 2013 11:59:50 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52789DB1.2090604@gmail.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <52789DB1.2090604@gmail.com> Message-ID: On Nov 5, 2013, at 8:26 AM, Peter Levart wrote: > > P.S. I'm curious about the strange seemingly unneeded code fragments in FinalizerThread and both Runnables. For example: > > 169 forkSecondaryFinalizer(new Runnable() { > 170*private volatile boolean running;* > 171 public void run() { > 172*if (running)* > 173*return;* > 174*running = true;* > > The FinalizerThread and each Runnable instance is only executed once. Why these checks then? Does anybody know? > I was wondering that too. A Thread is an instance of Runnable. So a finalize method could re-exec the current finalizer thread on another another thread. Paul. From paul.sandoz at oracle.com Tue Nov 5 11:03:02 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 5 Nov 2013 12:03:02 +0100 Subject: RFR 8027712 DistinctOpTest fails for unordered test In-Reply-To: <5278C441.4080103@oracle.com> References: <5278C441.4080103@oracle.com> Message-ID: <8C03469E-61D3-46ED-92D5-3A4DEA93F916@oracle.com> On Nov 5, 2013, at 11:11 AM, Alan Bateman wrote: > On 01/11/2013 17:57, Paul Sandoz wrote: >> Hi, >> >> This is a "eating humble pie and should of correctly listened to Henry in review" kind of email :-) >> >> The changes to DistinctOpTest recently committed result in a test failure, since one of the tests is incorrectly asserting on a particular element, which is non-determinisitic process [*]. >> >> See below for a patch that fixes the test. > This looks okay to me too. Thanks. > It might be worth running all these tests with parallelism set to 0 in case anything else shows up. > Yes, i did that (it was how i verified my assumptions in the footnote). In general we need to ensure out test infrastructure going forward has at least one machine that has or is configured to have just one hardware thread active. Paul. From amy.lu at oracle.com Tue Nov 5 11:09:34 2013 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 05 Nov 2013 19:09:34 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5278C1E4.2070002@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> Message-ID: <5278D1EE.60404@oracle.com> On 11/5/13 6:01 PM, Alan Bateman wrote: > On 05/11/2013 09:26, Amy Lu wrote: >> : >> >> Please review ProblemList.txt changes: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >> > This looks okay to me although I'm not sure about > sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej > fixed the test and also excluded it, pending a decision/discussion on > whether this test should be removed). > > Should we use the opportunity to add all the tests that are failing > due to the exact math intrinsic (JDK-8027622)? > > -Alan. Added 8027622 and affected tests into ProblemList: https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html Thanks, Amy From paul.sandoz at oracle.com Tue Nov 5 11:09:13 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 05 Nov 2013 11:09:13 +0000 Subject: hg: jdk8/tl/jdk: 8027712: DistinctOpTest fails for unordered test Message-ID: <20131105111041.08F5862A5C@hg.openjdk.java.net> Changeset: d5b3f83ffc40 Author: psandoz Date: 2013-11-05 12:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5b3f83ffc40 8027712: DistinctOpTest fails for unordered test Reviewed-by: henryjen, alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java From amy.lu at oracle.com Tue Nov 5 11:11:37 2013 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 05 Nov 2013 19:11:37 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5278C200.4010802@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C200.4010802@oracle.com> Message-ID: <5278D269.9090305@oracle.com> On 11/5/13 6:01 PM, Chris Hegarty wrote: > Thanks Amy, > > The updates look good to me. Just to confirm, have you verified that > the tests actually pass now? Yes, I tried them on one linux (as they are generic-all or linux-all) and test PASS. Thanks, Amy > > -Chris. > > On 05/11/2013 09:26, Amy Lu wrote: >> Following bugs have been fixed, related tests should be removed from >> ProblemList: >> >> 8021230 (CODETOOLS-7900208 >> has been >> promoted in jtreg 4.1 b07) >> java/lang/ThreadLocal/ThreadLocalSupplierTest.java generic-all >> >> JDK-8026502 >> java/lang/invoke/MethodHandleConstants.java generic-all >> >> JDK-8014719 >> sun/net/www/http/HttpClient/ProxyTest.java generic-all >> >> JDK-8009438 >> sun/security/pkcs11/Secmod/AddPrivateKey.java linux-all >> sun/security/pkcs11/Secmod/TrustAnchors.java linux-all >> >> JDK-8026772 >> sun/util/resources/TimeZone/Bug6317929.java generic-all >> >> >> Please review ProblemList.txt changes: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >> >> >> >> Thanks, >> Amy From chris.hegarty at oracle.com Tue Nov 5 11:33:34 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Nov 2013 11:33:34 +0000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <52789DB1.2090604@gmail.com> Message-ID: <5278D78E.9080105@oracle.com> On 05/11/2013 10:59, Paul Sandoz wrote: > On Nov 5, 2013, at 8:26 AM, Peter Levart wrote: >> >> P.S. I'm curious about the strange seemingly unneeded code fragments in FinalizerThread and both Runnables. For example: >> >> 169 forkSecondaryFinalizer(new Runnable() { >> 170*private volatile boolean running;* >> 171 public void run() { >> 172*if (running)* >> 173*return;* >> 174*running = true;* >> >> The FinalizerThread and each Runnable instance is only executed once. Why these checks then? Does anybody know? >> > > I was wondering that too. A Thread is an instance of Runnable. So a finalize method could re-exec the current finalizer thread on another another thread. Right. I added these a while back to ensure that this does not happen. -Chris. > > Paul. From chris.hegarty at oracle.com Tue Nov 5 12:05:03 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Nov 2013 12:05:03 +0000 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5278D1EE.60404@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> Message-ID: <5278DEEF.3010907@oracle.com> Thanks Amy, I can sponsor this change for you. -Chris. On 05/11/2013 11:09, Amy Lu wrote: > On 11/5/13 6:01 PM, Alan Bateman wrote: >> On 05/11/2013 09:26, Amy Lu wrote: >>> : >>> >>> Please review ProblemList.txt changes: >>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>> >> This looks okay to me although I'm not sure about >> sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej >> fixed the test and also excluded it, pending a decision/discussion on >> whether this test should be removed). >> >> Should we use the opportunity to add all the tests that are failing >> due to the exact math intrinsic (JDK-8027622)? >> >> -Alan. > > Added 8027622 and affected tests into ProblemList: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html > > > Thanks, > Amy From peter.levart at gmail.com Tue Nov 5 13:14:06 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 05 Nov 2013 14:14:06 +0100 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278D78E.9080105@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <52789DB1.2090604@gmail.com> <5278D78E.9080105@oracle.com> Message-ID: <5278EF1E.3010301@gmail.com> 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 Levart wrote: >>> >>> P.S. I'm curious about the strange seemingly unneeded code fragments >>> in FinalizerThread and both Runnables. For example: >>> >>> 169 forkSecondaryFinalizer(new Runnable() { >>> 170*private volatile boolean running;* >>> 171 public void run() { >>> 172*if (running)* >>> 173*return;* >>> 174*running = true;* >>> >>> The FinalizerThread and each Runnable instance is only executed >>> once. Why these checks then? Does anybody know? >>> >> >> I was wondering that too. A Thread is an instance of Runnable. So a >> finalize method could re-exec the current finalizer thread on another >> another thread. > > Right. I added these a while back to ensure that this does not happen. > > -Chris. That's really mean 8-) Peter > >> >> Paul. From Sergey.Bylokhov at oracle.com Tue Nov 5 16:28:03 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 05 Nov 2013 20:28:03 +0400 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <5274E3FF.3070807@oracle.com> References: <52738E00.2070806@oracle.com> <5274E3FF.3070807@oracle.com> Message-ID: <52791C93.1060600@oracle.com> Hello, Updated version: http://cr.openjdk.java.net/~serb/8027696/webrev.01/ Dates and spaces were fixed. On 02.11.2013 15:37, Alan Bateman wrote: > On 01/11/2013 11:18, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 8. >> Most of tests in the sound area, and some tests in the client, >> java.lang, security, jmx etc has incorrect copyright. >> According to the http://openjdk.java.net/faq >> "GPL v2 + the Classpath exception for the class libraries and those >> parts of the virtual machine that expose public APIs" >> >> But currently our tests mix gpl+cp and gpl or has no header at all. >> Tests with "/nodynamiccopyright/", with other company's copyright, or >> other gpl templates were not updated. >> >> Also it would be good if in the faq we explicitly mention about >> copyright of the tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8027696 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8027696/webrev.00 >> > Thanks for doing this. I sampled a few of the files in the webrev and > the changes mostly look okay. > > The only thing is that I'm not sure about is the dates that you've put > on tests that were missing a header. For example, > test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java > was added in 2013 but the header proposed in the webrev has 2012. Does > your script to fix up these headers look at the hg log to get the date > range? > > I see you've changed jdk/test/Makefile to have the GPL header. I don't > know what the right header is for that (as the rest of the Makefiles > have the GPL + Classpath exception). > > One other question is whether this is a one-off effort by yourself or > whether this is part of an effort to keep us in check on a continuous > basis. Periodically David Katleman brings up malformed headers on > jdk8-dev. I assume these are caught by something that checks the > headers on a weekly or continuous basis. Maybe there is an opportunity > to combine efforts and also have these scripts run on a continuous > basis on jdk8/tl, jdk8/awt and the other forests that collect changes. > > -Alan. -- Best regards, Sergey. From aleksej.efimov at oracle.com Tue Nov 5 16:38:44 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Nov 2013 20:38:44 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h Message-ID: <52791F14.2080305@oracle.com> Hi, Can I have a review for tzdata2013h integration [1]. The webrev link can be located here [2]. The following test sets were executed on build with fix: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter And here is the list of failures: FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% FAILED: java/time/tck/java/time/TCKInstant.java %1% FAILED: java/time/tck/java/time/TCKLocalDate.java %1% FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% FAILED: java/util/Calendar/JavatimeTest.java %1% FAILED: sun/util/calendar/zi/TestZoneInfo310.java The group %1% tests failures relates to the JDK-8027622 bug and are expected (actually, it was already resolved in hotspot repo). The 'TestZoneInfo310' test failure is an actual error in current ZoneInfoFile class implementation in JDK. I have filled a bug for this one [3] and will send a separate review with fix later today. [1] https://bugs.openjdk.java.net/browse/JDK-8027370 [2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8027848 From aleksej.efimov at oracle.com Tue Nov 5 17:26:48 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Nov 2013 21:26:48 +0400 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes Message-ID: <52792A58.2050503@oracle.com> Hi, Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. Thanks, Aleksej [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html From Alan.Bateman at oracle.com Tue Nov 5 17:48:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 17:48:18 +0000 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52792A58.2050503@oracle.com> References: <52792A58.2050503@oracle.com> Message-ID: <52792F62.50608@oracle.com> Adding i18n-dev as this is the mailing list where this area is maintained. On 05/11/2013 17:26, Aleksej Efimov wrote: > Hi, > Can I have a review for a 8027848 [1] bug fix . There is unimplemented > functionality related to the future GMT offset changes. > The ZoneInfoFile class doesn't analyses if there is such offset > changes and as a result incorrectly creates the ZoneInfo instance. > It was discovered during the TestZoneInfo310 test execution as part of > tzdata2013h update [3]. > > Thanks, > Aleksej > > [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 > [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 > [3] tzdata2013h review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html > From Alan.Bateman at oracle.com Tue Nov 5 17:50:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 17:50:42 +0000 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <52791F14.2080305@oracle.com> References: <52791F14.2080305@oracle.com> Message-ID: <52792FF2.4050606@oracle.com> On 05/11/2013 16:38, Aleksej Efimov wrote: > Hi, > > Can I have a review for tzdata2013h integration [1]. The webrev link > can be located here [2]. > > The following test sets were executed on build with fix: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter > > And here is the list of failures: > FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% > FAILED: java/time/tck/java/time/TCKInstant.java %1% > FAILED: java/time/tck/java/time/TCKLocalDate.java %1% > FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% > FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% > FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java > %1% > FAILED: java/util/Calendar/JavatimeTest.java %1% > > FAILED: sun/util/calendar/zi/TestZoneInfo310.java > > > The group %1% tests failures relates to the JDK-8027622 bug and are > expected (actually, it was already resolved in hotspot repo). In another thread, Amy Lu is updating the ProblemList.txt to exclude these tests until the hotspot fix gets to jdk8/tl. For your testing then you could run with -XX:-UseMathExactIntrinsics and check that the all tests related to time and time zones are passing. -Alan. From aleksej.efimov at oracle.com Tue Nov 5 18:07:37 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Nov 2013 22:07:37 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <52792FF2.4050606@oracle.com> References: <52791F14.2080305@oracle.com> <52792FF2.4050606@oracle.com> Message-ID: <527933E9.3030707@oracle.com> Alan, Thank you for advise. I have executed the same test sets with -XX:-UseMathExactIntrinsics and, as was expected, there is only one failure: sun/util/calendar/zi/TestZoneInfo310.java. -Aleksej On 11/05/2013 09:50 PM, Alan Bateman wrote: > On 05/11/2013 16:38, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for tzdata2013h integration [1]. The webrev link >> can be located here [2]. >> >> The following test sets were executed on build with fix: >> test/sun/util/calendar test/java/util/Calendar >> test/sun/util/resources/TimeZone test/sun/util/calendar >> test/java/util/TimeZone test/java/time test/java/util/Formatter >> >> And here is the list of failures: >> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >> FAILED: java/time/tck/java/time/TCKInstant.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >> FAILED: >> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >> FAILED: java/util/Calendar/JavatimeTest.java %1% >> >> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >> >> >> The group %1% tests failures relates to the JDK-8027622 bug and are >> expected (actually, it was already resolved in hotspot repo). > In another thread, Amy Lu is updating the ProblemList.txt to exclude > these tests until the hotspot fix gets to jdk8/tl. For your testing > then you could run with -XX:-UseMathExactIntrinsics and check that the > all tests related to time and time zones are passing. > > -Alan. From mike.duigou at oracle.com Tue Nov 5 18:13:05 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Nov 2013 10:13:05 -0800 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <525FD6A4.20302@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> <525FD6A4.20302@oracle.com> Message-ID: <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> One final set of changes was required based upon cross platform testing. The revised webrev which passes cross platform testing on all platforms is here: http://cr.openjdk.java.net/~mduigou/JDK-8015068/3/webrev/ The changes are: - I had to switch to using uname -s because Solaris doesn't support "-o" option. - Some internal tools which scrape the results from Stats.txt were confused by the "FIXME CODETOOLS-7900176" text. I have changed it to not include a space. The second issue does point out one important difference between the previous -exclude handling and the handling used by this changeset. The set of excludes or summary counts is not part of the current logs. I would like to see the excluded totals added into the runlist.txt file but currently jtreg doesn't include either excluded or ignored in this list. Are we ready yet? Finally? Mike On Oct 17 2013, at 05:23 , Alan Bateman wrote: > On 16/10/2013 21:22, Mike Duigou wrote: >> Hello all; >> >> With the imminent promotion of JTReg 4.1b07 it's possible to finally consider completing this changeset! >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/ >> >> This updated webrev includes handling of the shared library permissions. >> >> Thanks, >> >> Mike > It would good to get this in when you can. I looked at the updated webrev and it looks mostly the same as the previous rounds. The update to set the permissions on DLLs looks fine, I assume that cygwin chmod must be add an ACE that grants execute permission. > > -Alan. > From xueming.shen at oracle.com Tue Nov 5 18:50:56 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 05 Nov 2013 10:50:56 -0800 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52792A58.2050503@oracle.com> References: <52792A58.2050503@oracle.com> Message-ID: <52793E10.1050903@oracle.com> Aleksej, For better performance (1) the currT should be "static final" so we dont have to access the System.curentTimeMillis() for each TimeZone/ZoneInfo instance. (2) instead of iterating through the standardTransitions(), shouldn't we just check the last one? given it's a sorted list. btw, in theory, the change now uses the "current vm starttime" instead of the "tzdb generated" time. But it should be fine, given ZoneInfo.getRawOffset() will just do a search for the current rawoffset. I may consider to add the "generated time" into the tzdb.dat in the future, if desired. Thanks! -Sherman On 11/05/2013 09:26 AM, Aleksej Efimov wrote: > Hi, > Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. > The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. > It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. > > Thanks, > Aleksej > > [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 > [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 > [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html From xueming.shen at oracle.com Tue Nov 5 18:58:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 05 Nov 2013 10:58:36 -0800 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52793E10.1050903@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> Message-ID: <52793FDC.5010507@oracle.com> On 11/05/2013 10:50 AM, Xueming Shen wrote: > Aleksej, > > For better performance > (1) the currT should be "static final" so we dont have to access the > System.curentTimeMillis() for each TimeZone/ZoneInfo instance. > (2) instead of iterating through the standardTransitions(), shouldn't we just > check the last one? given it's a sorted list. and maybe this willGMTOffsetChange setting can be done just at line#431. -Sherman > > btw, in theory, the change now uses the "current vm starttime" instead of > the "tzdb generated" time. But it should be fine, given ZoneInfo.getRawOffset() > will just do a search for the current rawoffset. I may consider to add the > "generated time" into the tzdb.dat in the future, if desired. > > Thanks! > -Sherman > > On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >> Hi, >> Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. >> The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. >> It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. >> >> Thanks, >> Aleksej >> >> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >> [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >> [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html > From huizhe.wang at oracle.com Tue Nov 5 19:44:50 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 05 Nov 2013 19:44:50 +0000 Subject: hg: jdk8/tl/jdk: 8027860: [TEST_BUG] File not closed in javax/xml/jaxp/parsers/8022548/XOMParserTest.java Message-ID: <20131105194503.8AA7C62A6C@hg.openjdk.java.net> Changeset: a8a044db575c Author: joehw Date: 2013-11-05 11:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8a044db575c 8027860: [TEST_BUG] File not closed in javax/xml/jaxp/parsers/8022548/XOMParserTest.java Reviewed-by: alanb ! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java From mandy.chung at oracle.com Tue Nov 5 20:24:42 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Nov 2013 12:24:42 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <6DD23F9D-4EA7-4844-8D53-17F7BFF57A33@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <6DD23F9D-4EA7-4844-8D53-17F7BFF57A33@oracle.com> Message-ID: <5279540A.1020800@oracle.com> On 11/5/2013 1:11 AM, Paul Sandoz wrote: > On Nov 5, 2013, at 3:21 AM, Mandy Chung wrote: >>> 2. In VM.java. booted need not be volatile now that it is only accessed within a locked region. Also awaitBooted might as well be void as it can only ever return true. >>> >> Fixed. Revised webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ >> > The booted field is also accessed directly from within other areas of the VM class e.g.: > > 272 // This method can only be invoked during system initialization. > 273 public static void saveAndRemoveProperties(Properties props) { > 274 if (booted) > 275 throw new IllegalStateException("System initialization has completed"); > > 323 public static void initializeOSEnvironment() { > 324 if (!booted) { > 325 OSEnvironment.initialize(); > 326 } > 327 } Oops... missed to look at its use within VM class. A good reason to keep booted as volatile originally. Mandy From mandy.chung at oracle.com Tue Nov 5 20:25:45 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Nov 2013 12:25:45 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <5278CAA5.5000608@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <5278CAA5.5000608@oracle.com> Message-ID: <52795449.7010004@oracle.com> On 11/5/2013 2:38 AM, Alan Bateman wrote: > On 05/11/2013 02:21, Mandy Chung wrote: >> >> Fixed. Revised webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ >> > I looked at the latest webrev. > > Having runFinalization and runAllFinalizers be a no-open during > initialization is reasonable (it should never happen). > > I agree with Peter's suggestion to move the > SharedSecrets.getJavaLangAccess() into the run methods. > Yes agree - thanks Peter. > As regards the booted flag then there are a few places where > VM.isBooted is used so it be better to leave it as volatile (it's only > used in a few places to having it synchronized is unlikely to make an > observable difference). > Reverted back to volatile. http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.04/ Mandy From rob.mckenna at oracle.com Tue Nov 5 21:23:31 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 05 Nov 2013 21:23:31 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) Message-ID: <527961D3.4080004@oracle.com> Hi folks, I'd like to backport this change to JDK7. Note: this fix uses posix_spawn by default on Mac OSX only. On Solaris fork will remain the default behaviour. I've just noticed that there is a problem with the testcase on Solaris in that it will test fork twice. (and won't test posix_spawn) I'll figure out a way around this, but in the mean time I'd like to get the ball rolling on this review anyway. -Rob From rob.mckenna at oracle.com Tue Nov 5 21:24:05 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 05 Nov 2013 21:24:05 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527961D3.4080004@oracle.com> References: <527961D3.4080004@oracle.com> Message-ID: <527961F5.2020401@oracle.com> .. http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ -Rob On 05/11/13 21:23, Rob McKenna wrote: > Hi folks, > > I'd like to backport this change to JDK7. Note: this fix uses > posix_spawn by default on Mac OSX only. On Solaris fork will remain > the default behaviour. > > I've just noticed that there is a problem with the testcase on Solaris > in that it will test fork twice. (and won't test posix_spawn) I'll > figure out a way around this, but in the mean time I'd like to get the > ball rolling on this review anyway. > > -Rob > > From rob.mckenna at oracle.com Tue Nov 5 21:37:26 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 05 Nov 2013 21:37:26 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527961F5.2020401@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> Message-ID: <52796516.6010108@oracle.com> Apologies, I forgot to mention the dependency on: 8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0111bab8dc35 -Rob On 05/11/13 21:24, Rob McKenna wrote: > .. > > http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ > > -Rob > > On 05/11/13 21:23, Rob McKenna wrote: >> Hi folks, >> >> I'd like to backport this change to JDK7. Note: this fix uses >> posix_spawn by default on Mac OSX only. On Solaris fork will remain >> the default behaviour. >> >> I've just noticed that there is a problem with the testcase on >> Solaris in that it will test fork twice. (and won't test posix_spawn) >> I'll figure out a way around this, but in the mean time I'd like to >> get the ball rolling on this review anyway. >> >> -Rob >> >> > From mandy.chung at oracle.com Tue Nov 5 21:58:38 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Nov 2013 13:58:38 -0800 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <52787736.1090904@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> <52786415.7090205@oracle.com> <52787736.1090904@oracle.com> Message-ID: <52796A0E.9030709@oracle.com> On 11/4/2013 8:42 PM, David Holmes wrote: > This looks good to me. One nit that caused me some confusion - it took > me a while to realize that in transitionTo eg: > > 221 public void transitionTo(Thread.State tstate) throws > InterruptedException { > 222 switch (tstate) { > 223 case RUNNABLE: > 224 nextState(RUNNABLE); > 225 break; > > The case value, eg RUNNABLE, and the arg to nextState, eg RUNNABLE, > are two completely different values! Can I suggest using S_xxx for the > int states (why not an enum?). > Good suggestion to rename them. I considered adding an enum class that might confuse with Thread.State enum and so decided to leave them as it is. > Typo: awaitArrive should be awaitAdvance Fixed. This updated webrev also fixes ThreadMXBeanStateTest to retry getting ThreadInfo and improves the formatting of the output and include thread ID in the output: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.03/ This version has got 1000 successful runs of both tests with and without -Xcomp. thanks for the review. Mandy From aleksej.efimov at oracle.com Tue Nov 5 23:21:19 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 06 Nov 2013 03:21:19 +0400 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52793FDC.5010507@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> Message-ID: <52797D6F.3080209@oracle.com> Sherman, Thank you for a quick review. I totally agree with you on all items. Actually, I missed fact that the transitions are sorted. And yes - the change can be done on line #431. The new tested fix can be found here: http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ -Aleksej On 11/05/2013 10:58 PM, Xueming Shen wrote: > On 11/05/2013 10:50 AM, Xueming Shen wrote: >> Aleksej, >> >> For better performance >> (1) the currT should be "static final" so we dont have to access the >> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >> (2) instead of iterating through the standardTransitions(), shouldn't >> we just >> check the last one? given it's a sorted list. > > and maybe this willGMTOffsetChange setting can be done just at line#431. > > -Sherman > >> >> btw, in theory, the change now uses the "current vm starttime" >> instead of >> the "tzdb generated" time. But it should be fine, given >> ZoneInfo.getRawOffset() >> will just do a search for the current rawoffset. I may consider to >> add the >> "generated time" into the tzdb.dat in the future, if desired. >> >> Thanks! >> -Sherman >> >> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>> Hi, >>> Can I have a review for a 8027848 [1] bug fix . There is >>> unimplemented functionality related to the future GMT offset changes. >>> The ZoneInfoFile class doesn't analyses if there is such offset >>> changes and as a result incorrectly creates the ZoneInfo instance. >>> It was discovered during the TestZoneInfo310 test execution as part >>> of tzdata2013h update [3]. >>> >>> Thanks, >>> Aleksej >>> >>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>> [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>> [3] tzdata2013h review thread: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >> > From david.holmes at oracle.com Wed Nov 6 00:23:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Nov 2013 10:23:18 +1000 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52795449.7010004@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <5278CAA5.5000608@oracle.com> <52795449.7010004@oracle.com> Message-ID: <52798BF6.2060701@oracle.com> Ship it! :) And again apologies for sending you down the wrong path on the volatile. David On 6/11/2013 6:25 AM, Mandy Chung wrote: > On 11/5/2013 2:38 AM, Alan Bateman wrote: >> On 05/11/2013 02:21, Mandy Chung wrote: >>> >>> Fixed. Revised webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ >>> >> I looked at the latest webrev. >> >> Having runFinalization and runAllFinalizers be a no-open during >> initialization is reasonable (it should never happen). >> >> I agree with Peter's suggestion to move the >> SharedSecrets.getJavaLangAccess() into the run methods. >> > > Yes agree - thanks Peter. > >> As regards the booted flag then there are a few places where >> VM.isBooted is used so it be better to leave it as volatile (it's only >> used in a few places to having it synchronized is unlikely to make an >> observable difference). >> > > Reverted back to volatile. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.04/ > > Mandy From david.holmes at oracle.com Wed Nov 6 01:07:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Nov 2013 11:07:08 +1000 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <52796A0E.9030709@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> <52786415.7090205@oracle.com> <52787736.1090904@oracle.com> <52796A0E.9030709@oracle.com> Message-ID: <5279963C.7050406@oracle.com> Thanks Mandy. One minor nit: Having goSleep be an instance method on ThreadStateController makes the usage look weird: thread.goSleep(10); // actually makes current thread go sleep I suggest making it static and use static import to shorten the call site :) If you do change that, no need for re-review. David On 6/11/2013 7:58 AM, Mandy Chung wrote: > On 11/4/2013 8:42 PM, David Holmes wrote: >> This looks good to me. One nit that caused me some confusion - it took >> me a while to realize that in transitionTo eg: >> >> 221 public void transitionTo(Thread.State tstate) throws >> InterruptedException { >> 222 switch (tstate) { >> 223 case RUNNABLE: >> 224 nextState(RUNNABLE); >> 225 break; >> >> The case value, eg RUNNABLE, and the arg to nextState, eg RUNNABLE, >> are two completely different values! Can I suggest using S_xxx for the >> int states (why not an enum?). >> > > Good suggestion to rename them. I considered adding an enum class that > might confuse with Thread.State enum and so decided to leave them as it is. > >> Typo: awaitArrive should be awaitAdvance > > Fixed. > > This updated webrev also fixes ThreadMXBeanStateTest to retry getting > ThreadInfo and improves the formatting of the output and include thread > ID in the output: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.03/ > > This version has got 1000 successful runs of both tests with and without > -Xcomp. > > thanks for the review. > Mandy From david.holmes at oracle.com Wed Nov 6 01:09:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Nov 2013 11:09:18 +1000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527961F5.2020401@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> Message-ID: <527996BE.3060003@oracle.com> Hi Rob, How different is this to the JDK 8 version? Thanks, David On 6/11/2013 7:24 AM, Rob McKenna wrote: > .. > > http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ > > -Rob > > On 05/11/13 21:23, Rob McKenna wrote: >> Hi folks, >> >> I'd like to backport this change to JDK7. Note: this fix uses >> posix_spawn by default on Mac OSX only. On Solaris fork will remain >> the default behaviour. >> >> I've just noticed that there is a problem with the testcase on Solaris >> in that it will test fork twice. (and won't test posix_spawn) I'll >> figure out a way around this, but in the mean time I'd like to get the >> ball rolling on this review anyway. >> >> -Rob >> >> > From david.holmes at oracle.com Wed Nov 6 01:20:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Nov 2013 11:20:11 +1000 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> <525FD6A4.20302@oracle.com> <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> Message-ID: <5279994B.6090206@oracle.com> Hi Mike, Won't pretend I follow all the changes, but how did you get rid of the platform-specific checks in the ProblemList ? Will jtreg figure that part out for itself? Also what is the failure mode if JT_HOME is not set and jtreg is not in the path? Should we just fail in that case before we try to use a blank variable. Thanks, David On 6/11/2013 4:13 AM, Mike Duigou wrote: > One final set of changes was required based upon cross platform testing. > > The revised webrev which passes cross platform testing on all platforms is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8015068/3/webrev/ > > The changes are: > > - I had to switch to using uname -s because Solaris doesn't support "-o" option. > > - Some internal tools which scrape the results from Stats.txt were confused by the "FIXME CODETOOLS-7900176" text. I have changed it to not include a space. > > The second issue does point out one important difference between the previous -exclude handling and the handling used by this changeset. The set of excludes or summary counts is not part of the current logs. I would like to see the excluded totals added into the runlist.txt file but currently jtreg doesn't include either excluded or ignored in this list. > > Are we ready yet? Finally? > > Mike > > > On Oct 17 2013, at 05:23 , Alan Bateman wrote: > >> On 16/10/2013 21:22, Mike Duigou wrote: >>> Hello all; >>> >>> With the imminent promotion of JTReg 4.1b07 it's possible to finally consider completing this changeset! >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/ >>> >>> This updated webrev includes handling of the shared library permissions. >>> >>> Thanks, >>> >>> Mike >> It would good to get this in when you can. I looked at the updated webrev and it looks mostly the same as the previous rounds. The update to set the permissions on DLLs looks fine, I assume that cygwin chmod must be add an ACE that grants execute permission. >> >> -Alan. >> > From mandy.chung at oracle.com Wed Nov 6 01:21:20 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Nov 2013 17:21:20 -0800 Subject: JDK-8027351: (ref) Base's class finalize method not invoked if a private finalize method exists in its subclass In-Reply-To: <52798BF6.2060701@oracle.com> References: <5273EFCB.7010200@oracle.com> <20131101133742.799770@eggemoggin.niobe.net> <527418F8.5040507@oracle.com> <5276F92E.5030405@oracle.com> <52772667.8080100@oracle.com> <52775BF3.4020708@gmail.com> <52775F4C.5040601@oracle.com> <527770F4.1070305@gmail.com> <5277FDDB.3040508@oracle.com> <527851DC.9020908@oracle.com> <5278562A.90209@oracle.com> <5278CAA5.5000608@oracle.com> <52795449.7010004@oracle.com> <52798BF6.2060701@oracle.com> Message-ID: <52799990.1000701@oracle.com> On 11/5/2013 4:23 PM, David Holmes wrote: > Ship it! :) > Thanks for the review. > And again apologies for sending you down the wrong path on the volatile. > No apology needed. I missed its usage in sun.misc.VM. Mandy > David > > On 6/11/2013 6:25 AM, Mandy Chung wrote: >> On 11/5/2013 2:38 AM, Alan Bateman wrote: >>> On 05/11/2013 02:21, Mandy Chung wrote: >>>> >>>> Fixed. Revised webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.03/ >>>> >>> I looked at the latest webrev. >>> >>> Having runFinalization and runAllFinalizers be a no-open during >>> initialization is reasonable (it should never happen). >>> >>> I agree with Peter's suggestion to move the >>> SharedSecrets.getJavaLangAccess() into the run methods. >>> >> >> Yes agree - thanks Peter. >> >>> As regards the booted flag then there are a few places where >>> VM.isBooted is used so it be better to leave it as volatile (it's only >>> used in a few places to having it synchronized is unlikely to make an >>> observable difference). >>> >> >> Reverted back to volatile. >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027351/webrev.04/ >> >> Mandy From mandy.chung at oracle.com Wed Nov 6 01:35:04 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Nov 2013 17:35:04 -0800 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5279963C.7050406@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> <52786415.7090205@oracle.com> <52787736.1090904@oracle.com> <52796A0E.9030709@oracle.com> <5279963C.7050406@oracle.com> Message-ID: <52799CC8.2020509@oracle.com> On 11/5/2013 5:07 PM, David Holmes wrote: > Thanks Mandy. > > One minor nit: > > Having goSleep be an instance method on ThreadStateController makes > the usage look weird: > > thread.goSleep(10); // actually makes current thread go sleep > Good catch. I changed it to a static pause(long ms) method. Changeset pushed. thanks for the review. Mandy > I suggest making it static and use static import to shorten the call > site :) > > If you do change that, no need for re-review. > > David > > On 6/11/2013 7:58 AM, Mandy Chung wrote: >> On 11/4/2013 8:42 PM, David Holmes wrote: >>> This looks good to me. One nit that caused me some confusion - it took >>> me a while to realize that in transitionTo eg: >>> >>> 221 public void transitionTo(Thread.State tstate) throws >>> InterruptedException { >>> 222 switch (tstate) { >>> 223 case RUNNABLE: >>> 224 nextState(RUNNABLE); >>> 225 break; >>> >>> The case value, eg RUNNABLE, and the arg to nextState, eg RUNNABLE, >>> are two completely different values! Can I suggest using S_xxx for the >>> int states (why not an enum?). >>> >> >> Good suggestion to rename them. I considered adding an enum class that >> might confuse with Thread.State enum and so decided to leave them as >> it is. >> >>> Typo: awaitArrive should be awaitAdvance >> >> Fixed. >> >> This updated webrev also fixes ThreadMXBeanStateTest to retry getting >> ThreadInfo and improves the formatting of the output and include thread >> ID in the output: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.03/ >> >> This version has got 1000 successful runs of both tests with and without >> -Xcomp. >> >> thanks for the review. >> Mandy From mandy.chung at oracle.com Wed Nov 6 01:33:35 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 06 Nov 2013 01:33:35 +0000 Subject: hg: jdk8/tl/jdk: 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java; ... Message-ID: <20131106013347.C2A5E62A89@hg.openjdk.java.net> Changeset: 85fd2ae0a845 Author: mchung Date: 2013-11-05 17:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85fd2ae0a845 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java 6944188: ThreadMXBean/ThreadStateTest.java fails intermittently Reviewed-by: dholmes, chegar + test/java/lang/Thread/ThreadStateController.java ! test/java/lang/Thread/ThreadStateTest.java + test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java - test/java/lang/management/ThreadMXBean/ThreadStateTest.java From stuart.marks at oracle.com Wed Nov 6 01:50:17 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 05 Nov 2013 17:50:17 -0800 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <5273D448.2050808@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> Message-ID: <5279A059.9010304@oracle.com> On 11/1/13 9:18 AM, Tristan Yan wrote: > Hi Everyone > http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ > > Description: > 1. Convert shell script test to Java program test. > 2. Using random server port by reusing Darryl Mocek's work to replace fixed > server port. > 3. Using java Process class to start client process. > 4. Also convert other shell script test runSerialBench.sh to java program test also Hi Tristan, Several comments on this webrev. ** The original arrangement within the test/java/rmi/reliability/benchmark directory had the main benchmark files (scripts) at the top, some benchmark framework files in the "bench" subdirectory, and the actual RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. The webrev moves all the RMI benchmarks to the top benchmark directory but leaves the serial benchmarks in bench/serial. The RMI benchmarks are now all cluttering the top directory, but the main serial benchmark test is now buried in the bench/serial directory. The nice organization that was there before is now spoiled. Is this rearrangement necessary in order to convert the scripts to Java? I would prefer the original arrangement be left in place. ** The RMI benchmark Main.java file has a @run tag of the form, @run main/othervm/policy=policy.all/timeout=1800 -server Main -c config There is a subtle but serious problem here: the -server option is passed to the >>JVM<< and not as an argument to the main() method. The main() method gets neither a -server nor a -client argument, so its default "run mode" as defined by the benchmark itself is SAMEVM. This runs the client and server in the same JVM, which is different from the shell script, which ran separate client and server JVMs. ** The logic to process the -server argument still expects to take a port, even though the port is assigned automatically. So the obvious fix to the above, @run main/othervm/policy=policy.all/timeout=1800 Main -server -c config doesn't work, since a port is missing. The logic to increment the argument index to collect the port argument should be removed. Also, the -server line should be restored to the usage message, but without the port argument. ** After this is done, the client's command line is constructed improperly. The command line ends up looking something like this: java client -cp Main client localhost:58583 -c config The word "client" appears twice, but what's really required is "-client" to appear as an argument after Main. ** The client is run using ProcessBuilder, which by default sends stdout and stderr to pipes to be read by the parent. But the parent never reads them, thus any messages from the client are never seen. The client is the one that emits the benchmark report, so its output needs to be seen. It might be sufficient to have the client inherit the parent's stdout and stderr. This might intermix the client's and server's output, but it's better than nothing. ** The config file is checked with the following code: try { confFile = args[i]; confstr = new FileInputStream(System.getProperty("test.src") + System.getProperty("file.separator") + confFile); } catch (IOException e) { die("Error: unable to open \"" + args[i] + "\""); } This is potentially misleading, as the message doesn't print the actual filename that was attempted to be opened. This is important, as the test.src property doesn't exist in the client JVM. Note that the original shell script passed full pathnames for the config file to both the client and the server. The new @run tag merely says "-c config" which redefines the config filename to be relative to the test.src directory. You could pass -Dtest.src=... to the client, but it seems like there should be something better than can be done. ** The client needs to have its security policy set up. This is missing from the construction of the client's command line. ** ProcessBuilder takes a List for its command; there is no need to turn the list into an array. ** In the benchmark main methods, code of the form, while (true) { runBenchmarks(); if (exitRequested) { System.exit(); } } was replaced with while (!exitRequested) { runBenchmarks(); } This is a subtle logic change, in that the former code always executed the loop at least once. It seems unlikely, but it's possible that a timer could set exitRequested before loop entry, resulting in the benchmark running zero times. I guess, if you really want to clean this up (we do need to avoid System.exit in jtreg tests), use a do-while loop instead. ** Don't forget to remove the 7190106/runRmiBench.sh entry from ProblemList.txt. ** Remove the references to RMISecurityManager and just use SecurityManager. This is just general cleanup. (I deprecated RMISecurityManager last week.) :-) It would be good if you could fix up these issues and post another webrev. Thanks. s'marks > Thank you > Tristan > > On 01/11/2013 23:58, Stuart Marks wrote: >> On 10/31/13 10:22 PM, Tristan Yan wrote: >>> I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>> on my research, it looks like the issue of fixed port was already addressed >>> by Stuart Marks in other RMI tests which are Java based. I would like to >>> reuse his solution, however it does not work for shell based tests. >> >> (Darryl Mocek did the unique port work for the RMI tests.) >> >> Was the patch attached to your message? If so, it didn't get through. Most >> OpenJDK mailing lists strip off attachments before forwarding the message to >> the recipients. >> >>> 2. My recommendation would be to convert this shell script test into Java >>> based test and re-use the dynamic port allocation solution by Stuart Marks to >>> address the issue >>> >>> 3. Also this test was written with server/client mode in shell script. In the >>> past there have been sync issues between server/client which caused the test >>> to fail. If we convert the shell script into Java based test, it would avoid >>> using "sleep 10" mechanism to allow for server and client to start up and >>> also give us better control in synchronizing server and client. >> >> (Background for interested readers.) In general, yes, it's quite difficult to >> make reliable shell tests, especially for multi-process tests like this one. >> There is the unique port issue, and there is also the issue of how long for >> the client to wait until the server is ready. Error handling is also a >> problem, for example, if one of the JVMs gets an unexpected exception, it's >> easy for shell tests to mishandle this case. They might hang or erroneously >> report success. >> >> -- >> >> If this is a rewrite, it's probably fairly large, so you need to upload it >> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >> >> Thanks. >> >> s'marks > From mike.duigou at oracle.com Wed Nov 6 02:04:18 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Nov 2013 18:04:18 -0800 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <5279994B.6090206@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> <525FD6A4.20302@oracle.com> <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> <5279994B.6090206@oracle.com> Message-ID: <24A8AD3F-A0C0-4F18-BB2B-D07B774FA0C6@oracle.com> On Nov 5 2013, at 17:20 , David Holmes wrote: > Hi Mike, > > Won't pretend I follow all the changes, but how did you get rid of the platform-specific checks in the ProblemList ? Will jtreg figure that part out for itself? Yes. JTReg has had this ability for a while and was recently enhanced to support multiple exclude files. I > Also what is the failure mode if JT_HOME is not set and jtreg is not in the path? Should we just fail in that case before we try to use a blank variable. Good point. I am going to revert to setting JT_HOME to a fixed SLASHJAVA path and fix it in the next round. (which redoes configure time detection of jtreg and eliminates JT_HOME entirely). Mike > > Thanks, > David > > On 6/11/2013 4:13 AM, Mike Duigou wrote: >> One final set of changes was required based upon cross platform testing. >> >> The revised webrev which passes cross platform testing on all platforms is here: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015068/3/webrev/ >> >> The changes are: >> >> - I had to switch to using uname -s because Solaris doesn't support "-o" option. >> >> - Some internal tools which scrape the results from Stats.txt were confused by the "FIXME CODETOOLS-7900176" text. I have changed it to not include a space. >> >> The second issue does point out one important difference between the previous -exclude handling and the handling used by this changeset. The set of excludes or summary counts is not part of the current logs. I would like to see the excluded totals added into the runlist.txt file but currently jtreg doesn't include either excluded or ignored in this list. >> >> Are we ready yet? Finally? >> >> Mike >> >> >> On Oct 17 2013, at 05:23 , Alan Bateman wrote: >> >>> On 16/10/2013 21:22, Mike Duigou wrote: >>>> Hello all; >>>> >>>> With the imminent promotion of JTReg 4.1b07 it's possible to finally consider completing this changeset! >>>> >>>> http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/ >>>> >>>> This updated webrev includes handling of the shared library permissions. >>>> >>>> Thanks, >>>> >>>> Mike >>> It would good to get this in when you can. I looked at the updated webrev and it looks mostly the same as the previous rounds. The update to set the permissions on DLLs looks fine, I assume that cygwin chmod must be add an ACE that grants execute permission. >>> >>> -Alan. >>> >> From amy.lu at oracle.com Wed Nov 6 02:45:06 2013 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 06 Nov 2013 10:45:06 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5278D1EE.60404@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> Message-ID: <5279AD32.40907@oracle.com> On 11/5/13 7:09 PM, Amy Lu wrote: > On 11/5/13 6:01 PM, Alan Bateman wrote: >> On 05/11/2013 09:26, Amy Lu wrote: >>> : >>> >>> Please review ProblemList.txt changes: >>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>> >> This looks okay to me although I'm not sure about >> sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej >> fixed the test and also excluded it, pending a decision/discussion on >> whether this test should be removed). Aleksej, Should this test be removed from ProblemList? Thanks, Amy >> >> Should we use the opportunity to add all the tests that are failing >> due to the exact math intrinsic (JDK-8027622)? >> >> -Alan. > > Added 8027622 and affected tests into ProblemList: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html > > > Thanks, > Amy From tristan.yan at oracle.com Wed Nov 6 03:04:09 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 06 Nov 2013 11:04:09 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5279AD32.40907@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> Message-ID: <5279B1A9.3080408@oracle.com> Hi Amy Can we exclude below two also test/com/sun/net/httpserver/Test9a.java test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Thank you Tristan On 06/11/2013 10:45, Amy Lu wrote: > On 11/5/13 7:09 PM, Amy Lu wrote: >> On 11/5/13 6:01 PM, Alan Bateman wrote: >>> On 05/11/2013 09:26, Amy Lu wrote: >>>> : >>>> >>>> Please review ProblemList.txt changes: >>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>> >>> This looks okay to me although I'm not sure about >>> sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej >>> fixed the test and also excluded it, pending a decision/discussion >>> on whether this test should be removed). > > Aleksej, > > Should this test be removed from ProblemList? > > Thanks, > Amy > >>> >>> Should we use the opportunity to add all the tests that are failing >>> due to the exact math intrinsic (JDK-8027622)? >>> >>> -Alan. >> >> Added 8027622 and affected tests into ProblemList: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >> >> >> Thanks, >> Amy > From tristan.yan at oracle.com Wed Nov 6 03:38:33 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 06 Nov 2013 11:38:33 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5279B1A9.3080408@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> <5279B1A9.3080408@oracle.com> Message-ID: <5279B9B9.40007@oracle.com> Sorry, I replied to the wrong thread, please ignore my previous mail Tristan On 06/11/2013 11:04, Tristan Yan wrote: > Hi Amy > Can we exclude below two also > > test/com/sun/net/httpserver/Test9a.java > test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java > > Thank you > Tristan > > On 06/11/2013 10:45, Amy Lu wrote: >> On 11/5/13 7:09 PM, Amy Lu wrote: >>> On 11/5/13 6:01 PM, Alan Bateman wrote: >>>> On 05/11/2013 09:26, Amy Lu wrote: >>>>> : >>>>> >>>>> Please review ProblemList.txt changes: >>>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>>> >>>> This looks okay to me although I'm not sure about >>>> sun/util/resources/TimeZone/Bug6317929.java (for some reason >>>> Aleksej fixed the test and also excluded it, pending a >>>> decision/discussion on whether this test should be removed). >> >> Aleksej, >> >> Should this test be removed from ProblemList? >> >> Thanks, >> Amy >> >>>> >>>> Should we use the opportunity to add all the tests that are failing >>>> due to the exact math intrinsic (JDK-8027622)? >>>> >>>> -Alan. >>> >>> Added 8027622 and affected tests into ProblemList: >>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >>> >>> >>> Thanks, >>> Amy >> > From mike.duigou at oracle.com Wed Nov 6 03:51:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 5 Nov 2013 19:51:44 -0800 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> <525FD6A4.20302@oracle.com> <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> Message-ID: I have updated the webrev to backout the changes to how JT_HOME is set. This will be addressed in the next set of changes (8020779 https://bugs.openjdk.java.net/browse/JDK-8020779 and 8009683 https://bugs.openjdk.java.net/browse/JDK-8009683) which will revisit how JT_HOME is set and how the jtreg executable is found. http://cr.openjdk.java.net/~mduigou/JDK-8015068/4/webrev/ Mike On Nov 5 2013, at 10:13 , Mike Duigou wrote: > One final set of changes was required based upon cross platform testing. > > The revised webrev which passes cross platform testing on all platforms is here: > > http://cr.openjdk.java.net/~mduigou/JDK-8015068/3/webrev/ > > The changes are: > > - I had to switch to using uname -s because Solaris doesn't support "-o" option. > > - Some internal tools which scrape the results from Stats.txt were confused by the "FIXME CODETOOLS-7900176" text. I have changed it to not include a space. > > The second issue does point out one important difference between the previous -exclude handling and the handling used by this changeset. The set of excludes or summary counts is not part of the current logs. I would like to see the excluded totals added into the runlist.txt file but currently jtreg doesn't include either excluded or ignored in this list. > > Are we ready yet? Finally? > > Mike > > > On Oct 17 2013, at 05:23 , Alan Bateman wrote: > >> On 16/10/2013 21:22, Mike Duigou wrote: >>> Hello all; >>> >>> With the imminent promotion of JTReg 4.1b07 it's possible to finally consider completing this changeset! >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/ >>> >>> This updated webrev includes handling of the shared library permissions. >>> >>> Thanks, >>> >>> Mike >> It would good to get this in when you can. I looked at the updated webrev and it looks mostly the same as the previous rounds. The update to set the permissions on DLLs looks fine, I assume that cygwin chmod must be add an ACE that grants execute permission. >> >> -Alan. >> > From forax at univ-mlv.fr Wed Nov 6 10:37:14 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 06 Nov 2013 11:37:14 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <029C8D69-1223-45A3-A793-53009B2E279D@oracle.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278AB95.6000707@gmail.com> <167F01C3-5C73-470A-8E13-128DA317A9F0@oracle.com> <5278BF87.5020501@gmail.com> <029C8D69-1223-45A3-A793-53009B2E279D@oracle.com> Message-ID: <527A1BDA.1080604@univ-mlv.fr> On 11/05/2013 11:11 AM, Joel Borggr?n-Franck wrote: > On 5 nov 2013, at 10:51, Peter Levart wrote: > >> 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 accessor: >>>>> >>>>> - for classic declaring class - as is / unchanged >>>>> - for anonymous declaring class - just create and return NativeMethodAccessorImpl without a parent >>>>> >>>>> Then in NativeMethodAccessorImpl (and same for constructor), modify the inflation checking logic: >>>>> >>>>> if (parent != null && ++numInvocations > ReflectionFactory.inflationThreshold()) { >>>>> MethodAccessorImpl acc = (MethodAccessorImpl) >>>>> new MethodAccessorGenerator(). >>>>> generateMethod(method.getDeclaringClass(), >>>>> method.getName(), >>>>> method.getParameterTypes(), >>>>> method.getReturnType(), >>>>> method.getExceptionTypes(), >>>>> method.getModifiers()); >>>>> parent.setDelegate(acc); >>>>> } >>> I don't like adding even more special cases to this check. IMHO a better way that we discussed and rejected, opting for a smaller change, is to create a NonInflatingMethodAccessor and just drop in one of those without a delegate for when creating the accessor for methods/ctors on anonymous classes. >> Even better. I would name the new class NativeMethodAccessorImpl and the one doing inflation InflatingNativeMethodAccessorImpl which would extend NativeMethodAccessorImpl, override invoke() and call super.invoke()... This way, no native methods duplication is needed. invoke() is already an interface method with 2 implementations. Now it will have 3. Does this present any difference for dispatch optimization? >> > FWIW i think the magic number is 4, but I don't know where I got that. Anyhow, this might be slightly controversial, but for all code I care about (reflective invocation of methods/ctors on non-VM-anonymous classes) the check happens exactly once as is. No, the magic number is 2 (by default), you can look for TypeProfileWidth in the vm code. regards, R?mi From rob.mckenna at oracle.com Wed Nov 6 13:30:43 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 06 Nov 2013 13:30:43 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527A0673.9000500@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <52796516.6010108@oracle.com> <527A0673.9000500@oracle.com> Message-ID: <527A4483.3040306@oracle.com> Hi Alan, On 06/11/13 09:05, Alan Bateman wrote: > On 05/11/2013 21:37, Rob McKenna wrote: >> Apologies, I forgot to mention the dependency on: >> >> 8008118: (process) Possible null pointer dereference in >> jdk/src/solaris/native/java/lang/UNIXProcess_md.c >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0111bab8dc35 >> >> -Rob > To keep the changes the same for jdk7u-dev then it make sense to bring > this in first. The process to get changes into jdk7u-dev requires > getting approval on the jdk7u-dev mailing list, we can't approve it here. Yes, absolutely. I'm looking for approval for the code in principle. Particularly the change in the default property value on Solaris since thats the only change. Once approved I will of course seek approval for integration. Also, I will also integrate these changes separately and in order. 8008118 has been sitting in my repository for some time and I totally forgot about it until I looked at the webrev. -Rob > > -Alan > From jan.lahoda at oracle.com Wed Nov 6 16:50:37 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 06 Nov 2013 16:50:37 +0000 Subject: hg: jdk8/tl/langtools: 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests Message-ID: <20131106165047.9E584623C6@hg.openjdk.java.net> Changeset: 75c8cde12ab6 Author: jlahoda Date: 2013-11-06 17:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/75c8cde12ab6 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. Reviewed-by: vromero, dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/defaultMethods/super/TestDirectSuperInterfaceInvoke.java From Alan.Bateman at oracle.com Wed Nov 6 14:33:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Nov 2013 14:33:27 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527A4483.3040306@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <52796516.6010108@oracle.com> <527A0673.9000500@oracle.com> <527A4483.3040306@oracle.com> Message-ID: <527A5337.2090100@oracle.com> On 06/11/2013 13:30, Rob McKenna wrote: > > Yes, absolutely. I'm looking for approval for the code in principle. > Particularly the change in the default property value on Solaris since > thats the only change. Once approved I will of course seek approval > for integration. I think the proposal is reasonable, at least I (for one) think of Mac OS X as more of a developer platform whereas someone deploying on Solaris is more likely to be a bit more conservative. -Alan. From rob.mckenna at oracle.com Wed Nov 6 12:00:00 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 06 Nov 2013 12:00:00 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527996BE.3060003@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <527996BE.3060003@oracle.com> Message-ID: <527A2F40.7020200@oracle.com> Hi David, The only difference in 5049299 is the change in the default property value in Solaris. Apologies for not making that clear. -Rob On 06/11/13 01:09, David Holmes wrote: > Hi Rob, > > How different is this to the JDK 8 version? > > Thanks, > David > > On 6/11/2013 7:24 AM, Rob McKenna wrote: >> .. >> >> http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ >> >> -Rob >> >> On 05/11/13 21:23, Rob McKenna wrote: >>> Hi folks, >>> >>> I'd like to backport this change to JDK7. Note: this fix uses >>> posix_spawn by default on Mac OSX only. On Solaris fork will remain >>> the default behaviour. >>> >>> I've just noticed that there is a problem with the testcase on Solaris >>> in that it will test fork twice. (and won't test posix_spawn) I'll >>> figure out a way around this, but in the mean time I'd like to get the >>> ball rolling on this review anyway. >>> >>> -Rob >>> >>> >> From Alan.Bateman at oracle.com Wed Nov 6 17:11:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Nov 2013 17:11:28 +0000 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> <525FD6A4.20302@oracle.com> <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> Message-ID: <527A7840.4080405@oracle.com> On 06/11/2013 03:51, Mike Duigou wrote: > I have updated the webrev to backout the changes to how JT_HOME is set. This will be addressed in the next set of changes (8020779 https://bugs.openjdk.java.net/browse/JDK-8020779 and 8009683 https://bugs.openjdk.java.net/browse/JDK-8009683) which will revisit how JT_HOME is set and how the jtreg executable is found. > > http://cr.openjdk.java.net/~mduigou/JDK-8015068/4/webrev/ > > Mike > I've skimmed over the lastest webrev and it looks very good (and great to see the use of groups and the removal of the exclude list cruft). On the excluded=CODETOOLS-7900176 output then maybe this should be left out for now as the Makefile will need to be updated if/when there is a way to get the count of the number of tests excluded. -Alan. From mike.duigou at oracle.com Wed Nov 6 17:13:14 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Nov 2013 09:13:14 -0800 Subject: RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing In-Reply-To: <527A7840.4080405@oracle.com> References: <145F648E-CDE7-4C36-8E4B-F56ED39C0C5E@oracle.com> <6F54F866-5384-4B0C-AC36-826838760C1E@oracle.com> <521DDAD7.9000701@oracle.com> <525FD6A4.20302@oracle.com> <4DFE4F38-D924-4EE0-9ECB-6562644AB40F@oracle.com> <527A7840.4080405@oracle.com> Message-ID: <6B85ACFC-16AD-4CF6-9FB3-58CD72CCF824@oracle.com> Thank you for the review! On Nov 6 2013, at 09:11 , Alan Bateman wrote: > On 06/11/2013 03:51, Mike Duigou wrote: >> I have updated the webrev to backout the changes to how JT_HOME is set. This will be addressed in the next set of changes (8020779 https://bugs.openjdk.java.net/browse/JDK-8020779 and 8009683 https://bugs.openjdk.java.net/browse/JDK-8009683) which will revisit how JT_HOME is set and how the jtreg executable is found. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8015068/4/webrev/ >> >> Mike >> > I've skimmed over the lastest webrev and it looks very good (and great to see the use of groups and the removal of the exclude list cruft). > > On the excluded=CODETOOLS-7900176 output then maybe this should be left out for now as the Makefile will need to be updated if/when there is a way to get the count of the number of tests excluded. I will remove "excluded" entirely for now then. Mike > -Alan. From xueming.shen at oracle.com Wed Nov 6 17:18:57 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Nov 2013 09:18:57 -0800 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52797D6F.3080209@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> <52797D6F.3080209@oracle.com> Message-ID: <527A7A01.3010301@oracle.com> Looks fine. thanks! -Sherman On 11/05/2013 03:21 PM, Aleksej Efimov wrote: > Sherman, > Thank you for a quick review. I totally agree with you on all items. > Actually, I missed fact that the transitions are sorted. And yes - the change can be done on line #431. > The new tested fix can be found here: http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ > > -Aleksej > > On 11/05/2013 10:58 PM, Xueming Shen wrote: >> On 11/05/2013 10:50 AM, Xueming Shen wrote: >>> Aleksej, >>> >>> For better performance >>> (1) the currT should be "static final" so we dont have to access the >>> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >>> (2) instead of iterating through the standardTransitions(), shouldn't we just >>> check the last one? given it's a sorted list. >> >> and maybe this willGMTOffsetChange setting can be done just at line#431. >> >> -Sherman >> >>> >>> btw, in theory, the change now uses the "current vm starttime" instead of >>> the "tzdb generated" time. But it should be fine, given ZoneInfo.getRawOffset() >>> will just do a search for the current rawoffset. I may consider to add the >>> "generated time" into the tzdb.dat in the future, if desired. >>> >>> Thanks! >>> -Sherman >>> >>> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>>> Hi, >>>> Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. >>>> The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. >>>> It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. >>>> >>>> Thanks, >>>> Aleksej >>>> >>>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>>> [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>>> [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >>> >> > From mike.duigou at oracle.com Wed Nov 6 17:50:48 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 06 Nov 2013 17:50:48 +0000 Subject: hg: jdk8/tl/jdk: 8021309: replace test/Makefile jdk_* targets with jtreg groups; ... Message-ID: <20131106175102.D607F623C9@hg.openjdk.java.net> Changeset: 9c30cbc316e9 Author: mduigou Date: 2013-11-05 19:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c30cbc316e9 8021309: replace test/Makefile jdk_* targets with jtreg groups 8015068: Use jtreg -exclude for handling problemList.txt exclusions Reviewed-by: jjg, smarks, chegar, alanb, dholmes ! .hgignore ! test/Makefile From Alan.Bateman at oracle.com Wed Nov 6 09:05:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Nov 2013 09:05:55 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <52796516.6010108@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <52796516.6010108@oracle.com> Message-ID: <527A0673.9000500@oracle.com> On 05/11/2013 21:37, Rob McKenna wrote: > Apologies, I forgot to mention the dependency on: > > 8008118: (process) Possible null pointer dereference in > jdk/src/solaris/native/java/lang/UNIXProcess_md.c > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0111bab8dc35 > > -Rob To keep the changes the same for jdk7u-dev then it make sense to bring this in first. The process to get changes into jdk7u-dev requires getting approval on the jdk7u-dev mailing list, we can't approve it here. -Alan From xueming.shen at oracle.com Wed Nov 6 18:44:06 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Nov 2013 10:44:06 -0800 Subject: RFR: 8026330: java.util.Base64 urlEncoder should omit padding Message-ID: <527A8DF6.1070603@oracle.com> Hi, The latest spec and implementation of java.util.Base64.getXXXEncoder() is to add appropriate padding character(s) at the end of the output encoded data stream, to follow the note explicitly specified in the RFC Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise. However the RFE also mentions that In some circumstances, the use of padding ("=") in base-encoded data is not required or used... Feedback so far also suggests that Base64.encoder without padding might be desired in some real world use scenario. So here is the webrev to add a new method to the Encoder class to return a non-padding version. http://cr.openjdk.java.net/~sherman/8026330/webrev Thanks! -Sherman From peter.levart at gmail.com Wed Nov 6 19:10:10 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 06 Nov 2013 20:10:10 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <527A1BDA.1080604@univ-mlv.fr> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278AB95.6000707@gmail.com> <167F01C3-5C73-470A-8E13-128DA317A9F0@oracle.com> <5278BF87.5020501@gmail.com> <029C8D69-1223-45A3-A793-53009B2E279D@oracle.com> <527A1BDA.1080604@univ-mlv.fr> Message-ID: <527A9412.305@gmail.com> 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 wrote: >> >>> 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 accessor: >>>>>> >>>>>> - for classic declaring class - as is / unchanged >>>>>> - for anonymous declaring class - just create and return >>>>>> NativeMethodAccessorImpl without a parent >>>>>> >>>>>> Then in NativeMethodAccessorImpl (and same for constructor), >>>>>> modify the inflation checking logic: >>>>>> >>>>>> if (parent != null && ++numInvocations > >>>>>> ReflectionFactory.inflationThreshold()) { >>>>>> MethodAccessorImpl acc = (MethodAccessorImpl) >>>>>> new MethodAccessorGenerator(). >>>>>> generateMethod(method.getDeclaringClass(), >>>>>> method.getName(), >>>>>> method.getParameterTypes(), >>>>>> method.getReturnType(), >>>>>> method.getExceptionTypes(), >>>>>> method.getModifiers()); >>>>>> parent.setDelegate(acc); >>>>>> } >>>> I don't like adding even more special cases to this check. IMHO a >>>> better way that we discussed and rejected, opting for a smaller >>>> change, is to create a NonInflatingMethodAccessor and just drop in >>>> one of those without a delegate for when creating the accessor for >>>> methods/ctors on anonymous classes. >>> Even better. I would name the new class NativeMethodAccessorImpl and >>> the one doing inflation InflatingNativeMethodAccessorImpl which >>> would extend NativeMethodAccessorImpl, override invoke() and call >>> super.invoke()... This way, no native methods duplication is needed. >>> invoke() is already an interface method with 2 implementations. Now >>> it will have 3. Does this present any difference for dispatch >>> optimization? >>> >> FWIW i think the magic number is 4, but I don't know where I got >> that. Anyhow, this might be slightly controversial, but for all code >> I care about (reflective invocation of methods/ctors on >> non-VM-anonymous classes) the check happens exactly once as is. > > No, the magic number is 2 (by default), > you can look for TypeProfileWidth in the vm code. I forgot that each generated method accessor is a separate class with a separate method. So the number of implementations is already much more than 2 today... Regards, Peter > > regards, > R?mi > From aleksej.efimov at oracle.com Wed Nov 6 19:11:46 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 06 Nov 2013 23:11:46 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <527933E9.3030707@oracle.com> References: <52791F14.2080305@oracle.com> <52792FF2.4050606@oracle.com> <527933E9.3030707@oracle.com> Message-ID: <527A9472.9070403@oracle.com> Hi, We have a fix for JDK-8027848 and it was approved in parallel thread. With '-XX:-UseMathExactIntrinsics' tests run flag and applied fix for JDK-8027848 all tests from the following test sets are passing: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter. I suppose, that we're good to go with this change, unless there are some comments or issues. -Aleksej On 11/05/2013 10:07 PM, Aleksej Efimov wrote: > Alan, > Thank you for advise. > I have executed the same test sets with -XX:-UseMathExactIntrinsics > and, as was expected, there is only one failure: > sun/util/calendar/zi/TestZoneInfo310.java. > > -Aleksej > > On 11/05/2013 09:50 PM, Alan Bateman wrote: >> On 05/11/2013 16:38, Aleksej Efimov wrote: >>> Hi, >>> >>> Can I have a review for tzdata2013h integration [1]. The webrev link >>> can be located here [2]. >>> >>> The following test sets were executed on build with fix: >>> test/sun/util/calendar test/java/util/Calendar >>> test/sun/util/resources/TimeZone test/sun/util/calendar >>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>> >>> And here is the list of failures: >>> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >>> FAILED: java/time/tck/java/time/TCKInstant.java %1% >>> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >>> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >>> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >>> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >>> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >>> FAILED: >>> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >>> FAILED: java/util/Calendar/JavatimeTest.java %1% >>> >>> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >>> >>> >>> The group %1% tests failures relates to the JDK-8027622 bug and are >>> expected (actually, it was already resolved in hotspot repo). >> In another thread, Amy Lu is updating the ProblemList.txt to exclude >> these tests until the hotspot fix gets to jdk8/tl. For your testing >> then you could run with -XX:-UseMathExactIntrinsics and check that >> the all tests related to time and time zones are passing. >> >> -Alan. > From aleksej.efimov at oracle.com Wed Nov 6 19:15:41 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 06 Nov 2013 23:15:41 +0400 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <527A7A01.3010301@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> <52797D6F.3080209@oracle.com> <527A7A01.3010301@oracle.com> Message-ID: <527A955D.8090407@oracle.com> Sherman, thank you for reviewing it! -Aleksej On 11/06/2013 09:18 PM, Xueming Shen wrote: > Looks fine. > > thanks! > -Sherman > > On 11/05/2013 03:21 PM, Aleksej Efimov wrote: >> Sherman, >> Thank you for a quick review. I totally agree with you on all items. >> Actually, I missed fact that the transitions are sorted. And yes - >> the change can be done on line #431. >> The new tested fix can be found here: >> http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ >> >> >> -Aleksej >> >> On 11/05/2013 10:58 PM, Xueming Shen wrote: >>> On 11/05/2013 10:50 AM, Xueming Shen wrote: >>>> Aleksej, >>>> >>>> For better performance >>>> (1) the currT should be "static final" so we dont have to access the >>>> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >>>> (2) instead of iterating through the standardTransitions(), >>>> shouldn't we just >>>> check the last one? given it's a sorted list. >>> >>> and maybe this willGMTOffsetChange setting can be done just at >>> line#431. >>> >>> -Sherman >>> >>>> >>>> btw, in theory, the change now uses the "current vm starttime" >>>> instead of >>>> the "tzdb generated" time. But it should be fine, given >>>> ZoneInfo.getRawOffset() >>>> will just do a search for the current rawoffset. I may consider to >>>> add the >>>> "generated time" into the tzdb.dat in the future, if desired. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>>>> Hi, >>>>> Can I have a review for a 8027848 [1] bug fix . There is >>>>> unimplemented functionality related to the future GMT offset changes. >>>>> The ZoneInfoFile class doesn't analyses if there is such offset >>>>> changes and as a result incorrectly creates the ZoneInfo instance. >>>>> It was discovered during the TestZoneInfo310 test execution as >>>>> part of tzdata2013h update [3]. >>>>> >>>>> Thanks, >>>>> Aleksej >>>>> >>>>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>>>> [2] Proposed fix: >>>>> http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>>>> [3] tzdata2013h review thread: >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >>>> >>> >> > From peter.levart at gmail.com Wed Nov 6 19:30:25 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 06 Nov 2013 20:30:25 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> Message-ID: <527A98D1.4080906@gmail.com> On 11/05/2013 10:10 AM, Brian Goetz wrote: > Ineexof(char) sounds like as fast and simpler? Well, indexOf(char) or lastIndexOf(char) searches for a single char. We can do better searching backwards for two chars at the same time. If the "name" of VM-anonymous class is always ending with pattern: "slash followed by some decimal digits" then the following would be even faster: public static boolean isVMAnonymousClassFAST(Class cls) { String name = cls.getName(); for (int i = name.length() - 1; i >= 0; i--) { char c = name.charAt(i); if (c == '/') 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 > wrote: > >> On 11/04/2013 07:12 PM, robert.field at 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 serialization fails once reflection proxy generation kicks in >>> Reviewed-by: ksrini, briangoetz, jfranck >>> Contributed-by:joel.franck at oracle.com,brian.goetz at oracle.com,robert.field at oracle.com >>> >>> ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java >>> ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java >>> ! src/share/classes/sun/reflect/misc/ReflectUtil.java >>> + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java >>> ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java >>> + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java >>> >> Hi Robert, >> >> I also propose a much faster variant of: >> >> + /** >> + * Checks if {@code Class cls} is a VM-anonymous class >> + * as defined by {@link sun.misc.Unsafe#defineAnonymousClass} >> + * (not to be confused with a Java Language anonymous inner class). >> + */ >> + public static boolean isVMAnonymousClass(Class cls) { >> + return cls.getSimpleName().contains("/"); >> + } >> >> >> The following: >> >> public static boolean isVMAnonymousClassFAST(Class cls) { >> String name = cls.getName(); >> for (int i = name.length() - 1; i >= 0; i--) { >> char c = name.charAt(i); >> if (c == '.') return false; >> if (c == '/') return true; >> } >> return false; // root package >> } >> >> It's about 12..25x faster for typical class names and doesn't produce >> any garbage. >> >> >> Regards, Peter >> From mike.duigou at oracle.com Wed Nov 6 20:40:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Nov 2013 12:40:25 -0800 Subject: RFR: 8020779 & 8026988 : Improvements to JTReg executable location handling Message-ID: Hello all; With JDK-8015068 only very recently pushed it's time for the next set of jtreg test/Makfile changes. These changes improve the configure script detection of jtreg and improve the handling of the specification variables in the jdk and langtools test/Makefiles. This changeset is also the first step in syncing the two test/Makefiles. More will follow which will further simplify the integration of testing into the overall build/test process. http://cr.openjdk.java.net/~mduigou/JDK-8020779/0/webrev/ Mike From dan.xu at oracle.com Wed Nov 6 21:26:25 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 06 Nov 2013 21:26:25 +0000 Subject: hg: jdk8/tl/jdk: 8025698: (fs) Typo in exception thrown by encode() in UnixPath.java Message-ID: <20131106212658.DEC6E623DA@hg.openjdk.java.net> Changeset: 6ea1f9d8ec78 Author: dxu Date: 2013-11-06 13:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ea1f9d8ec78 8025698: (fs) Typo in exception thrown by encode() in UnixPath.java Reviewed-by: dxu, mduigou, henryjen, weijun Contributed-by: ajuckel at gmail.com ! src/solaris/classes/sun/nio/fs/UnixPath.java From kumar.x.srinivasan at oracle.com Wed Nov 6 23:34:56 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 06 Nov 2013 23:34:56 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131106233521.C1A77623E4@hg.openjdk.java.net> Changeset: 81cbdd5876e8 Author: ksrini Date: 2013-11-06 11:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81cbdd5876e8 8027227: [asm] generate CONSTANT_InterfaceMethodref for invoke{special/static) of non-abstract methods on ifaces Reviewed-by: ksrini, lagergren Contributed-by: ebruneton at free.fr, forax at univ-mlv.fr, john.r.rose at oracle.com, paul.sandoz at oracle.com ! src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handle.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/version.txt Changeset: dbda97d6aa3a Author: ksrini Date: 2013-11-06 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dbda97d6aa3a 8027232: Update j.l.invoke code generating class files to use ASM enhancements for invocation of non-abstract methods on ifaces Reviewed-by: ksrini, rfield Contributed-by: john.r.rose at oracle.com, paul.sandoz at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaAsm.java From john.r.rose at oracle.com Thu Nov 7 01:20:39 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Nov 2013 17:20:39 -0800 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <527A98D1.4080906@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> <527A98D1.4080906@gmail.com> Message-ID: <5AAEA553-6A71-43FD-A7BA-A001BA2D5128@oracle.com> On Nov 6, 2013, at 11:30 AM, Peter Levart 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. > > If the "name" of VM-anonymous class is always ending with pattern: "slash followed by some decimal digits" then the following would be even faster: Although this reasoning is plausible, it is not a reliable conclusion, and should not drive edits of Java code without careful measurement. The reasoning assumes a performance model based on the interpreter and bytecode count. But performance depends on native code produced by the JIT. An optimizing JIT will usually transform the code deeply. For string scanning, for example, HotSpot has an intrinsic for String.indexOf(String) that uses totally different code from a user-coded loop. (It is not currently so for String.indexOf(int), but String.indexOf("/") is potentially very fast.) Also, with your example code, the combined loop may often be faster than two back-to-back loops, but simpler loops can sometimes be vectorized more robustly, to the point where back-to-back simple loops, if vectorized, may be competitive with a hand-fused loop. So loop complexity and method intrinsics can create surprises for those who rely on simple performance modesl Some day we will get to a world where loops are specified stream-wise, and robustly optimized without this sort of manual intervention. In the mean time, be careful about advising hand-optimizations of Java code. They can backfire, by confusing the JIT and preventing optimizations that would apply to simpler code. ? John From stuart.marks at oracle.com Thu Nov 7 01:31:37 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 06 Nov 2013 17:31:37 -0800 Subject: RFR: 7174936: several String methods claim to always create new String Message-ID: <527AED79.2010702@oracle.com> Hi all, Please review the following spec changes to java.lang.String. In several places the specs mention returning "new" strings. This is overspecified; it's sufficient to return "a" string that satisfies the required properties. In some cases the current implementation doesn't create a new string -- for example, substring(0) returns 'this' -- which is strictly a violation of the spec. The solution is to relax the spec requirement to create new strings. Also, this change cleans up the specs for the copyValueOf() overloads to make them identical to the corresponding valueOf() overloads. Previously, they were gratuitously different. I think that some time in the dim, distant past, probably before JDK 1.0, they had different semantics, but now they're identical. The specs should say they're identical. This change is spec only, no code changes. Bug report: https://bugs.openjdk.java.net/browse/jdk-7174936 Webrev: http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html Thanks! s'marks From vitalyd at gmail.com Thu Nov 7 01:32:26 2013 From: vitalyd at gmail.com (Boris Davidovich) Date: Wed, 6 Nov 2013 20:32:26 -0500 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5AAEA553-6A71-43FD-A7BA-A001BA2D5128@oracle.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> <527A98D1.4080906@gmail.com> <5AAEA553-6A71-43FD-A7BA-A001BA2D5128@oracle.com> Message-ID: John, Just curious here - the String.indexOf(String) will have to fetch the arg string from memory somewhere (how are constant pool entries handled by the way? Is their address patched in or is it a lookup into the StringTable?). If it's not in cache, that could be tens if not hundreds of cycles. With char, the search value is an immediate so no additional mem fetches. For short strings (I'm assuming this case falls into that category) I don't think intrinsic is all that beneficial given that it can miss on memory. I agree that measurement is needed, but mental model (even taking intrinsic into account) seems to imply that char code would run faster, especially if searching backwards is more likely to terminate loop sooner. Am I missing something? Thanks Sent from my phone On Nov 6, 2013 8:21 PM, "John Rose" wrote: > On Nov 6, 2013, at 11:30 AM, Peter Levart 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. > > > > If the "name" of VM-anonymous class is always ending with pattern: > "slash followed by some decimal digits" then the following would be even > faster: > > Although this reasoning is plausible, it is not a reliable conclusion, and > should not drive edits of Java code without careful measurement. The > reasoning assumes a performance model based on the interpreter and bytecode > count. But performance depends on native code produced by the JIT. > > An optimizing JIT will usually transform the code deeply. For string > scanning, for example, HotSpot has an intrinsic for String.indexOf(String) > that uses totally different code from a user-coded loop. (It is not > currently so for String.indexOf(int), but String.indexOf("/") is > potentially very fast.) > > Also, with your example code, the combined loop may often be faster than > two back-to-back loops, but simpler loops can sometimes be vectorized more > robustly, to the point where back-to-back simple loops, if vectorized, may > be competitive with a hand-fused loop. > > So loop complexity and method intrinsics can create surprises for those > who rely on simple performance modesl > > Some day we will get to a world where loops are specified stream-wise, and > robustly optimized without this sort of manual intervention. In the mean > time, be careful about advising hand-optimizations of Java code. They can > backfire, by confusing the JIT and preventing optimizations that would > apply to simpler code. > > ? John From david.holmes at oracle.com Thu Nov 7 01:51:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 11:51:25 +1000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527A2F40.7020200@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <527996BE.3060003@oracle.com> <527A2F40.7020200@oracle.com> Message-ID: <527AF21D.1070907@oracle.com> On 6/11/2013 10:00 PM, Rob McKenna wrote: > Hi David, > > The only difference in 5049299 is the change in the default property > value in Solaris. Apologies for not making that clear. Given this was primarily aimed at Solaris in the first place it seems strange to me to not make the change on Solaris. If this is considered risky fr an update release then I would think that applies to all platforms equally. ?? If Solaris is not in fact changing then the comment in src/solaris/native/java/lang/UNIXProcess_md.c needs to be altered: * Based on the above analysis, we are currently using vfork() on ! * Linux and spawn() on other Unix systems, but the code to use clone() ! * and fork() remains. David ----- > -Rob > > On 06/11/13 01:09, David Holmes wrote: >> Hi Rob, >> >> How different is this to the JDK 8 version? >> >> Thanks, >> David >> >> On 6/11/2013 7:24 AM, Rob McKenna wrote: >>> .. >>> >>> http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ >>> >>> -Rob >>> >>> On 05/11/13 21:23, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> I'd like to backport this change to JDK7. Note: this fix uses >>>> posix_spawn by default on Mac OSX only. On Solaris fork will remain >>>> the default behaviour. >>>> >>>> I've just noticed that there is a problem with the testcase on Solaris >>>> in that it will test fork twice. (and won't test posix_spawn) I'll >>>> figure out a way around this, but in the mean time I'd like to get the >>>> ball rolling on this review anyway. >>>> >>>> -Rob >>>> >>>> >>> > From david.holmes at oracle.com Thu Nov 7 02:15:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 12:15:03 +1000 Subject: RFR: 7174936: several String methods claim to always create new String In-Reply-To: <527AED79.2010702@oracle.com> References: <527AED79.2010702@oracle.com> Message-ID: <527AF7A7.40602@oracle.com> Hi Stuart, On 7/11/2013 11:31 AM, Stuart Marks wrote: > Hi all, > > Please review the following spec changes to java.lang.String. > > In several places the specs mention returning "new" strings. This is > overspecified; it's sufficient to return "a" string that satisfies the > required properties. In some cases the current implementation doesn't > create a new string -- for example, substring(0) returns 'this' -- which > is strictly a violation of the spec. The solution is to relax the spec > requirement to create new strings. Or modify it as per concat - which is spec'd to return this when you concat an empty string. But I suppose in principle this allows for reuse of existing String objects. > Also, this change cleans up the specs for the copyValueOf() overloads to > make them identical to the corresponding valueOf() overloads. > Previously, they were gratuitously different. I think that some time in > the dim, distant past, probably before JDK 1.0, they had different > semantics, but now they're identical. The specs should say they're > identical. Don't we normally express this as "Equivalent to ..." rather than "Identical to ..." - the latter seems like an overspecification. > > This change is spec only, no code changes. Surely this change invalidates any tests that check for "new" strings as per the spec? They won't start failing but they will no longer be valid test. That aside subSequence is specified by CharSequence to return a new CharSequence. So I don't think you can simply remove that requirement. Cheers, David ----- > Bug report: > > https://bugs.openjdk.java.net/browse/jdk-7174936 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html > > > Thanks! > > s'marks From patrick.zhang at oracle.com Thu Nov 7 03:48:02 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Thu, 07 Nov 2013 11:48:02 +0800 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> Message-ID: <527B0D72.703@oracle.com> Hi Everyone, I am working on https://bugs.openjdk.java.net/browse/JDK-8019502. The problem is, some java.util test does use ${TESTVMOPTS} to launch java program in script. Then it may lose VM setting from high level. The fix will refer to https://bugs.openjdk.java.net/browse/JDK-8003890 finished by Mark Sheppard. Just add ${TESTVMOPTS} to launch java. Regards Patrick From martinrb at google.com Thu Nov 7 04:03:18 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Nov 2013 20:03:18 -0800 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527961D3.4080004@oracle.com> References: <527961D3.4080004@oracle.com> Message-ID: I did some review work on this in the past, but I don't have any opinion on whether it should be backported to jdk7 or not, risk/benefit-wise. I can imagine some users might care a great deal, as we did for running on Linux. On Tue, Nov 5, 2013 at 1:23 PM, Rob McKenna wrote: > Hi folks, > > I'd like to backport this change to JDK7. Note: this fix uses posix_spawn > by default on Mac OSX only. On Solaris fork will remain the default > behaviour. > > I've just noticed that there is a problem with the testcase on Solaris in > that it will test fork twice. (and won't test posix_spawn) I'll figure out > a way around this, but in the mean time I'd like to get the ball rolling on > this review anyway. > > -Rob > > > From amy.lu at oracle.com Thu Nov 7 04:29:32 2013 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 07 Nov 2013 12:29:32 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <5279AD32.40907@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> Message-ID: <527B172C.1020803@oracle.com> On 11/6/13 10:45 AM, Amy Lu wrote: > On 11/5/13 7:09 PM, Amy Lu wrote: >> On 11/5/13 6:01 PM, Alan Bateman wrote: >>> On 05/11/2013 09:26, Amy Lu wrote: >>>> : >>>> >>>> Please review ProblemList.txt changes: >>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>> >>> This looks okay to me although I'm not sure about >>> sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej >>> fixed the test and also excluded it, pending a decision/discussion >>> on whether this test should be removed). > > Aleksej, > > Should this test be removed from ProblemList? > > Thanks, > Amy > >>> >>> Should we use the opportunity to add all the tests that are failing >>> due to the exact math intrinsic (JDK-8027622)? >>> >>> -Alan. >> >> Added 8027622 and affected tests into ProblemList: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >> >> >> Thanks, >> Amy > If it's pending decision on whether sun/util/resources/TimeZone/Bug6317929.java should be removed, maybe it can be updated in separate change. I'm adding it back to ProblemList and here's the updated changes: https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.02/index.html Thanks, Amy From john.r.rose at oracle.com Thu Nov 7 04:35:05 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Nov 2013 20:35:05 -0800 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> <527A98D1.4080906@gmail.com> <5AAEA553-6A71-43FD-A7BA-A001BA2D5128@oracle.com> Message-ID: <6A6625E5-57F7-416B-B0C2-81FACE3B71FF@oracle.com> On Nov 6, 2013, at 5:32 PM, Boris Davidovich wrote: > Am I missing something? > The intrinsic would be looking at a constant string. ? John From stuart.marks at oracle.com Thu Nov 7 08:12:35 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 07 Nov 2013 00:12:35 -0800 Subject: RFR: 7174936: several String methods claim to always create new String In-Reply-To: <527AF7A7.40602@oracle.com> References: <527AED79.2010702@oracle.com> <527AF7A7.40602@oracle.com> Message-ID: <527B4B73.2040400@oracle.com> On 11/6/13 6:15 PM, David Holmes wrote: > On 7/11/2013 11:31 AM, Stuart Marks wrote: >> In several places the specs mention returning "new" strings. This is >> overspecified; it's sufficient to return "a" string that satisfies the >> required properties. In some cases the current implementation doesn't >> create a new string -- for example, substring(0) returns 'this' -- which >> is strictly a violation of the spec. The solution is to relax the spec >> requirement to create new strings. > > Or modify it as per concat - which is spec'd to return this when you concat an > empty string. > > But I suppose in principle this allows for reuse of existing String objects. I'm mainly interested in relaxing the spec, allowing the implementation maximum freedom to choose whether to create a new string or return a pre-existing instance such as 'this', instead of requiring one way or the other. The concat() method is weird in that if the arg is empty, it requires returning 'this'; but if 'this' is empty, it requires creating a new String instead of just returning the arg. I think this is overspecified. But the implementation follows this exactly, so I didn't want to change the spec in this case. Maybe later. >> Also, this change cleans up the specs for the copyValueOf() overloads to >> make them identical to the corresponding valueOf() overloads. >> Previously, they were gratuitously different. I think that some time in >> the dim, distant past, probably before JDK 1.0, they had different >> semantics, but now they're identical. The specs should say they're >> identical. > > Don't we normally express this as "Equivalent to ..." rather than "Identical to > ..." - the latter seems like an overspecification. Yes, "Equivalent to..." is better; I'll change it. > Surely this change invalidates any tests that check for "new" strings as per the > spec? They won't start failing but they will no longer be valid test. For methods where the implementation violates the spec by not returning a new instance, any tests that exist for these cases would be failing, so I'd think we'd have heard about this already. So perhaps such tests don't exist. For methods where the implementation does return a new string, relaxing the spec may indeed invalidate tests that test for a new string. Such a test wouldn't actually fail until some future time when the implementation is changed. But yes, this change might have some impact on the JCK. This is going through the normal internal review process (CCC) though, so the JCK team should be properly informed of the change. > That aside subSequence is specified by CharSequence to return a new > CharSequence. So I don't think you can simply remove that requirement. Oh yes, good catch. I had originally modified subSequence to change all the mentions of CharSequence to String -- since String.subSequence() merely calls String.substring(). After talking to Mike Duigou about this we decided that it would be better to leave these all as CharSequence. I changed them all back, but I missed this one in the @return clause. I'll fix this too. Thanks, s'marks > Cheers, > David > ----- > >> Bug report: >> >> https://bugs.openjdk.java.net/browse/jdk-7174936 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html >> >> >> >> Thanks! >> >> s'marks From peter.levart at gmail.com Thu Nov 7 08:36:14 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 07 Nov 2013 09:36:14 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5AAEA553-6A71-43FD-A7BA-A001BA2D5128@oracle.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> <8A0932AA-6460-4E9D-8C31-3B3D26A0F2DF@oracle.com> <527A98D1.4080906@gmail.com> <5AAEA553-6A71-43FD-A7BA-A001BA2D5128@oracle.com> Message-ID: <527B50FE.6080508@gmail.com> On 11/07/2013 02:20 AM, John Rose wrote: > On Nov 6, 2013, at 11:30 AM, Peter Levart > 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. >> >> If the "name" of VM-anonymous class is always ending with pattern: >> "slash followed by some decimal digits" then the following would be >> even faster: > > Although this reasoning is plausible, it is not a reliable conclusion, > and should not drive edits of Java code without careful measurement. > The reasoning assumes a performance model based on the interpreter > and bytecode count. But performance depends on native code produced > by the JIT. I agree. I should have measured it... > > An optimizing JIT will usually transform the code deeply. For string > scanning, for example, HotSpot has an intrinsic for > String.indexOf(String) that uses totally different code from a > user-coded loop. (It is not currently so for String.indexOf(int), but > String.indexOf("/") is potentially very fast.) > > Also, with your example code, the combined loop may often be faster > than two back-to-back loops, but simpler loops can sometimes be > vectorized more robustly, to the point where back-to-back simple > loops, if vectorized, may be competitive with a hand-fused loop. > > So loop complexity and method intrinsics can create surprises for > those who rely on simple performance modesl > > Some day we will get to a world where loops are specified stream-wise, > and robustly optimized without this sort of manual intervention. In > the mean time, be careful about advising hand-optimizations of Java > code. They can backfire, by confusing the JIT and preventing > optimizations that would apply to simpler code. > > ? John So I did measure it. I took two classes with the following names: com.test.pkg.PerfTest$Classic$1 com.test.pkg.PerfTest$$Lambda$1/925858445 Typically package names will be even relatively longer than in this example. I measured the following implementations: public static boolean isVMAnonymousClass(Class cls) { return cls.getSimpleName().contains("/"); } public static boolean isVMAnonymousClass_FAST1(Class cls) { String name = cls.getName(); for (int i = name.length() - 1; i >= 0; i--) { char c = name.charAt(i); if (c == '.') return false; if (c == '/') return true; } return false; } public static boolean isVMAnonymousClass_FAST2(Class cls) { String name = cls.getName(); for (int i = name.length() - 1; i >= 0; i--) { char c = name.charAt(i); if (c == '/') return true; if (c < '0' || c > '9') return false; } return false; } public static boolean isVMAnonymousClass_indexOf(Class cls) { return cls.getName().indexOf("/") > -1; } I also tried String.lastIndexOf(String) and it is a little faster for true return, since it only scans backwards until the "/" is found, but it is slower than String.indexOf(String) for "false" return. Is it not intrinsified? Here are the results: http://cr.openjdk.java.net/~plevart/jdk8-tl/isVmAnonymousClass/results.txt I think that any of the above implementations that doesn't use Class.getSimpleName() is good. The FAST2 variant is favourable for false return since it typically decides after examining a single character at end of class name and is still among the fastest for true return... Here's the code I used for testing: http://cr.openjdk.java.net/~plevart/jdk8-tl/isVmAnonymousClass/com/test/pkg/PerfTest.java http://cr.openjdk.java.net/~plevart/jdk8-tl/isVmAnonymousClass/si/pele/microbench/TestRunner.java Regards, Peter From chris.hegarty at oracle.com Thu Nov 7 09:06:07 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 07 Nov 2013 09:06:07 +0000 Subject: hg: jdk8/tl/jdk: 8027822: ProblemList.txt Updates (11/2013) Message-ID: <20131107090621.4C161623EC@hg.openjdk.java.net> Changeset: f37d62e295c0 Author: chegar Date: 2013-11-07 08:04 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f37d62e295c0 8027822: ProblemList.txt Updates (11/2013) Reviewed-by: chegar, alanb Contributed-by: Amy Lu ! test/ProblemList.txt From Alan.Bateman at oracle.com Thu Nov 7 09:07:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 09:07:34 +0000 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527B0D72.703@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> Message-ID: <527B5856.8090301@oracle.com> On 07/11/2013 03:48, Patrick Zhang wrote: > Hi Everyone, > > I am working on https://bugs.openjdk.java.net/browse/JDK-8019502. The > problem is, some java.util test does use ${TESTVMOPTS} to launch java > program in script. Then it may lose VM setting from high level. > > The fix will refer to https://bugs.openjdk.java.net/browse/JDK-8003890 > finished by Mark Sheppard. Just add ${TESTVMOPTS} to launch java. Did you intend to include a link to a patch? -Alan. From chris.hegarty at oracle.com Thu Nov 7 09:09:51 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Nov 2013 09:09:51 +0000 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <527B172C.1020803@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> <527B172C.1020803@oracle.com> Message-ID: <527B58DF.8080900@oracle.com> Sorry for the delay Amy. Trivially, 'windows-amd64, solaris-amd64, linux-amd64, macosx-all' was not matching the 64bit versions of these OSes, neither was s/amd64/x64/. So I changed it to generic-all for now. I did run into this myself a while back, but can't remember the correct labels. Not to worry, these are temporary additions and will be removed in a few weeks. Thanks, -Chris. On 11/07/2013 04:29 AM, Amy Lu wrote: > > On 11/6/13 10:45 AM, Amy Lu wrote: >> On 11/5/13 7:09 PM, Amy Lu wrote: >>> On 11/5/13 6:01 PM, Alan Bateman wrote: >>>> On 05/11/2013 09:26, Amy Lu wrote: >>>>> : >>>>> >>>>> Please review ProblemList.txt changes: >>>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>>> >>>> This looks okay to me although I'm not sure about >>>> sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej >>>> fixed the test and also excluded it, pending a decision/discussion >>>> on whether this test should be removed). >> >> Aleksej, >> >> Should this test be removed from ProblemList? >> >> Thanks, >> Amy >> >>>> >>>> Should we use the opportunity to add all the tests that are failing >>>> due to the exact math intrinsic (JDK-8027622)? >>>> >>>> -Alan. >>> >>> Added 8027622 and affected tests into ProblemList: >>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >>> >>> >>> Thanks, >>> Amy >> > If it's pending decision on whether > sun/util/resources/TimeZone/Bug6317929.java should be removed, maybe it > can be updated in separate change. > > I'm adding it back to ProblemList and here's the updated changes: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.02/index.html > > > Thanks, > Amy > From amy.lu at oracle.com Thu Nov 7 09:17:44 2013 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 07 Nov 2013 17:17:44 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <527B58DF.8080900@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> <527B172C.1020803@oracle.com> <527B58DF.8080900@oracle.com> Message-ID: <527B5AB8.9070904@oracle.com> Thank you Chris ! /Amy On 11/7/13 5:09 PM, Chris Hegarty wrote: > Sorry for the delay Amy. > > Trivially, 'windows-amd64, solaris-amd64, linux-amd64, macosx-all' was > not matching the 64bit versions of these OSes, neither was > s/amd64/x64/. So I changed it to generic-all for now. I did run into > this myself a while back, but can't remember the correct labels. Not > to worry, these are temporary additions and will be removed in a few > weeks. > > Thanks, > -Chris. > > On 11/07/2013 04:29 AM, Amy Lu wrote: >> >> On 11/6/13 10:45 AM, Amy Lu wrote: >>> On 11/5/13 7:09 PM, Amy Lu wrote: >>>> On 11/5/13 6:01 PM, Alan Bateman wrote: >>>>> On 05/11/2013 09:26, Amy Lu wrote: >>>>>> : >>>>>> >>>>>> Please review ProblemList.txt changes: >>>>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>>>> >>>>>> >>>>> This looks okay to me although I'm not sure about >>>>> sun/util/resources/TimeZone/Bug6317929.java (for some reason Aleksej >>>>> fixed the test and also excluded it, pending a decision/discussion >>>>> on whether this test should be removed). >>> >>> Aleksej, >>> >>> Should this test be removed from ProblemList? >>> >>> Thanks, >>> Amy >>> >>>>> >>>>> Should we use the opportunity to add all the tests that are failing >>>>> due to the exact math intrinsic (JDK-8027622)? >>>>> >>>>> -Alan. >>>> >>>> Added 8027622 and affected tests into ProblemList: >>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >>>> >>>> >>>> >>>> Thanks, >>>> Amy >>> >> If it's pending decision on whether >> sun/util/resources/TimeZone/Bug6317929.java should be removed, maybe it >> can be updated in separate change. >> >> I'm adding it back to ProblemList and here's the updated changes: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.02/index.html >> >> >> >> Thanks, >> Amy >> From erik.joelsson at oracle.com Thu Nov 7 09:24:56 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 07 Nov 2013 10:24:56 +0100 Subject: RFR: 8020779 & 8026988 : Improvements to JTReg executable location handling In-Reply-To: References: Message-ID: <527B5C68.2030006@oracle.com> Hello Mike, I think this looks good. A couple of comments that don't necessarily call for any changes. The version check is commented out, when is it planned to be activated? I see you use 'which' as a fallback in the makefiles. Just be aware that we have had some trouble using the which command in the past. Sometimes on Solaris it gives unexpected output depending on your environment and the behavior on fail is different on various platforms and implementations. It looks like you are trying to handle all the weird cases though. /Erik On 2013-11-06 21:40, Mike Duigou wrote: > Hello all; > > With JDK-8015068 only very recently pushed it's time for the next set of jtreg test/Makfile changes. These changes improve the configure script detection of jtreg and improve the handling of the specification variables in the jdk and langtools test/Makefiles. This changeset is also the first step in syncing the two test/Makefiles. More will follow which will further simplify the integration of testing into the overall build/test process. > > http://cr.openjdk.java.net/~mduigou/JDK-8020779/0/webrev/ > > Mike From chris.hegarty at oracle.com Thu Nov 7 09:24:31 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 07 Nov 2013 09:24:31 +0000 Subject: hg: jdk8/tl/jdk: 8027961: Inet[4|6]Address native initializing code should check field/MethodID values Message-ID: <20131107092443.B985C623EF@hg.openjdk.java.net> Changeset: 82b276590b85 Author: chegar Date: 2013-11-07 08:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82b276590b85 8027961: Inet[4|6]Address native initializing code should check field/MethodID values Reviewed-by: michaelm, rriggs ! src/share/native/java/net/Inet4Address.c ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/InetAddress.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c From mike.duigou at oracle.com Thu Nov 7 09:34:19 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 7 Nov 2013 01:34:19 -0800 Subject: RFR: 8020779 & 8026988 : Improvements to JTReg executable location handling In-Reply-To: <527B5C68.2030006@oracle.com> References: <527B5C68.2030006@oracle.com> Message-ID: <02ABED68-7E4E-4CA0-B3FB-0199D61F4EAD@oracle.com> On Nov 7 2013, at 01:24 , Erik Joelsson wrote: > Hello Mike, > > I think this looks good. A couple of comments that don't necessarily call for any changes. > > The version check is commented out, when is it planned to be activated? I was working on this piece at the same time as a the "make version 4.0" discussion was happening and I wanted to wait for the solution used there and reapply it. I can complete this code before commit. > > I see you use 'which' as a fallback in the makefiles. Just be aware that we have had some trouble using the which command in the past. Sometimes on Solaris it gives unexpected output depending on your environment and the behavior on fail is different on various platforms and implementations. It looks like you are trying to handle all the weird cases though. The pattern I used is copied from hgforest.sh where the problems were indeed previously encountered. I would prefer to have no fallback at all and plan to eventually remove it in a future changeset. The current fallback behaviour is intended to help with the transition from the old build system to the new build infrastructure and the variety of usage patterns for test/Makefile which are still being used. It will be a week or two before I try to finalize this changeset. Thanks, Mike > /Erik > > On 2013-11-06 21:40, Mike Duigou wrote: >> Hello all; >> >> With JDK-8015068 only very recently pushed it's time for the next set of jtreg test/Makfile changes. These changes improve the configure script detection of jtreg and improve the handling of the specification variables in the jdk and langtools test/Makefiles. This changeset is also the first step in syncing the two test/Makefiles. More will follow which will further simplify the integration of testing into the overall build/test process. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8020779/0/webrev/ >> >> Mike > From chris.hegarty at oracle.com Thu Nov 7 10:05:05 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Nov 2013 10:05:05 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) Message-ID: <527B65D1.8090400@oracle.com> Virus checkers and, on more modern Windows OSes, Windows Experience Service, and other external processes, have been causing trouble when it comes to tests deleting files. On a number of occasions in the past retry logic has been added to tests that need to delete files. Also, the jtreg harness has similar logic when cleaning up temporary files. This has reared its head again with: 8027902: TEST_BUG: java/net/URLClassLoader/closetest/CloseTest.java and java/net/URLClassLoader/closetest/GetResourceAsStream.java failed due to dir operation failed. 8022213: Intermittent test failures in java/net/URLClassLoader I'd like to add file utility functions to the common jdk/testlibrary, starting with a "more reliable" delete. I've made minimal changes to the URLClassloader tests to use this ( more could be done, but this is just a start ). http://cr.openjdk.java.net/~chegar/fileUtils/webrev/ The important part here for review is the "API" and impl in FileUtils. Thanks, -Chris. From magnus.ihse.bursie at oracle.com Thu Nov 7 10:09:01 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 07 Nov 2013 11:09:01 +0100 Subject: RFR: 8020779 & 8026988 : Improvements to JTReg executable location handling In-Reply-To: References: Message-ID: <527B66BD.50400@oracle.com> On 2013-11-06 21:40, Mike Duigou wrote: > Hello all; > > With JDK-8015068 only very recently pushed it's time for the next set of jtreg test/Makfile changes. These changes improve the configure script detection of jtreg and improve the handling of the specification variables in the jdk and langtools test/Makefiles. This changeset is also the first step in syncing the two test/Makefiles. More will follow which will further simplify the integration of testing into the overall build/test process. > > http://cr.openjdk.java.net/~mduigou/JDK-8020779/0/webrev/ I don't think the changes in toolchain.m4 does what you want it to do. The AC_ARG_WITH function is not really well designed. In particular, it is missing a "default" section. So if you use the functionality to execute code on "yes" and "no", then "no" will be the same wether or not you leave the option out alltogether, or try call it like --without-jtreg (or --with-jtreg=no, which is the same as --without). Our typical use pattern, to get around this, is to not execute any code in the AC_ARG_WITH function, and instead check the $with_argname option afterwards. There you can separate the different use patterns: * $with_argname=yes --> user explicitely set --with-argname (or --with-argname=yes) * $with_argname=no --> user explicitely set --without-argname (or --with-argname=no) * $with_argname= (empty) --> user did not specify flag at all; do default action. * $with_argname= --> user explicitely set --with-argname=, most likely trying to override a path. In this case, it will no longer be possible to explicitely disable jtreg with your changes. (If I read the code correctly -- I have not tried running it). Also, the pair AC_MSG_CHECKING and AC_MSG_RESULT needs to be close together. If any output arrives inbetween them, the output will look garbled, like: checking for foo... yes. checking for jtreg... Rewriting path for JT_HOME to /localhome/jthome yes. checking for bar... no. I tend to use the pair just consecutively after I actually found out what I was looking for, to avoid this. Then it's really just useful for the log output, not to show progress. If the test I'm about to make might take a non-significant amount of time, I might start by a AC_MSG_NOTICE([Trying to locate package foo]) or similar. Also, if the search failed, and a AC_MSG_CHECKING had been printed, an AC_MSG_RESULT([no]) should be printed before AC_MSG_ERROR. /Magnus From aleksej.efimov at oracle.com Thu Nov 7 10:36:25 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 07 Nov 2013 14:36:25 +0400 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <527B172C.1020803@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> <527B172C.1020803@oracle.com> Message-ID: <527B6D29.9050901@oracle.com> Hi Amy, This test is currently fixed and working as expected, but I have a desire to remove this test. In fact, this test (and my decision to fix and exclude it) already brings too many question, it doesn't do any helpful testing and all situation with adding fixed test to ProblemsList.txt looks awkward. I planned to remove it as part of JDK-8025051, but it will be resolved only in next 1-2 weeks. So, I suggest to exclude it from problems list and remove it now. Thank you, Aleksej On 11/07/2013 08:29 AM, Amy Lu wrote: > > On 11/6/13 10:45 AM, Amy Lu wrote: >> On 11/5/13 7:09 PM, Amy Lu wrote: >>> On 11/5/13 6:01 PM, Alan Bateman wrote: >>>> On 05/11/2013 09:26, Amy Lu wrote: >>>>> : >>>>> >>>>> Please review ProblemList.txt changes: >>>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>>> >>>> This looks okay to me although I'm not sure about >>>> sun/util/resources/TimeZone/Bug6317929.java (for some reason >>>> Aleksej fixed the test and also excluded it, pending a >>>> decision/discussion on whether this test should be removed). >> >> Aleksej, >> >> Should this test be removed from ProblemList? >> >> Thanks, >> Amy >> >>>> >>>> Should we use the opportunity to add all the tests that are failing >>>> due to the exact math intrinsic (JDK-8027622)? >>>> >>>> -Alan. >>> >>> Added 8027622 and affected tests into ProblemList: >>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >>> >>> >>> Thanks, >>> Amy >> > If it's pending decision on whether > sun/util/resources/TimeZone/Bug6317929.java should be removed, maybe > it can be updated in separate change. > > I'm adding it back to ProblemList and here's the updated changes: > https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.02/index.html > > > Thanks, > Amy > From amy.lu at oracle.com Thu Nov 7 10:43:59 2013 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 07 Nov 2013 18:43:59 +0800 Subject: RFR: 8027822: ProblemList.txt Updates (11/2013) In-Reply-To: <527B6D29.9050901@oracle.com> References: <5278B9D9.8010505@oracle.com> <5278C1E4.2070002@oracle.com> <5278D1EE.60404@oracle.com> <5279AD32.40907@oracle.com> <527B172C.1020803@oracle.com> <527B6D29.9050901@oracle.com> Message-ID: <527B6EEF.9050909@oracle.com> Thank you for confirm. And yes, removed. Thanks, Amy On 11/7/13 6:36 PM, Aleksej Efimov wrote: > Hi Amy, > This test is currently fixed and working as expected, but I have a > desire to remove this test. In fact, this test (and my decision to fix > and exclude it) already brings too many question, it doesn't do any > helpful testing and all situation with adding fixed test to > ProblemsList.txt looks awkward. I planned to remove it as part of > JDK-8025051, but it will be resolved only in next 1-2 weeks. So, I > suggest to exclude it from problems list and remove it now. > > Thank you, > Aleksej > > On 11/07/2013 08:29 AM, Amy Lu wrote: >> >> On 11/6/13 10:45 AM, Amy Lu wrote: >>> On 11/5/13 7:09 PM, Amy Lu wrote: >>>> On 11/5/13 6:01 PM, Alan Bateman wrote: >>>>> On 05/11/2013 09:26, Amy Lu wrote: >>>>>> : >>>>>> >>>>>> Please review ProblemList.txt changes: >>>>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev/index.html >>>>>> >>>>> This looks okay to me although I'm not sure about >>>>> sun/util/resources/TimeZone/Bug6317929.java (for some reason >>>>> Aleksej fixed the test and also excluded it, pending a >>>>> decision/discussion on whether this test should be removed). >>> >>> Aleksej, >>> >>> Should this test be removed from ProblemList? >>> >>> Thanks, >>> Amy >>> >>>>> >>>>> Should we use the opportunity to add all the tests that are >>>>> failing due to the exact math intrinsic (JDK-8027622)? >>>>> >>>>> -Alan. >>>> >>>> Added 8027622 and affected tests into ProblemList: >>>> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.01/index.html >>>> >>>> >>>> Thanks, >>>> Amy >>> >> If it's pending decision on whether >> sun/util/resources/TimeZone/Bug6317929.java should be removed, maybe >> it can be updated in separate change. >> >> I'm adding it back to ProblemList and here's the updated changes: >> https://dl.dropboxusercontent.com/u/5812451/yl153753/8027822/webrev.02/index.html >> >> >> Thanks, >> Amy >> > From michael.x.mcmahon at oracle.com Thu Nov 7 10:43:33 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 07 Nov 2013 10:43:33 +0000 Subject: hg: jdk8/tl/jdk: 8027881: test/java/net/URLPermission/nstest/LookupTest.java failing intermittently, output insufficient Message-ID: <20131107104346.E8CAB623F2@hg.openjdk.java.net> Changeset: 88d1ed05a246 Author: michaelm Date: 2013-11-07 10:22 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88d1ed05a246 8027881: test/java/net/URLPermission/nstest/LookupTest.java failing intermittently, output insufficient Reviewed-by: chegar ! test/java/net/URLPermission/URLPermissionTest.java ! test/java/net/URLPermission/nstest/LookupTest.java + test/java/net/URLPermission/nstest/lookup.sh - test/java/net/URLPermission/nstest/policy From michael.x.mcmahon at oracle.com Thu Nov 7 11:19:15 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 07 Nov 2013 11:19:15 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527B65D1.8090400@oracle.com> References: <527B65D1.8090400@oracle.com> Message-ID: <527B7733.1010101@oracle.com> Chris, Would it be useful to add some instrumentation/logging (to System.err) if it's taking more than one iteration to delete a file? We could end up with degraded test performance if there is a general problem deleting files, and otherwise would have no way of understanding what the problem is (eg. up to 7.5 seconds are allowed to delete the file) Also, just curious what is the value in throwing InterruptedException out of the delete() method? It seems onerous for calling code to have to catch it. Michael On 07/11/13 10:05, Chris Hegarty wrote: > Virus checkers and, on more modern Windows OSes, Windows Experience > Service, and other external processes, have been causing trouble when > it comes to tests deleting files. > > On a number of occasions in the past retry logic has been added to > tests that need to delete files. Also, the jtreg harness has similar > logic when cleaning up temporary files. > > This has reared its head again with: > 8027902: TEST_BUG: java/net/URLClassLoader/closetest/CloseTest.java > and java/net/URLClassLoader/closetest/GetResourceAsStream.java failed > due to dir operation failed. > 8022213: Intermittent test failures in java/net/URLClassLoader > > I'd like to add file utility functions to the common jdk/testlibrary, > starting with a "more reliable" delete. I've made minimal changes to > the URLClassloader tests to use this ( more could be done, but this is > just a start ). > > http://cr.openjdk.java.net/~chegar/fileUtils/webrev/ > > The important part here for review is the "API" and impl in FileUtils. > > Thanks, > -Chris. From Alan.Bateman at oracle.com Thu Nov 7 11:22:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 11:22:24 +0000 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <52791C93.1060600@oracle.com> References: <52738E00.2070806@oracle.com> <5274E3FF.3070807@oracle.com> <52791C93.1060600@oracle.com> Message-ID: <527B77F0.4050109@oracle.com> On 05/11/2013 16:28, Sergey Bylokhov wrote: > Hello, > Updated version: > http://cr.openjdk.java.net/~serb/8027696/webrev.01/ > Dates and spaces were fixed. Thanks Sergey, I sampled a few and they look correct. The only thing is that I'm not sure about is test/Makefile, it's just not clear whether which header this should have. -Alan From chris.hegarty at oracle.com Thu Nov 7 11:34:06 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Nov 2013 11:34:06 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527B7733.1010101@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> Message-ID: <527B7AAE.1090703@oracle.com> On 11/07/2013 11:19 AM, Michael McMahon wrote: > Chris, > > Would it be useful to add some instrumentation/logging (to System.err) > if it's taking > more than one iteration to delete a file? We could end up with degraded > test performance if there is a general problem deleting files, and > otherwise would have > no way of understanding what the problem is (eg. up to 7.5 seconds are > allowed to delete the file) I had an optional PrintStream param on delete/deleteTree, but removed it. If the file fails to delete, then you will see all the suppressed exceptions, but I agree if it fails a number of times and then succeeds you do not see this. I'm not sure that it is worth adding PrintStream ( and this is why I removed it ) since the external interference occurs infrequently and does not appear to last long. I just wanted to keep this as simply as possible, but I could be convinced to reintroduce it. > Also, just curious what is the value in throwing InterruptedException > out of the delete() method? > It seems onerous for calling code to have to catch it. Right handling this is a pain. Since we may now be possibly sleeping during a delete I wanted jtreg to be able to interrupt the test and have the test take correct action, rather than just swallowing it. It is really annoying to see hung tests in logs that do not respond to jtregs attempts to stop them. I've also received another comment offline about the method names. They should be more descriptive, and highlight the difference between these methods and regular delete. So maybe move to public deleteWithRetry? -Chris. > > Michael > > On 07/11/13 10:05, Chris Hegarty wrote: >> Virus checkers and, on more modern Windows OSes, Windows Experience >> Service, and other external processes, have been causing trouble when >> it comes to tests deleting files. >> >> On a number of occasions in the past retry logic has been added to >> tests that need to delete files. Also, the jtreg harness has similar >> logic when cleaning up temporary files. >> >> This has reared its head again with: >> 8027902: TEST_BUG: java/net/URLClassLoader/closetest/CloseTest.java >> and java/net/URLClassLoader/closetest/GetResourceAsStream.java failed >> due to dir operation failed. >> 8022213: Intermittent test failures in java/net/URLClassLoader >> >> I'd like to add file utility functions to the common jdk/testlibrary, >> starting with a "more reliable" delete. I've made minimal changes to >> the URLClassloader tests to use this ( more could be done, but this is >> just a start ). >> >> http://cr.openjdk.java.net/~chegar/fileUtils/webrev/ >> >> The important part here for review is the "API" and impl in FileUtils. >> >> Thanks, >> -Chris. > From Alan.Bateman at oracle.com Thu Nov 7 11:46:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 11:46:31 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527A4483.3040306@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <52796516.6010108@oracle.com> <527A0673.9000500@oracle.com> <527A4483.3040306@oracle.com> Message-ID: <527B7D97.4010701@oracle.com> On 06/11/2013 13:30, Rob McKenna wrote: > > Yes, absolutely. I'm looking for approval for the code in principle. > Particularly the change in the default property value on Solaris since > thats the only change. Once approved I will of course seek approval > for integration. > > Also, I will also integrate these changes separately and in order. > 8008118 has been sitting in my repository for some time and I totally > forgot about it until I looked at the webrev. > > -Rob Okay, so will you refresh the webrev and just highlight the differences from the jdk8 patch? -Alan. From michael.x.mcmahon at oracle.com Thu Nov 7 11:49:25 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 07 Nov 2013 11:49:25 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527B7AAE.1090703@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> <527B7AAE.1090703@oracle.com> Message-ID: <527B7E45.6030108@oracle.com> On 07/11/13 11:34, Chris Hegarty wrote: > On 11/07/2013 11:19 AM, Michael McMahon wrote: >> Chris, >> >> Would it be useful to add some instrumentation/logging (to System.err) >> if it's taking >> more than one iteration to delete a file? We could end up with degraded >> test performance if there is a general problem deleting files, and >> otherwise would have >> no way of understanding what the problem is (eg. up to 7.5 seconds are >> allowed to delete the file) > > I had an optional PrintStream param on delete/deleteTree, but removed > it. If the file fails to delete, then you will see all the suppressed > exceptions, but I agree if it fails a number of times and then > succeeds you do not see this. > > I'm not sure that it is worth adding PrintStream ( and this is why I > removed it ) since the external interference occurs infrequently and > does not appear to last long. I just wanted to keep this as simply as > possible, but I could be convinced to reintroduce it. > Personally, I would have thought System.err would be okay, but maybe there are tests that need to run without this kind of noise. I agree adding a PrintStream arg is not worth doing. >> Also, just curious what is the value in throwing InterruptedException >> out of the delete() method? >> It seems onerous for calling code to have to catch it. > > Right handling this is a pain. Since we may now be possibly sleeping > during a delete I wanted jtreg to be able to interrupt the test and > have the test take correct action, rather than just swallowing it. It > is really annoying to see hung tests in logs that do not respond to > jtregs attempts to stop them. > I wasn't suggesting to swallow the exception - rather to wrap it in an unchecked exception. The issue is really only whether callers need to distinguish this situation from the various other errors and environmental problems that will all probably cause a test to be interrupted/stopped. Michael > I've also received another comment offline about the method names. > They should be more descriptive, and highlight the difference between > these methods and regular delete. So maybe move to public > deleteWithRetry? > > -Chris. > >> >> Michael >> >> On 07/11/13 10:05, Chris Hegarty wrote: >>> Virus checkers and, on more modern Windows OSes, Windows Experience >>> Service, and other external processes, have been causing trouble when >>> it comes to tests deleting files. >>> >>> On a number of occasions in the past retry logic has been added to >>> tests that need to delete files. Also, the jtreg harness has similar >>> logic when cleaning up temporary files. >>> >>> This has reared its head again with: >>> 8027902: TEST_BUG: java/net/URLClassLoader/closetest/CloseTest.java >>> and java/net/URLClassLoader/closetest/GetResourceAsStream.java failed >>> due to dir operation failed. >>> 8022213: Intermittent test failures in java/net/URLClassLoader >>> >>> I'd like to add file utility functions to the common jdk/testlibrary, >>> starting with a "more reliable" delete. I've made minimal changes to >>> the URLClassloader tests to use this ( more could be done, but this is >>> just a start ). >>> >>> http://cr.openjdk.java.net/~chegar/fileUtils/webrev/ >>> >>> The important part here for review is the "API" and impl in FileUtils. >>> >>> Thanks, >>> -Chris. >> From joel.franck at oracle.com Thu Nov 7 12:35:37 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 07 Nov 2013 12:35:37 +0000 Subject: hg: jdk8/tl/jdk: 8027796: Refactor Core Reflection for Type Annotations Message-ID: <20131107123551.69603623FB@hg.openjdk.java.net> Changeset: 44fa6bf42846 Author: jfranck Date: 2013-11-07 13:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44fa6bf42846 8027796: Refactor Core Reflection for Type Annotations Reviewed-by: psandoz ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/TypeAnnotation.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java From joel.franck at oracle.com Thu Nov 7 13:20:07 2013 From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=) Date: Thu, 7 Nov 2013 14:20:07 +0100 Subject: RFR: JDK-8027796: Refactor Core Reflection for Type Annotations In-Reply-To: <57FC26A3-2AFD-4F15-A912-AE3521F2D812@oracle.com> References: <81B30411-8BD8-4A5A-BA97-C9A8D172DC3C@oracle.com> <57FC26A3-2AFD-4F15-A912-AE3521F2D812@oracle.com> Message-ID: <20131107132007.GA6241@oracle.com> Thanks for the review Paul cheers /Joel On 2013-11-05, Paul Sandoz wrote: > > On Nov 4, 2013, at 8:36 PM, Joel Borggr?n-Franck wrote: > > > Hi > > > > Please review this small refactoring of the type annotations reflection code. This fix just makes the types final since the code wasn't designed for inheritance. > > > > webrev: http://cr.openjdk.java.net/~jfranck/8027796/webrev.00/ > > jbs: https://bugs.openjdk.java.net/browse/JDK-8027796 > > > > +1 > > FWIW (take it or leave it) the "final" on AnnotatedTypeFactory.buildAnnotatedType is redundant since AnnotatedTypeFactory is final and thus cannot be overridden with another class that shadows the static method. > > Paul. From Alan.Bateman at oracle.com Thu Nov 7 13:24:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 13:24:12 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527B7AAE.1090703@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> <527B7AAE.1090703@oracle.com> Message-ID: <527B947C.3030405@oracle.com> On 07/11/2013 11:34, Chris Hegarty wrote: > : > > I've also received another comment offline about the method names. > They should be more descriptive, and highlight the difference between > these methods and regular delete. So maybe move to public > deleteWithRetry? That might be a bit better as otherwise it's not obvious how it differs from Files.delete. Also to keep the names consistent then deleteTreeWithRetry should probably be deleteFileTreeWithRetry. On interrupting the sleep then it looks like the methods aren't consistent, one will throw InterruptedException, the other will complete early without an exception and without the interrupt status set. If you want then you could extend SimpleFileVisitor instead, that would allow you to drop the preVisitDirectory method. A passing comment on closetest/Command is that the copyFile method could use Files.copy with REPLACE_EXISTING. Also rm_minus_rf (amusing name) doesn't need to use isFile or isDirectory as FilesUtil.deleteFIleTree will do the right thing. -Alan. From Sergey.Bylokhov at oracle.com Thu Nov 7 13:46:37 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 07 Nov 2013 17:46:37 +0400 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <527B77F0.4050109@oracle.com> References: <52738E00.2070806@oracle.com> <5274E3FF.3070807@oracle.com> <52791C93.1060600@oracle.com> <527B77F0.4050109@oracle.com> Message-ID: <527B99BD.8050401@oracle.com> On 07.11.2013 15:22, Alan Bateman wrote: > Thanks Sergey, I sampled a few and they look correct. > > The only thing is that I'm not sure about is test/Makefile, it's just > not clear whether which header this should have. I can skip it this time. -- Best regards, Sergey. From rob.mckenna at oracle.com Thu Nov 7 13:53:06 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 07 Nov 2013 13:53:06 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527AF21D.1070907@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <527996BE.3060003@oracle.com> <527A2F40.7020200@oracle.com> <527AF21D.1070907@oracle.com> Message-ID: <527B9B42.6030600@oracle.com> Ah, thanks for catching that David, I've updated the webrev in place. I believe the reasoning is that we want to minimise any potential impact to customers running in production. The general feeling seems to be that Mac is a development platform and is less likely to cause us problems in that regard. (not that I would anticipate any on Solaris, but I understand the desire to be conservative) -Rob On 07/11/13 01:51, David Holmes wrote: > On 6/11/2013 10:00 PM, Rob McKenna wrote: >> Hi David, >> >> The only difference in 5049299 is the change in the default property >> value in Solaris. Apologies for not making that clear. > > Given this was primarily aimed at Solaris in the first place it seems > strange to me to not make the change on Solaris. If this is considered > risky fr an update release then I would think that applies to all > platforms equally. ?? > > If Solaris is not in fact changing then the comment in > src/solaris/native/java/lang/UNIXProcess_md.c needs to be altered: > > * Based on the above analysis, we are currently using vfork() on > ! * Linux and spawn() on other Unix systems, but the code to use clone() > ! * and fork() remains. > > David > ----- > >> -Rob >> >> On 06/11/13 01:09, David Holmes wrote: >>> Hi Rob, >>> >>> How different is this to the JDK 8 version? >>> >>> Thanks, >>> David >>> >>> On 6/11/2013 7:24 AM, Rob McKenna wrote: >>>> .. >>>> >>>> http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ >>>> >>>> -Rob >>>> >>>> On 05/11/13 21:23, Rob McKenna wrote: >>>>> Hi folks, >>>>> >>>>> I'd like to backport this change to JDK7. Note: this fix uses >>>>> posix_spawn by default on Mac OSX only. On Solaris fork will remain >>>>> the default behaviour. >>>>> >>>>> I've just noticed that there is a problem with the testcase on >>>>> Solaris >>>>> in that it will test fork twice. (and won't test posix_spawn) I'll >>>>> figure out a way around this, but in the mean time I'd like to get >>>>> the >>>>> ball rolling on this review anyway. >>>>> >>>>> -Rob >>>>> >>>>> >>>> >> From sundararajan.athijegannathan at oracle.com Thu Nov 7 14:17:15 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 07 Nov 2013 14:17:15 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20131107141717.77C2F623FE@hg.openjdk.java.net> Changeset: 2f07b4234451 Author: sundar Date: 2013-11-07 17:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2f07b4234451 8027828: ClassCastException when converting return value of a Java method to boolean Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/JDK-8027828.js + test/script/basic/JDK-8027828.js.EXPECTED + test/script/basic/convert.js + test/script/basic/convert.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 3b794f364c77 Author: sundar Date: 2013-11-07 18:11 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3b794f364c77 Merge From rob.mckenna at oracle.com Thu Nov 7 13:52:47 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 7 Nov 2013 05:52:47 -0800 (PST) Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527B7D97.4010701@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <52796516.6010108@oracle.com> <527A0673.9000500@oracle.com> <527A4483.3040306@oracle.com> <527B7D97.4010701@oracle.com> Message-ID: <527B9B2F.4080606@oracle.com> I've added a review showing the differences to jdk8 to: http://cr.openjdk.java.net/~robm/5049299/7/webrev.02/ I've updated the previous webrev ( http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ ) in place to reflect the comment change. Note: still putting together a separate test which will call Basic.java with the correct parameters on each platform. -Rob On 07/11/13 11:46, Alan Bateman wrote: > On 06/11/2013 13:30, Rob McKenna wrote: >> >> Yes, absolutely. I'm looking for approval for the code in principle. >> Particularly the change in the default property value on Solaris >> since thats the only change. Once approved I will of course seek >> approval for integration. >> >> Also, I will also integrate these changes separately and in order. >> 8008118 has been sitting in my repository for some time and I totally >> forgot about it until I looked at the webrev. >> >> -Rob > Okay, so will you refresh the webrev and just highlight the > differences from the jdk8 patch? > > -Alan. From chris.hegarty at oracle.com Thu Nov 7 14:59:07 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Nov 2013 14:59:07 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527B947C.3030405@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> <527B7AAE.1090703@oracle.com> <527B947C.3030405@oracle.com> Message-ID: <527BAABB.7050202@oracle.com> Given both Michael and Alan's comments. I've update the webrev: http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/ 1) more descriptive method names 2) deleteXXX methods return if interrupted, leaving the interrupt status set 3) Use Files.copy with REPLACE_EXISTING 4) Use SimpleFileVisitor, rather than FileVisitor Thanks, -Chris. On 11/07/2013 01:24 PM, Alan Bateman wrote: > On 07/11/2013 11:34, Chris Hegarty wrote: >> : >> >> I've also received another comment offline about the method names. >> They should be more descriptive, and highlight the difference between >> these methods and regular delete. So maybe move to public >> deleteWithRetry? > That might be a bit better as otherwise it's not obvious how it differs > from Files.delete. Also to keep the names consistent then > deleteTreeWithRetry should probably be deleteFileTreeWithRetry. > > On interrupting the sleep then it looks like the methods aren't > consistent, one will throw InterruptedException, the other will complete > early without an exception and without the interrupt status set. > > If you want then you could extend SimpleFileVisitor instead, that would > allow you to drop the preVisitDirectory method. > > A passing comment on closetest/Command is that the copyFile method could > use Files.copy with REPLACE_EXISTING. > > Also rm_minus_rf (amusing name) doesn't need to use isFile or > isDirectory as FilesUtil.deleteFIleTree will do the right thing. > > -Alan. From Alan.Bateman at oracle.com Thu Nov 7 16:45:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 16:45:26 +0000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527B9B2F.4080606@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <52796516.6010108@oracle.com> <527A0673.9000500@oracle.com> <527A4483.3040306@oracle.com> <527B7D97.4010701@oracle.com> <527B9B2F.4080606@oracle.com> Message-ID: <527BC3A6.8030608@oracle.com> On 07/11/2013 13:52, Rob McKenna wrote: > I've added a review showing the differences to jdk8 to: > > http://cr.openjdk.java.net/~robm/5049299/7/webrev.02/ That makes it easy, thanks. At L100 then I assume you mean "posix_spawn" rather than "spawn". -Alan From volker.simonis at gmail.com Thu Nov 7 17:33:52 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Nov 2013 18:33:52 +0100 Subject: Question regarding "Entity Expansion in JAXB", "-DentityExpansionLimit" and "8017298: Better XML support" Message-ID: Hi, I have a question related to change "8017298: Better XML support" which went into the last security update. Because it was considered a security fix, there's not much information available (i.e. no webrev, no bug description, no discussion on the public mailing lists). As far as I can see, the "entityExpansionLimit" for JAXB has been there since Java 5 and according to Blaise Doughan blog at http://blog.bdoughan.com/2011/03/preventing-entity-expansion-attacks-in.html it should have been enabled by default together with the XMLConstants.FEATURE_SECURE_PROCESSING feature. Now we have a customer who claims that after upgrading to 7u45 he gets an execption because of too many entity expansions. The customer explicitly sets "-DentityExpansionLimit=1". For us it seems as if before change "8017298: Better XML support" there must have been places in the libraries which ignored the "entityExpansionLimit" setting even if this was explicitly specified by the user. Can somebody confirm this assumption or is our customer facing another problem? Thank you and best regards, Volker From Alan.Bateman at oracle.com Thu Nov 7 18:05:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 18:05:46 +0000 Subject: Question regarding "Entity Expansion in JAXB", "-DentityExpansionLimit" and "8017298: Better XML support" In-Reply-To: References: Message-ID: <527BD67A.9000509@oracle.com> On 07/11/2013 17:33, Volker Simonis wrote: > Hi, > > I have a question related to change "8017298: Better XML support" > which went into the last security update. Because it was considered a > security fix, there's not much information available (i.e. no webrev, > no bug description, no discussion on the public mailing lists). > > As far as I can see, the "entityExpansionLimit" for JAXB has been > there since Java 5 and according to Blaise Doughan blog at > http://blog.bdoughan.com/2011/03/preventing-entity-expansion-attacks-in.html > it should have been enabled by default together with the > XMLConstants.FEATURE_SECURE_PROCESSING feature. > > Now we have a customer who claims that after upgrading to 7u45 he gets > an execption because of too many entity expansions. The customer > explicitly sets "-DentityExpansionLimit=1". > > For us it seems as if before change "8017298: Better XML support" > there must have been places in the libraries which ignored the > "entityExpansionLimit" setting even if this was explicitly specified > by the user. Can somebody confirm this assumption or is our customer > facing another problem? This might be useful: http://docs.oracle.com/javase/tutorial/jaxp/limits/index.html -Alan. From naoto.sato at oracle.com Thu Nov 7 18:04:06 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 07 Nov 2013 18:04:06 +0000 Subject: hg: jdk8/tl/jdk: 8027930: ResourceBundle test failures in fr locale Message-ID: <20131107180439.48B1C6240F@hg.openjdk.java.net> Changeset: fb7abd509bd2 Author: naoto Date: 2013-11-07 10:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb7abd509bd2 8027930: ResourceBundle test failures in fr locale Reviewed-by: smarks ! test/java/util/ResourceBundle/ResourceBundleTest.java ! test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java From xueming.shen at oracle.com Thu Nov 7 18:59:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Nov 2013 10:59:36 -0800 Subject: RFR: JDK-8027645: Pattern.split() with positive lookahead Message-ID: <527BE318.3050007@oracle.com> Hi, As suggested in the bug report [1] the spec of j.u.Pattern.split() does not clearly specify what the expected behavior should be for scenario like a zero-width match is found at the beginning of the input string (such as whether or not an empty leading string should be included into the resulting array), worse, the implementation is not consistent as well (for different input cases, such as "Abc".split(...) vs "AbcEfg".split(...)). The spec also is not clear regarding what the expected behavior should be if the size of the input string is 0 [2]. As a reference, Perl.split() function has clear/explicit spec regarding above use scenario [3]. So the proposed change here is to updatethe spec&impl of Pattern.split() to have clear specification for above use scanrio, as Perl does (1) A zero-length input sequence always results zero-length resulting array (instead of returning a string[] only contains an empty string) (2) An empty leading substring is included at the beginning of the resulting array, when there is a positive-width match at the beginning of the input sequence. A zero-width match at the beginning however never produces such empty leading substring. webrev: http://cr.openjdk.java.net/~sherman/8027645/webrev/ Thanks! -Sherman [1] https://bugs.openjdk.java.net/browse/JDK-8027645 [2] https://bugs.openjdk.java.net/browse/JDK-6559590 [3] http://perldoc.perl.org/functions/split.html btw:the following perl script is used to verify the perl behavior ------------------ $str = "AbcEfgHij"; @substr = split(/(?=\p{Uppercase})/, $str); #$str = "abc efg hij"; #@substr = split(/ /, $str); print "split[sz=", scalar @substr, "]=[", join(",", @substr), "]\n"; ------------------ From Alan.Bateman at oracle.com Thu Nov 7 19:04:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Nov 2013 19:04:23 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527BAABB.7050202@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> <527B7AAE.1090703@oracle.com> <527B947C.3030405@oracle.com> <527BAABB.7050202@oracle.com> Message-ID: <527BE437.4000905@oracle.com> On 07/11/2013 14:59, Chris Hegarty wrote: > Given both Michael and Alan's comments. I've update the webrev: > http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/ > > 1) more descriptive method names > 2) deleteXXX methods return if interrupted, leaving the > interrupt status set > 3) Use Files.copy with REPLACE_EXISTING > 4) Use SimpleFileVisitor, rather than FileVisitor > This looks better although interrupting the sleep means that the deleteXXX will quietly terminate with the interrupt status set (which could be awkward to diagnose if used with tests that are also using Thread.interrupt). An alternative might be to just throw the IOException with InterruptedException as the cause. -Alan. From mandy.chung at oracle.com Thu Nov 7 21:59:00 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 07 Nov 2013 13:59:00 -0800 Subject: Simple 1-line fix for 8027943 to fix serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImp Message-ID: <527C0D24.3080001@oracle.com> This reverts com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl back to the previous serial version. diff --git a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java b/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java --- a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java +++ b/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java @@ -89,4 +89,6 @@ sm.checkPermission(perm); } } + + private static final long serialVersionUID = 4571178305984833743L; } Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027943/webrev.00/ Mandy From brent.christian at oracle.com Thu Nov 7 22:13:35 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 07 Nov 2013 14:13:35 -0800 Subject: RFR: 7174936: several String methods claim to always create new String In-Reply-To: <527AED79.2010702@oracle.com> References: <527AED79.2010702@oracle.com> Message-ID: <527C108F.4010106@oracle.com> Hi, Stuart On 11/6/13 5:31 PM, Stuart Marks wrote: > > In several places the specs mention returning "new" strings. This is > overspecified; it's sufficient to return "a" string that satisfies the > required properties. In some cases the current implementation doesn't > create a new string -- for example, substring(0) returns 'this' -- which > is strictly a violation of the spec. The solution is to relax the spec > requirement to create new strings. I like it. I'd like to suggest a doc tweak. For concat() we have: --- 1997,2008 ---- * If the length of the argument string is {@code 0}, then this ! * {@code String} object is returned. Otherwise, a ! * {@code String} object is returned, representing a character * sequence that is the concatenation of the character sequence With "new" removed, "Otherwise, a String object is returned, representing..." to me somewhat implies that in the other case, something other than a String object is returned. I prefer the way replace() is worded: --- 2025,2041 ---- * then a reference to this {@code String} object is returned. ! * Otherwise, a {@code String} object is returned that * represents a character sequence identical to the character I would change concat() to be similar: "Otherwise, a String object is returned that represents a character sequence that is the concatenation of..." Thanks, -Brent From Lance.Andersen at oracle.com Thu Nov 7 22:19:10 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Nov 2013 17:19:10 -0500 Subject: Simple 1-line fix for 8027943 to fix serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImp In-Reply-To: <527C0D24.3080001@oracle.com> References: <527C0D24.3080001@oracle.com> Message-ID: <77E45A2C-2C2E-4C02-84C3-C8D5A7B268BD@oracle.com> +1 On Nov 7, 2013, at 4:59 PM, Mandy Chung wrote: > This reverts com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl back to the previous serial version. > > diff --git a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java b/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java > --- a/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java > +++ b/src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java > @@ -89,4 +89,6 @@ > sm.checkPermission(perm); > } > } > + > + private static final long serialVersionUID = 4571178305984833743L; > } > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8027943/webrev.00/ > > Mandy > -------------- next part -------------- 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 roger.riggs at oracle.com Thu Nov 7 22:29:05 2013 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 07 Nov 2013 17:29:05 -0500 Subject: RFR doc only typo in java.io.DataInput Message-ID: <527C1431.4010201@oracle.com> Please review this straightforward typo correction: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/ Thanks, Roger From Lance.Andersen at oracle.com Thu Nov 7 22:33:10 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Nov 2013 17:33:10 -0500 Subject: RFR doc only typo in java.io.DataInput In-Reply-To: <527C1431.4010201@oracle.com> References: <527C1431.4010201@oracle.com> Message-ID: <5E990AC8-51EF-47A3-AF7F-280ED6A77A5A@oracle.com> +1 On Nov 7, 2013, at 5:29 PM, roger riggs wrote: > Please review this straightforward typo correction: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/ > > Thanks, Roger > -------------- next part -------------- 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 chris.hegarty at oracle.com Thu Nov 7 23:03:42 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Nov 2013 23:03:42 +0000 Subject: RFR doc only typo in java.io.DataInput In-Reply-To: <527C1431.4010201@oracle.com> References: <527C1431.4010201@oracle.com> Message-ID: <6F9DF82A-4D86-4AE9-A599-F474715CAE74@oracle.com> Looks fine to me Roger. -Chris > On 7 Nov 2013, at 22:29, roger riggs wrote: > > Please review this straightforward typo correction: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/ > > Thanks, Roger > From stuart.marks at oracle.com Thu Nov 7 23:16:12 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 07 Nov 2013 15:16:12 -0800 Subject: RFR: 7174936: several String methods claim to always create new String In-Reply-To: <527B4B73.2040400@oracle.com> References: <527AED79.2010702@oracle.com> <527AF7A7.40602@oracle.com> <527B4B73.2040400@oracle.com> Message-ID: <527C1F3C.1030702@oracle.com> On 11/7/13 12:12 AM, Stuart Marks wrote: > The concat() method is weird in that if the arg is empty, it requires returning > 'this'; but if 'this' is empty, it requires creating a new String instead of > just returning the arg. I think this is overspecified. But the implementation > follows this exactly, so I didn't want to change the spec in this case. Maybe > later. Woops, I forgot, I did change the concat() spec to no longer require creating a new string in the case where 'this' is empty. I think it's still overspecified, in that it requires returning 'this' if the arg is empty, though this doesn't seem to do much harm. s'marks From stuart.marks at oracle.com Thu Nov 7 23:18:45 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 07 Nov 2013 15:18:45 -0800 Subject: RFR: 7174936: several String methods claim to always create new String In-Reply-To: <527C108F.4010106@oracle.com> References: <527AED79.2010702@oracle.com> <527C108F.4010106@oracle.com> Message-ID: <527C1FD5.8070203@oracle.com> On 11/7/13 2:13 PM, Brent Christian wrote: > I would change concat() to be similar: > "Otherwise, a String object is returned that represents a character sequence > that is the concatenation of..." Yes, that's nice. Thanks for the suggestion. I'll put it in. s'marks From david.holmes at oracle.com Fri Nov 8 00:39:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Nov 2013 10:39:09 +1000 Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527B9B42.6030600@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <527996BE.3060003@oracle.com> <527A2F40.7020200@oracle.com> <527AF21D.1070907@oracle.com> <527B9B42.6030600@oracle.com> Message-ID: <527C32AD.7050602@oracle.com> On 7/11/2013 11:53 PM, Rob McKenna wrote: > Ah, thanks for catching that David, I've updated the webrev in place. > > I believe the reasoning is that we want to minimise any potential impact > to customers running in production. The general feeling seems to be that > Mac is a development platform and is less likely to cause us problems in > that regard. (not that I would anticipate any on Solaris, but I > understand the desire to be conservative) And linux? It has changed to vfork right? So OSX has changed, linux has changed, but Solaris remains as-is. All platforms allow selecting the mechanism via the property jdk.lang.Process.launchMechanism Thanks, David > -Rob > > On 07/11/13 01:51, David Holmes wrote: >> On 6/11/2013 10:00 PM, Rob McKenna wrote: >>> Hi David, >>> >>> The only difference in 5049299 is the change in the default property >>> value in Solaris. Apologies for not making that clear. >> >> Given this was primarily aimed at Solaris in the first place it seems >> strange to me to not make the change on Solaris. If this is considered >> risky fr an update release then I would think that applies to all >> platforms equally. ?? >> >> If Solaris is not in fact changing then the comment in >> src/solaris/native/java/lang/UNIXProcess_md.c needs to be altered: >> >> * Based on the above analysis, we are currently using vfork() on >> ! * Linux and spawn() on other Unix systems, but the code to use clone() >> ! * and fork() remains. >> >> David >> ----- >> >>> -Rob >>> >>> On 06/11/13 01:09, David Holmes wrote: >>>> Hi Rob, >>>> >>>> How different is this to the JDK 8 version? >>>> >>>> Thanks, >>>> David >>>> >>>> On 6/11/2013 7:24 AM, Rob McKenna wrote: >>>>> .. >>>>> >>>>> http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ >>>>> >>>>> -Rob >>>>> >>>>> On 05/11/13 21:23, Rob McKenna wrote: >>>>>> Hi folks, >>>>>> >>>>>> I'd like to backport this change to JDK7. Note: this fix uses >>>>>> posix_spawn by default on Mac OSX only. On Solaris fork will remain >>>>>> the default behaviour. >>>>>> >>>>>> I've just noticed that there is a problem with the testcase on >>>>>> Solaris >>>>>> in that it will test fork twice. (and won't test posix_spawn) I'll >>>>>> figure out a way around this, but in the mean time I'd like to get >>>>>> the >>>>>> ball rolling on this review anyway. >>>>>> >>>>>> -Rob >>>>>> >>>>>> >>>>> >>> > From dan.xu at oracle.com Fri Nov 8 01:16:44 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 07 Nov 2013 17:16:44 -0800 Subject: RFR doc only typo in java.io.DataInput In-Reply-To: <527C1431.4010201@oracle.com> References: <527C1431.4010201@oracle.com> Message-ID: <527C3B7C.8030106@oracle.com> Hi Roger, The change looks good. -Dan On 11/07/2013 02:29 PM, roger riggs wrote: > Please review this straightforward typo correction: > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-doc-readlong-8024458/ > > Thanks, Roger > From dan.xu at oracle.com Fri Nov 8 02:26:35 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 07 Nov 2013 18:26:35 -0800 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527BE437.4000905@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> <527B7AAE.1090703@oracle.com> <527B947C.3030405@oracle.com> <527BAABB.7050202@oracle.com> <527BE437.4000905@oracle.com> Message-ID: <527C4BDB.9030102@oracle.com> On 11/07/2013 11:04 AM, Alan Bateman wrote: > On 07/11/2013 14:59, Chris Hegarty wrote: >> Given both Michael and Alan's comments. I've update the webrev: >> http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/ >> >> 1) more descriptive method names >> 2) deleteXXX methods return if interrupted, leaving the >> interrupt status set >> 3) Use Files.copy with REPLACE_EXISTING >> 4) Use SimpleFileVisitor, rather than FileVisitor >> > This looks better although interrupting the sleep means that the > deleteXXX will quietly terminate with the interrupt status set (which > could be awkward to diagnose if used with tests that are also using > Thread.interrupt). An alternative might be to just throw the > IOException with InterruptedException as the cause. > > -Alan. > > Hi Chris, In the method, deleteFileWithRetry0(), it assumes that if any other process is accessing the same file, the delete operation, Files.delete(), will throw out IOException on Windows. But I don't see this assumption is always true when I investigated this issue on intermittent test failures. When Files.delete() method is called, it finally calls DeleteFile or RemoveDirectory functions based on whether the target is a file or directory. And these Windows APIs only mark the target for deletion on close and return immediately without waiting the operation to be completed. If another process is accessing the file in the meantime, the delete operation does not occur and the target file stays at delete-pending status until that open handle is closed. It basically implies that DeleteFile and RemoveDirectory is like an async operation. Therefore, we cannot assume that the file/directory is deleted after Files.delete() returns or File.delete() returns true. When checking those intermittently test failures, I find the test normally succeeds on the Files.delete() call. But due to the interference of Anti-virus or other Windows daemon services, the target file changes to delete-pending status. And the immediately following operation fails due the target file still exists, but our tests assume the target file is already gone. Because the delete-pending status of a file usually last for a very short time which depends on the interference source, such failures normally happens when we recursively delete a folder or delete-and-create a file with the same file name at a high frequency. It is basically a Windows API design or implementation issue. I have logged an enhancement, JDK-8024496, to solve it from Java library layer. Currently, I have two strategies in mind. One is to make the delete operation blocking, which means to make sure the file/directory is deleted before the return. The other is to make sure the delete-pending file does not lead to a failure of subsequent file operations. But they both has pros and cons. Thank! -Dan From roger.riggs at oracle.com Fri Nov 8 01:58:40 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 08 Nov 2013 01:58:40 +0000 Subject: hg: jdk8/tl/jdk: 8024458: DataInput.readDouble refers to "readlong" instead of "readLong" Message-ID: <20131108015854.EDA3B62455@hg.openjdk.java.net> Changeset: 04f071a95c29 Author: rriggs Date: 2013-11-07 20:56 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04f071a95c29 8024458: DataInput.readDouble refers to "readlong" instead of "readLong" Summary: fix the typo Reviewed-by: lancea, chegar, dxu ! src/share/classes/java/io/DataInput.java From stuart.marks at oracle.com Fri Nov 8 03:02:36 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 07 Nov 2013 19:02:36 -0800 Subject: RFR: 8028027: serialver should emit declaration with the 'private' modifier Message-ID: <527C544C.5090900@oracle.com> Hi all, Please review this quick one-liner to change the serialver tool so that it emits a serialVersionUID declaration with the 'private' modifier, which comports with the recommendation in the java.io.Serializable page. Bug: https://bugs.openjdk.java.net/browse/JDK-8028027 Patch appended below. Thanks, s'marks ---------- # HG changeset patch # User smarks # Date 1383868023 28800 # Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180 # Parent f18b60bd22a1be988d329960c46d504f4b75000f 8028027: serialver should emit declaration with the 'private' modifier Reviewed-by: XXX diff -r f18b60bd22a1 -r 1e1088bfea50 src/share/classes/sun/tools/serialver/SerialVer.java --- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07 15:45:21 2013 -0800 +++ b/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07 15:47:03 2013 -0800 @@ -211,7 +211,7 @@ Class cl = Class.forName(classname, false, loader); ObjectStreamClass desc = ObjectStreamClass.lookup(cl); if (desc != null) { - return " static final long serialVersionUID = " + + return " private static final long serialVersionUID = " + desc.getSerialVersionUID() + "L;"; } else { return null; From joe.darcy at oracle.com Fri Nov 8 03:04:36 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 07 Nov 2013 19:04:36 -0800 Subject: RFR: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: <527C544C.5090900@oracle.com> References: <527C544C.5090900@oracle.com> Message-ID: <527C54C4.9030804@oracle.com> Approved!! -Joe On 11/7/2013 7:02 PM, Stuart Marks wrote: > Hi all, > > Please review this quick one-liner to change the serialver tool so > that it emits a serialVersionUID declaration with the 'private' > modifier, which comports with the recommendation in the > java.io.Serializable page. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8028027 > > Patch appended below. > > Thanks, > > s'marks > > > ---------- > > > # HG changeset patch > # User smarks > # Date 1383868023 28800 > # Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180 > # Parent f18b60bd22a1be988d329960c46d504f4b75000f > 8028027: serialver should emit declaration with the 'private' modifier > Reviewed-by: XXX > > diff -r f18b60bd22a1 -r 1e1088bfea50 > src/share/classes/sun/tools/serialver/SerialVer.java > --- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov > 07 15:45:21 2013 -0800 > +++ b/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov > 07 15:47:03 2013 -0800 > @@ -211,7 +211,7 @@ > Class cl = Class.forName(classname, false, loader); > ObjectStreamClass desc = ObjectStreamClass.lookup(cl); > if (desc != null) { > - return " static final long serialVersionUID = " + > + return " private static final long serialVersionUID = " + > desc.getSerialVersionUID() + "L;"; > } else { > return null; From mandy.chung at oracle.com Fri Nov 8 03:14:26 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 07 Nov 2013 19:14:26 -0800 Subject: RFR: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: <527C544C.5090900@oracle.com> References: <527C544C.5090900@oracle.com> Message-ID: <527C5712.9050601@oracle.com> Looks good. Mandy On 11/7/2013 7:02 PM, Stuart Marks wrote: > Hi all, > > Please review this quick one-liner to change the serialver tool so > that it emits a serialVersionUID declaration with the 'private' > modifier, which comports with the recommendation in the > java.io.Serializable page. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8028027 > > Patch appended below. > > Thanks, > > s'marks > > > ---------- > > > # HG changeset patch > # User smarks > # Date 1383868023 28800 > # Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180 > # Parent f18b60bd22a1be988d329960c46d504f4b75000f > 8028027: serialver should emit declaration with the 'private' modifier > Reviewed-by: XXX > > diff -r f18b60bd22a1 -r 1e1088bfea50 > src/share/classes/sun/tools/serialver/SerialVer.java > --- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov > 07 15:45:21 2013 -0800 > +++ b/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov > 07 15:47:03 2013 -0800 > @@ -211,7 +211,7 @@ > Class cl = Class.forName(classname, false, loader); > ObjectStreamClass desc = ObjectStreamClass.lookup(cl); > if (desc != null) { > - return " static final long serialVersionUID = " + > + return " private static final long serialVersionUID = " + > desc.getSerialVersionUID() + "L;"; > } else { > return null; From patrick.zhang at oracle.com Fri Nov 8 03:41:51 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Fri, 08 Nov 2013 11:41:51 +0800 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527B5856.8090301@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> Message-ID: <527C5D7F.2000102@oracle.com> Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. Now the webrev and result are attached. Please help to review. After checking the scripts in java.util, most of scripts have been finished in 8003890. So the webrev only change 2 rest files. webrev: http://cr.openjdk.java.net/~pzhang/8019502/webrev/ result: http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr Regards Patrick On 11/7/13 5:07 PM, Alan Bateman wrote: > On 07/11/2013 03:48, Patrick Zhang wrote: >> Hi Everyone, >> >> I am working on https://bugs.openjdk.java.net/browse/JDK-8019502. The >> problem is, some java.util test does use ${TESTVMOPTS} to launch java >> program in script. Then it may lose VM setting from high level. >> >> The fix will refer to >> https://bugs.openjdk.java.net/browse/JDK-8003890 finished by Mark >> Sheppard. Just add ${TESTVMOPTS} to launch java. > Did you intend to include a link to a patch? > > -Alan. From joe.darcy at oracle.com Fri Nov 8 04:12:08 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 08 Nov 2013 04:12:08 +0000 Subject: hg: jdk8/tl/langtools: 8027730: Fix release-8 type visitors to support intersection types Message-ID: <20131108041211.CF47C62459@hg.openjdk.java.net> Changeset: e39bd9401ea5 Author: darcy Date: 2013-11-07 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e39bd9401ea5 8027730: Fix release-8 type visitors to support intersection types Reviewed-by: jjg, jlahoda, sogoel ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java + test/tools/javac/processing/model/util/TestIntersectionTypeVisitors.java From david.holmes at oracle.com Fri Nov 8 04:10:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Nov 2013 20:10:59 -0800 (PST) Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527C5D7F.2000102@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> Message-ID: <527C6453.1000802@oracle.com> On 8/11/2013 1:41 PM, Patrick Zhang wrote: > Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. > Now the webrev and result are attached. Please help to review. > After checking the scripts in java.util, most of scripts have been > finished in 8003890. So the webrev only change 2 rest files. > > webrev: > http://cr.openjdk.java.net/~pzhang/8019502/webrev/ Looks fine to me. Thanks, David > result: > http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr > http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr > > Regards > Patrick > > On 11/7/13 5:07 PM, Alan Bateman wrote: >> On 07/11/2013 03:48, Patrick Zhang wrote: >>> Hi Everyone, >>> >>> I am working on https://bugs.openjdk.java.net/browse/JDK-8019502. The >>> problem is, some java.util test does use ${TESTVMOPTS} to launch java >>> program in script. Then it may lose VM setting from high level. >>> >>> The fix will refer to >>> https://bugs.openjdk.java.net/browse/JDK-8003890 finished by Mark >>> Sheppard. Just add ${TESTVMOPTS} to launch java. >> Did you intend to include a link to a patch? >> >> -Alan. From mandy.chung at oracle.com Fri Nov 8 04:48:59 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 08 Nov 2013 04:48:59 +0000 Subject: hg: jdk8/tl/corba: 8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45 Message-ID: <20131108044900.953AD6245A@hg.openjdk.java.net> Changeset: b99535e22efe Author: mchung Date: 2013-11-07 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b99535e22efe 8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45 Reviewed-by: msheppar, alanb, lancea ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java From yong.huang at oracle.com Fri Nov 8 06:34:08 2013 From: yong.huang at oracle.com (yong.huang at oracle.com) Date: Fri, 08 Nov 2013 06:34:08 +0000 Subject: hg: jdk8/tl/jdk: 8027695: There should be a space before % sign in Swedish locale Message-ID: <20131108063422.B41126245E@hg.openjdk.java.net> Changeset: e10a182c973a Author: yhuang Date: 2013-11-07 22:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e10a182c973a 8027695: There should be a space before % sign in Swedish locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From jaroslav.bachorik at oracle.com Fri Nov 8 07:48:40 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Fri, 08 Nov 2013 07:48:40 +0000 Subject: hg: jdk8/tl/jdk: 8007984: Null pointer dereference in jdk/linux-amd64/democlasses/demo/jvmti/heapTracker/src/java_crw_demo.c Message-ID: <20131108074852.ADE2362461@hg.openjdk.java.net> Changeset: b5748857ef42 Author: jbachorik Date: 2013-11-08 08:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5748857ef42 8007984: Null pointer dereference in jdk/linux-amd64/democlasses/demo/jvmti/heapTracker/src/java_crw_demo.c Reviewed-by: dholmes ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c From Alan.Bateman at oracle.com Fri Nov 8 08:34:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Nov 2013 00:34:57 -0800 (PST) Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527C32AD.7050602@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <527996BE.3060003@oracle.com> <527A2F40.7020200@oracle.com> <527AF21D.1070907@oracle.com> <527B9B42.6030600@oracle.com> <527C32AD.7050602@oracle.com> Message-ID: <527CA231.7050903@oracle.com> On 08/11/2013 00:39, David Holmes wrote: > > And linux? It has changed to vfork right? > > So OSX has changed, linux has changed, but Solaris remains as-is. All > platforms allow selecting the mechanism via the property > jdk.lang.Process.launchMechanism > The only change is OSX where the default switches from fork to posix_spawn. No change to the default on Solaris or Linux. -Alan. From staffan.larsen at oracle.com Fri Nov 8 09:04:08 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 08 Nov 2013 09:04:08 +0000 Subject: hg: jdk8/tl/jdk: 8027752: sun/tools/jstatd/TestJstatdExternalRegistry.java: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object Message-ID: <20131108090422.B49BD62469@hg.openjdk.java.net> Changeset: 8a4405fb40ba Author: ykantser Date: 2013-11-07 16:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a4405fb40ba 8027752: sun/tools/jstatd/TestJstatdExternalRegistry.java: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object Reviewed-by: sla, jbachorik ! test/sun/tools/jstatd/JstatdTest.java From paul.sandoz at oracle.com Fri Nov 8 09:19:35 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Nov 2013 10:19:35 +0100 Subject: RFR: JDK-8027645: Pattern.split() with positive lookahead In-Reply-To: <527BE318.3050007@oracle.com> References: <527BE318.3050007@oracle.com> Message-ID: <69D00307-B80A-42F3-8744-DB0F4B5A9DB7@oracle.com> Hi Sherman. When you say: + * of the stream. A zero-width match at the beginning however never produces + * such empty leading substring. Is it possible to have a starting sequence of one or more zero-width matches? It would be useful to add a comment on skipping for zero-width match. IIUC you could simplify the code in splitAsStream: while (matcher.find()) { nextElement = input.subSequence(current, matcher.start()).toString(); current = matcher.end(); if (!nextElement.isEmpty()) { return true; } else if (current > 0) // Ignore for zero-width match emptyElementCount++; } } That is less efficient for zero-width matching, but how common is that? Paul. On Nov 7, 2013, at 7:59 PM, Xueming Shen wrote: > Hi, > > As suggested in the bug report [1] the spec of j.u.Pattern.split() > does not clearly specify what the expected behavior should be for scenario > like a zero-width match is found at the beginning of the input string > (such as whether or not an empty leading string should be included into > the resulting array), worse, the implementation is not consistent as well > (for different input cases, such as "Abc".split(...) vs "AbcEfg".split(...)). > > The spec also is not clear regarding what the expected behavior should be > if the size of the input string is 0 [2]. > > As a reference, Perl.split() function has clear/explicit spec regarding > above use scenario [3]. > > So the proposed change here is to updatethe spec&impl of Pattern.split() to have > clear specification for above use scanrio, as Perl does > > (1) A zero-length input sequence always results zero-length resulting array > (instead of returning a string[] only contains an empty string) > (2) An empty leading substring is included at the beginning of the resulting > array, when there is a positive-width match at the beginning of the input > sequence. A zero-width match at the beginning however never produces such > empty leading substring. > > webrev: > http://cr.openjdk.java.net/~sherman/8027645/webrev/ > > Thanks! > -Sherman > > [1] https://bugs.openjdk.java.net/browse/JDK-8027645 > [2] https://bugs.openjdk.java.net/browse/JDK-6559590 > [3] http://perldoc.perl.org/functions/split.html > > btw:the following perl script is used to verify the perl behavior > ------------------ > $str = "AbcEfgHij"; > @substr = split(/(?=\p{Uppercase})/, $str); > #$str = "abc efg hij"; > #@substr = split(/ /, $str); > print "split[sz=", scalar @substr, "]=[", join(",", @substr), "]\n"; > ------------------ From Alan.Bateman at oracle.com Fri Nov 8 09:24:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Nov 2013 09:24:05 +0000 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527C5D7F.2000102@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> Message-ID: <527CADB5.2060702@oracle.com> On 08/11/2013 03:41, Patrick Zhang wrote: > Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. > Now the webrev and result are attached. Please help to review. > After checking the scripts in java.util, most of scripts have been > finished in 8003890. So the webrev only change 2 rest files. > > webrev: > http://cr.openjdk.java.net/~pzhang/8019502/webrev/ > > result: > http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr > http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr cc'ing i18n-dev as that is where Calendar (and its tests) are maintained. The change look okay to me but I wonder if perhaps you have the wrong bug number. JDK-8019502 is a confused bug but I think it was originally intended to be an audit of the tests that use Runtime.exec or ProcessBuilder to see if they should be changed to pass the options through. I just mention it as I suspect you might need to create a new bug for this and then split up JDK-8019502 into other tasks. -Alan From ygaevsky at azulsystems.com Fri Nov 8 09:45:11 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Fri, 8 Nov 2013 09:45:11 +0000 Subject: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: <527C544C.5090900@oracle.com> References: <527C544C.5090900@oracle.com> Message-ID: Hi Stuart, Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can cause confusion: $ serialver java.security.PublicKey java.security.PublicKey: private static final long serialVersionUID = 7187392471159151072L; $ javap java.security.PublicKey Compiled from "PublicKey.java" public interface java.security.PublicKey extends java.security.Key { public static final long serialVersionUID; } Thanks, -Yuri -----Original Message----- From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Stuart Marks Sent: Friday, November 8, 2013 7:03 AM To: core-libs-dev Subject: RFR: 8028027: serialver should emit declaration with the 'private' modifier Hi all, Please review this quick one-liner to change the serialver tool so that it emits a serialVersionUID declaration with the 'private' modifier, which comports with the recommendation in the java.io.Serializable page. Bug: https://bugs.openjdk.java.net/browse/JDK-8028027 Patch appended below. Thanks, s'marks ---------- # HG changeset patch # User smarks # Date 1383868023 28800 # Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180 # Parent f18b60bd22a1be988d329960c46d504f4b75000f 8028027: serialver should emit declaration with the 'private' modifier Reviewed-by: XXX diff -r f18b60bd22a1 -r 1e1088bfea50 src/share/classes/sun/tools/serialver/SerialVer.java --- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07 15:45:21 2013 -0800 +++ b/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07 15:47:03 2013 -0800 @@ -211,7 +211,7 @@ Class cl = Class.forName(classname, false, loader); ObjectStreamClass desc = ObjectStreamClass.lookup(cl); if (desc != null) { - return " static final long serialVersionUID = " + + return " private static final long serialVersionUID = " + desc.getSerialVersionUID() + "L;"; } else { return null; From patrick.zhang at oracle.com Fri Nov 8 10:13:23 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Fri, 08 Nov 2013 18:13:23 +0800 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527CADB5.2060702@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> <527CADB5.2060702@oracle.com> Message-ID: <527CB943.8040207@oracle.com> Hi Alan, I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it. Regards Patrick On 11/8/13 5:24 PM, Alan Bateman wrote: > On 08/11/2013 03:41, Patrick Zhang wrote: >> Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. >> Now the webrev and result are attached. Please help to review. >> After checking the scripts in java.util, most of scripts have been >> finished in 8003890. So the webrev only change 2 rest files. >> >> webrev: >> http://cr.openjdk.java.net/~pzhang/8019502/webrev/ >> >> result: >> http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr >> http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr > cc'ing i18n-dev as that is where Calendar (and its tests) are maintained. > > The change look okay to me but I wonder if perhaps you have the wrong > bug number. JDK-8019502 is a confused bug but I think it was > originally intended to be an audit of the tests that use Runtime.exec > or ProcessBuilder to see if they should be changed to pass the options > through. I just mention it as I suspect you might need to create a new > bug for this and then split up JDK-8019502 into other tasks. > > -Alan From tristan.yan at oracle.com Fri Nov 8 11:00:46 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 08 Nov 2013 19:00:46 +0800 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <5279A059.9010304@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> Message-ID: <527CC45E.5050902@oracle.com> /Thank you, Stuart There is one review point I want to ask you opinion. Which is the reason that I moved from test/java/rmi/reliability/benchmark/bench/rmi to test/java/rmi/reliability/benchmark is Main.java need access class TestLibrary for supporting random port. TestLibrary is a unpackage class, I couldn't find a way to let a class which has Package to access the class without package. Do you have suggestion on that? Thank you so much. Tristan On 11/06/2013 09:50 AM, Stuart Marks wrote: / > / > / / > On 11/1/13 9:18 AM, Tristan Yan wrote: > / >> /Hi Everyone >> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >> / / >> Description: >> 1. Convert shell script test to Java program test. >> 2. Using random server port by reusing Darryl Mocek's work to replace >> fixed >> server port. >> 3. Using java Process class to start client process. >> 4. Also convert other shell script test runSerialBench.sh to java >> program test also >> / > / > Hi Tristan, > / / > Several comments on this webrev. > / / > / / > ** The original arrangement within the > test/java/rmi/reliability/benchmark directory had the main benchmark > files (scripts) at the top, some benchmark framework files in the > "bench" subdirectory, and the actual RMI and serialization benchmarks > in bench/rmi and bench/serial subdirectories. > / / > The webrev moves all the RMI benchmarks to the top benchmark directory > but leaves the serial benchmarks in bench/serial. The RMI benchmarks > are now all cluttering the top directory, but the main serial > benchmark test is now buried in the bench/serial directory. The nice > organization that was there before is now spoiled. Is this > rearrangement necessary in order to convert the scripts to Java? I > would prefer the original arrangement be left in place. > / / > / / > ** The RMI benchmark Main.java file has a @run tag of the form, > / / > @run main/othervm/policy=policy.all/timeout=1800 -server Main -c > config > / / > There is a subtle but serious problem here: the -server option is > passed to the >>JVM<< and not as an argument to the main() method. The > main() method gets neither a -server nor a -client argument, so its > default "run mode" as defined by the benchmark itself is SAMEVM. This > runs the client and server in the same JVM, which is different from > the shell script, which ran separate client and server JVMs. > / / > / / > ** The logic to process the -server argument still expects to take a > port, even though the port is assigned automatically. So the obvious > fix to the above, > / / > @run main/othervm/policy=policy.all/timeout=1800 Main -server -c > config > / / > doesn't work, since a port is missing. The logic to increment the > argument index to collect the port argument should be removed. Also, > the -server line should be restored to the usage message, but without > the port argument. > / / > / / > ** After this is done, the client's command line is constructed > improperly. The command line ends up looking something like this: > / / > java client -cp Main client localhost:58583 -c config > / / > The word "client" appears twice, but what's really required is > "-client" to appear as an argument after Main. > / / > / / > ** The client is run using ProcessBuilder, which by default sends > stdout and stderr to pipes to be read by the parent. But the parent > never reads them, thus any messages from the client are never seen. > The client is the one that emits the benchmark report, so its output > needs to be seen. It might be sufficient to have the client inherit > the parent's stdout and stderr. This might intermix the client's and > server's output, but it's better than nothing. > / / > / / > ** The config file is checked with the following code: > / / > try { > confFile = args[i]; > confstr = new FileInputStream(System.getProperty("test.src") > + System.getProperty("file.separator") + confFile); > } catch (IOException e) { > die("Error: unable to open \"" + args[i] + "\""); > } > / / > This is potentially misleading, as the message doesn't print the > actual filename that was attempted to be opened. > / / > This is important, as the test.src property doesn't exist in the > client JVM. > / / > Note that the original shell script passed full pathnames for the > config file to both the client and the server. The new @run tag merely > says "-c config" which redefines the config filename to be relative to > the test.src directory. You could pass -Dtest.src=... to the client, > but it seems like there should be something better than can be done. > / / > / / > ** The client needs to have its security policy set up. This is > missing from the construction of the client's command line. > / / > / / > ** ProcessBuilder takes a List for its command; there is no > need to turn the list into an array. > / / > / / > ** In the benchmark main methods, code of the form, > / / > while (true) { > runBenchmarks(); > if (exitRequested) { > System.exit(); > } > } > / / > was replaced with > / / > while (!exitRequested) { > runBenchmarks(); > } > / / > This is a subtle logic change, in that the former code always executed > the loop at least once. It seems unlikely, but it's possible that a > timer could set exitRequested before loop entry, resulting in the > benchmark running zero times. I guess, if you really want to clean > this up (we do need to avoid System.exit in jtreg tests), use a > do-while loop instead. > / / > / / > ** Don't forget to remove the 7190106/runRmiBench.sh entry from > ProblemList.txt. > / / > / / > ** Remove the references to RMISecurityManager and just use > SecurityManager. This is just general cleanup. (I deprecated > RMISecurityManager last week.) :-) > / / > / / > It would be good if you could fix up these issues and post another > webrev. > / / > Thanks. > / / > s'marks > / / > / / > / / > / / > / >> /Thank you >> Tristan >> / / >> On 01/11/2013 23:58, Stuart Marks wrote: >> / >>> /On 10/31/13 10:22 PM, Tristan Yan wrote: >>> / >>>> /I am working on bug >>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>> on my research, it looks like the issue of fixed port was already >>>> addressed >>>> by Stuart Marks in other RMI tests which are Java based. I would >>>> like to >>>> reuse his solution, however it does not work for shell based tests. >>>> / >>> / >>> (Darryl Mocek did the unique port work for the RMI tests.) >>> / / >>> Was the patch attached to your message? If so, it didn't get >>> through. Most >>> OpenJDK mailing lists strip off attachments before forwarding the >>> message to >>> the recipients. >>> / / >>> / >>>> /2. My recommendation would be to convert this shell script test >>>> into Java >>>> based test and re-use the dynamic port allocation solution by >>>> Stuart Marks to >>>> address the issue >>>> / / >>>> 3. Also this test was written with server/client mode in shell >>>> script. In the >>>> past there have been sync issues between server/client which caused >>>> the test >>>> to fail. If we convert the shell script into Java based test, it >>>> would avoid >>>> using "sleep 10" mechanism to allow for server and client to start >>>> up and >>>> also give us better control in synchronizing server and client. >>>> / >>> / >>> (Background for interested readers.) In general, yes, it's quite >>> difficult to >>> make reliable shell tests, especially for multi-process tests like >>> this one. >>> There is the unique port issue, and there is also the issue of how >>> long for >>> the client to wait until the server is ready. Error handling is also a >>> problem, for example, if one of the JVMs gets an unexpected >>> exception, it's >>> easy for shell tests to mishandle this case. They might hang or >>> erroneously >>> report success. >>> / / >>> -- >>> / / >>> If this is a rewrite, it's probably fairly large, so you need to >>> upload it >>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>> / / >>> Thanks. >>> / / >>> s'marks >>> / >> / >> / / / From aleksej.efimov at oracle.com Fri Nov 8 11:44:47 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 08 Nov 2013 15:44:47 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <527A9472.9070403@oracle.com> References: <52791F14.2080305@oracle.com> <52792FF2.4050606@oracle.com> <527933E9.3030707@oracle.com> <527A9472.9070403@oracle.com> Message-ID: <527CCEAF.5020404@oracle.com> Hi, Can I ask reviewers to look at this fix? As was mentioned, the testing issues described in request were resolved. Thanks in advance, Aleksej On 11/06/2013 11:11 PM, Aleksej Efimov wrote: > Hi, > We have a fix for JDK-8027848 and it was approved in parallel thread. > With '-XX:-UseMathExactIntrinsics' tests run flag and applied fix for > JDK-8027848 all tests from the following test sets are passing: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter. > I suppose, that we're good to go with this change, unless there are > some comments or issues. > > -Aleksej > > On 11/05/2013 10:07 PM, Aleksej Efimov wrote: >> Alan, >> Thank you for advise. >> I have executed the same test sets with -XX:-UseMathExactIntrinsics >> and, as was expected, there is only one failure: >> sun/util/calendar/zi/TestZoneInfo310.java. >> >> -Aleksej >> >> On 11/05/2013 09:50 PM, Alan Bateman wrote: >>> On 05/11/2013 16:38, Aleksej Efimov wrote: >>>> Hi, >>>> >>>> Can I have a review for tzdata2013h integration [1]. The webrev >>>> link can be located here [2]. >>>> >>>> The following test sets were executed on build with fix: >>>> test/sun/util/calendar test/java/util/Calendar >>>> test/sun/util/resources/TimeZone test/sun/util/calendar >>>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>>> >>>> And here is the list of failures: >>>> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >>>> FAILED: java/time/tck/java/time/TCKInstant.java %1% >>>> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >>>> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >>>> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >>>> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >>>> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >>>> FAILED: >>>> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >>>> FAILED: java/util/Calendar/JavatimeTest.java %1% >>>> >>>> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >>>> >>>> >>>> The group %1% tests failures relates to the JDK-8027622 bug and are >>>> expected (actually, it was already resolved in hotspot repo). >>> In another thread, Amy Lu is updating the ProblemList.txt to exclude >>> these tests until the hotspot fix gets to jdk8/tl. For your testing >>> then you could run with -XX:-UseMathExactIntrinsics and check that >>> the all tests related to time and time zones are passing. >>> >>> -Alan. >> > From chris.hegarty at oracle.com Fri Nov 8 11:20:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Nov 2013 03:20:35 -0800 (PST) Subject: RFR: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: <527C544C.5090900@oracle.com> References: <527C544C.5090900@oracle.com> Message-ID: <527CC903.2090608@oracle.com> Looks good to me. It should have been this way from day one. -Chris. On 08/11/2013 03:02, Stuart Marks wrote: > Hi all, > > Please review this quick one-liner to change the serialver tool so that > it emits a serialVersionUID declaration with the 'private' modifier, > which comports with the recommendation in the java.io.Serializable page. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8028027 > > Patch appended below. > > Thanks, > > s'marks > > > ---------- > > > # HG changeset patch > # User smarks > # Date 1383868023 28800 > # Node ID 1e1088bfea50d7d3cc7cfdce2b0085b7adc6a180 > # Parent f18b60bd22a1be988d329960c46d504f4b75000f > 8028027: serialver should emit declaration with the 'private' modifier > Reviewed-by: XXX > > diff -r f18b60bd22a1 -r 1e1088bfea50 > src/share/classes/sun/tools/serialver/SerialVer.java > --- a/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07 > 15:45:21 2013 -0800 > +++ b/src/share/classes/sun/tools/serialver/SerialVer.java Thu Nov 07 > 15:47:03 2013 -0800 > @@ -211,7 +211,7 @@ > Class cl = Class.forName(classname, false, loader); > ObjectStreamClass desc = ObjectStreamClass.lookup(cl); > if (desc != null) { > - return " static final long serialVersionUID = " + > + return " private static final long serialVersionUID = " + > desc.getSerialVersionUID() + "L;"; > } else { > return null; From Alan.Bateman at oracle.com Fri Nov 8 11:57:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Nov 2013 11:57:11 +0000 Subject: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: References: <527C544C.5090900@oracle.com> Message-ID: <527CD197.9030803@oracle.com> On 08/11/2013 09:45, Yuri Gaevsky wrote: > Hi Stuart, > > Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can cause confusion: I think Stuart's suggestion is good for the case where the class doesn't have the serialVersionUID already, you just paste it into the source code to keep the value as it was generated previously. I think your concern is where the serialVersionUID is declared but hasn't following the recommendation. In that case then the emitted source line won't match the existing source declaration. Does that matter? I guess serialver should use reflection to get the modifiers and print a helpful suggestion. -Alan. From ygaevsky at azulsystems.com Fri Nov 8 12:11:18 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Fri, 8 Nov 2013 12:11:18 +0000 Subject: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: <527CD197.9030803@oracle.com> References: <527C544C.5090900@oracle.com> <527CD197.9030803@oracle.com> Message-ID: >> Unfortunately, several Java SE interfaces have public SVUIDs, so the fix can cause confusion: > I think Stuart's suggestion is good for the case where the class doesn't have the serialVersionUID already, you just paste it into the source code to keep the value as it was generated previously. Fully agree. > I think your concern is where the serialVersionUID is declared but hasn't following the recommendation. In that case then the emitted source line won't match the existing source declaration. Does that matter? I guess serialver should use reflection to get the modifiers and print a helpful suggestion. Well, it would be more consistent to check for existence of protected or public serialVersionUID with Reflection API and change the serialver output accordingly. Thanks, -Yuri From david.holmes at oracle.com Fri Nov 8 12:43:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Nov 2013 04:43:43 -0800 (PST) Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527CB943.8040207@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> <527CADB5.2060702@oracle.com> <527CB943.8040207@oracle.com> Message-ID: <527CDC7F.5020703@oracle.com> On 8/11/2013 8:13 PM, Patrick Zhang wrote: > Hi Alan, > > I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it. My understanding is that 8019502 was originally covering this issue for a broad range of tests across different areas. They were then split out into different CRs for different groups of tests. The remaining tests in the original bug were then handed to Patrick. David > Regards > Patrick > > On 11/8/13 5:24 PM, Alan Bateman wrote: >> On 08/11/2013 03:41, Patrick Zhang wrote: >>> Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. >>> Now the webrev and result are attached. Please help to review. >>> After checking the scripts in java.util, most of scripts have been >>> finished in 8003890. So the webrev only change 2 rest files. >>> >>> webrev: >>> http://cr.openjdk.java.net/~pzhang/8019502/webrev/ >>> >>> result: >>> http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr >>> http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr >> cc'ing i18n-dev as that is where Calendar (and its tests) are maintained. >> >> The change look okay to me but I wonder if perhaps you have the wrong >> bug number. JDK-8019502 is a confused bug but I think it was >> originally intended to be an audit of the tests that use Runtime.exec >> or ProcessBuilder to see if they should be changed to pass the options >> through. I just mention it as I suspect you might need to create a new >> bug for this and then split up JDK-8019502 into other tasks. >> >> -Alan From rob.mckenna at oracle.com Fri Nov 8 12:46:08 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 8 Nov 2013 04:46:08 -0800 (PST) Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev) In-Reply-To: <527C32AD.7050602@oracle.com> References: <527961D3.4080004@oracle.com> <527961F5.2020401@oracle.com> <527996BE.3060003@oracle.com> <527A2F40.7020200@oracle.com> <527AF21D.1070907@oracle.com> <527B9B42.6030600@oracle.com> <527C32AD.7050602@oracle.com> Message-ID: <527CDD10.3000800@oracle.com> vfork was the default in Linux before 5049299. You can see the variable START_CHILD_USE_VFORK being set in: http://cr.openjdk.java.net/~robm/5049299/webrev.06/src/solaris/native/java/lang/UNIXProcess_md.c.cdiff.html -Rob On 08/11/13 00:39, David Holmes wrote: > On 7/11/2013 11:53 PM, Rob McKenna wrote: >> Ah, thanks for catching that David, I've updated the webrev in place. >> >> I believe the reasoning is that we want to minimise any potential impact >> to customers running in production. The general feeling seems to be that >> Mac is a development platform and is less likely to cause us problems in >> that regard. (not that I would anticipate any on Solaris, but I >> understand the desire to be conservative) > > And linux? It has changed to vfork right? > > So OSX has changed, linux has changed, but Solaris remains as-is. All > platforms allow selecting the mechanism via the property > jdk.lang.Process.launchMechanism > > Thanks, > David > >> -Rob >> >> On 07/11/13 01:51, David Holmes wrote: >>> On 6/11/2013 10:00 PM, Rob McKenna wrote: >>>> Hi David, >>>> >>>> The only difference in 5049299 is the change in the default property >>>> value in Solaris. Apologies for not making that clear. >>> >>> Given this was primarily aimed at Solaris in the first place it seems >>> strange to me to not make the change on Solaris. If this is considered >>> risky fr an update release then I would think that applies to all >>> platforms equally. ?? >>> >>> If Solaris is not in fact changing then the comment in >>> src/solaris/native/java/lang/UNIXProcess_md.c needs to be altered: >>> >>> * Based on the above analysis, we are currently using vfork() on >>> ! * Linux and spawn() on other Unix systems, but the code to use >>> clone() >>> ! * and fork() remains. >>> >>> David >>> ----- >>> >>>> -Rob >>>> >>>> On 06/11/13 01:09, David Holmes wrote: >>>>> Hi Rob, >>>>> >>>>> How different is this to the JDK 8 version? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/11/2013 7:24 AM, Rob McKenna wrote: >>>>>> .. >>>>>> >>>>>> http://cr.openjdk.java.net/~robm/5049299/7/webrev.01/ >>>>>> >>>>>> -Rob >>>>>> >>>>>> On 05/11/13 21:23, Rob McKenna wrote: >>>>>>> Hi folks, >>>>>>> >>>>>>> I'd like to backport this change to JDK7. Note: this fix uses >>>>>>> posix_spawn by default on Mac OSX only. On Solaris fork will remain >>>>>>> the default behaviour. >>>>>>> >>>>>>> I've just noticed that there is a problem with the testcase on >>>>>>> Solaris >>>>>>> in that it will test fork twice. (and won't test posix_spawn) I'll >>>>>>> figure out a way around this, but in the mean time I'd like to get >>>>>>> the >>>>>>> ball rolling on this review anyway. >>>>>>> >>>>>>> -Rob >>>>>>> >>>>>>> >>>>>> >>>> >> From joel.franck at oracle.com Fri Nov 8 13:34:15 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 8 Nov 2013 14:34:15 +0100 Subject: RFR: JDK-8028055: (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true Message-ID: <20131108133415.GB6364@oracle.com> Hi Please review fix for: https://bugs.openjdk.java.net/browse/JDK-8028055 (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true As Peter observed here [1] the current fix is incomplete as it does not work when -Dsun.reflect.noInflation=true is set. Also included is a modification of ReflectUtil.isVMAnonymousClass(cls) to not allocate new Strings, guided by performance numbers from Peter [2]. webrev here: http://cr.openjdk.java.net/~jfranck/8028055/webrev.00/ [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022872.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022955.html cheers /Joel From Alan.Bateman at oracle.com Fri Nov 8 14:00:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Nov 2013 14:00:47 +0000 Subject: RFR: 8026330: java.util.Base64 urlEncoder should omit padding In-Reply-To: <527A8DF6.1070603@oracle.com> References: <527A8DF6.1070603@oracle.com> Message-ID: <527CEE8F.3040303@oracle.com> On 06/11/2013 18:44, Xueming Shen wrote: > Hi, > > The latest spec and implementation of java.util.Base64.getXXXEncoder() > is to add appropriate padding character(s) at the end of the output > encoded data stream, to follow the note explicitly specified in the > RFC > > Implementations MUST include appropriate pad characters at the end > of encoded data unless the specification referring to this document > explicitly states otherwise. > > However the RFE also mentions that > > In some circumstances, the use of padding ("=") in base-encoded data > is not required or used... > > Feedback so far also suggests that Base64.encoder without padding might > be desired in some real world use scenario. > > So here is the webrev to add a new method to the Encoder class to return > a non-padding version. > > http://cr.openjdk.java.net/~sherman/8026330/webrev The API looks okay although some developers might not initially recognize that an Encoder is immutable. In particularly, this statement might not be clear: "This instance of encoder is unaffected by this invocation." What you would think about including an example in the javadoc so that it's clear how to get an Encoder that doesn't emit padding? Otherwise this looks good except that I wonder about needing to eagerly create all 6 Encoders. So are you trying to get this into 8 or are you thinking of holding this to 9? -Alan. From chris.hegarty at oracle.com Fri Nov 8 14:47:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Nov 2013 14:47:23 +0000 Subject: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java) In-Reply-To: <527C4BDB.9030102@oracle.com> References: <527B65D1.8090400@oracle.com> <527B7733.1010101@oracle.com> <527B7AAE.1090703@oracle.com> <527B947C.3030405@oracle.com> <527BAABB.7050202@oracle.com> <527BE437.4000905@oracle.com> <527C4BDB.9030102@oracle.com> Message-ID: <527CF97B.9010406@oracle.com> Alan, > An alternative might be to just throw the IOException with > InterruptedException as the cause. Perfect. Updated in the new webrev. Dan, You are completely correct. I was only catering for the case where "java.nio.file.FileSystemException: : The process cannot access the file because it is being used by another process." Where the delete "succeeds" then we need to wait until the underlying platform delete completes, i.e. the file no longer exists. Updated webrev ( with only the diff from the previous ) : http://cr.openjdk.java.net/~chegar/fileUtils.02/webrev/ Thanks, -Chris. On 08/11/2013 02:26, Dan Xu wrote: > > On 11/07/2013 11:04 AM, Alan Bateman wrote: >> On 07/11/2013 14:59, Chris Hegarty wrote: >>> Given both Michael and Alan's comments. I've update the webrev: >>> http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/ >>> >>> 1) more descriptive method names >>> 2) deleteXXX methods return if interrupted, leaving the >>> interrupt status set >>> 3) Use Files.copy with REPLACE_EXISTING >>> 4) Use SimpleFileVisitor, rather than FileVisitor >>> >> This looks better although interrupting the sleep means that the >> deleteXXX will quietly terminate with the interrupt status set (which >> could be awkward to diagnose if used with tests that are also using >> Thread.interrupt). An alternative might be to just throw the >> IOException with InterruptedException as the cause. >> >> -Alan. >> >> > Hi Chris, > > In the method, deleteFileWithRetry0(), it assumes that if any other > process is accessing the same file, the delete operation, > Files.delete(), will throw out IOException on Windows. But I don't see > this assumption is always true when I investigated this issue on > intermittent test failures. > > When Files.delete() method is called, it finally calls DeleteFile or > RemoveDirectory functions based on whether the target is a file or > directory. And these Windows APIs only mark the target for deletion on > close and return immediately without waiting the operation to be > completed. If another process is accessing the file in the meantime, the > delete operation does not occur and the target file stays at > delete-pending status until that open handle is closed. It basically > implies that DeleteFile and RemoveDirectory is like an async operation. > Therefore, we cannot assume that the file/directory is deleted after > Files.delete() returns or File.delete() returns true. > > When checking those intermittently test failures, I find the test > normally succeeds on the Files.delete() call. But due to the > interference of Anti-virus or other Windows daemon services, the target > file changes to delete-pending status. And the immediately following > operation fails due the target file still exists, but our tests assume > the target file is already gone. Because the delete-pending status of a > file usually last for a very short time which depends on the > interference source, such failures normally happens when we recursively > delete a folder or delete-and-create a file with the same file name at a > high frequency. > > It is basically a Windows API design or implementation issue. I have > logged an enhancement, JDK-8024496, to solve it from Java library layer. > Currently, I have two strategies in mind. One is to make the delete > operation blocking, which means to make sure the file/directory is > deleted before the return. The other is to make sure the delete-pending > file does not lead to a failure of subsequent file operations. But they > both has pros and cons. > > Thank! > > -Dan From ygaevsky at azulsystems.com Fri Nov 8 15:20:15 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Fri, 8 Nov 2013 15:20:15 +0000 Subject: 8028027: serialver should emit declaration with the 'private' modifier Message-ID: > Well, it would be more consistent to check for existence of protected or public serialVersionUID with Reflection API and change the serialver output accordingly. Please see suggested fix and its output below. Thanks, -Yuri $ serialver java.security.PublicKey java.security.PublicKey: public static final long serialVersionUID = 7187392471159151072L; $ serialver java.lang.Exception java.lang.Exception: static final long serialVersionUID = -3387516993124229948L; $ serialver java.lang.AssertionError java.lang.AssertionError: private static final long serialVersionUID = -5013299493970297370L; $ serialver javax.xml.ws.soap.SOAPFaultException javax.xml.ws.soap.SOAPFaultException: private static final long serialVersionUID = -104968645459360720L; $ hg diff diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java b/src/share/classes/sun/tools/serialver/SerialVer.java --- a/src/share/classes/sun/tools/serialver/SerialVer.java +++ b/src/share/classes/sun/tools/serialver/SerialVer.java @@ -38,6 +38,7 @@ import java.net.MalformedURLException; import java.util.StringTokenizer; import sun.net.www.ParseUtil; +import java.lang.reflect.Modifier; public class SerialVer extends Applet { GridBagLayout gb; @@ -211,7 +212,17 @@ Class cl = Class.forName(classname, false, loader); ObjectStreamClass desc = ObjectStreamClass.lookup(cl); if (desc != null) { - return " static final long serialVersionUID = " + + String ams = ""; + try { + final int mod = + cl.getDeclaredField("serialVersionUID").getModifiers(); + ams = Modifier.isPublic(mod) ? "public" + : Modifier.isProtected(mod) ? "protected" + : Modifier.isPrivate(mod) ? "private" : ""; + } catch (NoSuchFieldException nsfe) { + ams = "private"; + } + return " " + ams + " static final long serialVersionUID = " + desc.getSerialVersionUID() + "L;"; } else { return null; From vladimir.x.ivanov at oracle.com Fri Nov 8 15:25:28 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 08 Nov 2013 19:25:28 +0400 Subject: RFR (XS): 8027823: catchException combinator fails with 9 argument target Message-ID: <527D0268.3040407@oracle.com> http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/ MethodHandleImpl.makeGuardWithCatch has special invokers (GuardWithCatch.invoke_L*) for methods with arity up to 8. When method arity is larger, generic invoker (GuardWithCatch.invoke_V) is used. Generic invoker expects GuardWithCatch.target & GuardWithCatch.catcher method handles to have (Object... av)Object type, but they can reference arbitrary methods, so type conversion is needed. makeSpreadArguments takes care of parameters' type conversion, but return type is left as is. That's the reason why GuardWithCatch.invoke_V fails to invoke both target or catcher. The fix is to add return type conversion on both paths. Testing: failing test, test/java/lang/invoke/ Thanks! Best regards, Vladimir Ivanov JBS: https://bugs.openjdk.java.net/browse/JDK-8027823 From mandy.chung at oracle.com Fri Nov 8 15:55:05 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 08 Nov 2013 15:55:05 +0000 Subject: hg: jdk8/tl/jdk: 8027351: (ref) Private finalize method invoked in preference to protected superclass method Message-ID: <20131108155536.2E54962470@hg.openjdk.java.net> Changeset: 41d7ce111bd8 Author: mchung Date: 2013-11-08 07:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41d7ce111bd8 8027351: (ref) Private finalize method invoked in preference to protected superclass method Reviewed-by: alanb, dholmes, mr, plevart, psandoz ! makefiles/lib/CoreLibraries.gmk ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjava/reorder-sparc ! makefiles/mapfiles/libjava/reorder-sparcv9 ! makefiles/mapfiles/libjava/reorder-x86 ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ref/Finalizer.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/VM.java + test/java/lang/ref/FinalizeOverride.java From chris.hegarty at oracle.com Fri Nov 8 16:13:27 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Nov 2013 16:13:27 +0000 Subject: hg: jdk8/tl/jdk: 8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface Message-ID: <20131108161339.A426462472@hg.openjdk.java.net> Changeset: 3112729d6b74 Author: tyan Date: 2013-11-08 15:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3112729d6b74 8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface Reviewed-by: chegar ! test/java/net/MulticastSocket/TestInterfaces.java ! test/java/net/NetworkInterface/Equals.java From chris.hegarty at oracle.com Fri Nov 8 16:17:23 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Nov 2013 16:17:23 +0000 Subject: hg: jdk8/tl/jdk: 8019834: InetAddress.getByName hangs for bad IPv6 literals Message-ID: <20131108161736.E58A062473@hg.openjdk.java.net> Changeset: 771c77b49bb6 Author: chegar Date: 2013-11-08 15:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771c77b49bb6 8019834: InetAddress.getByName hangs for bad IPv6 literals Reviewed-by: alanb ! src/share/classes/java/net/InetAddress.java ! test/java/net/ipv6tests/BadIPv6Addresses.java From xueming.shen at oracle.com Fri Nov 8 16:42:12 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Nov 2013 08:42:12 -0800 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <52791F14.2080305@oracle.com> References: <52791F14.2080305@oracle.com> Message-ID: <527D1464.3080508@oracle.com> looks fine. I would assume you've also run the corresponding tests at test/closed repo. -Sherman On 11/5/2013 8:38 AM, Aleksej Efimov wrote: > Hi, > > Can I have a review for tzdata2013h integration [1]. The webrev link can be located here [2]. > > The following test sets were executed on build with fix: > test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter > > And here is the list of failures: > FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% > FAILED: java/time/tck/java/time/TCKInstant.java %1% > FAILED: java/time/tck/java/time/TCKLocalDate.java %1% > FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% > FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% > FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% > FAILED: java/util/Calendar/JavatimeTest.java %1% > > FAILED: sun/util/calendar/zi/TestZoneInfo310.java > > > The group %1% tests failures relates to the JDK-8027622 bug and are expected (actually, it was already resolved in hotspot repo). > The 'TestZoneInfo310' test failure is an actual error in current ZoneInfoFile class implementation in JDK. I have filled a bug for this one [3] and will send a separate review with fix later today. > > [1] https://bugs.openjdk.java.net/browse/JDK-8027370 > [2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8027848 From mandy.chung at oracle.com Fri Nov 8 17:44:27 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 08 Nov 2013 17:44:27 +0000 Subject: hg: jdk8/tl/jdk: 8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351 Message-ID: <20131108174442.42C5662476@hg.openjdk.java.net> Changeset: 1c9ba18198d5 Author: mchung Date: 2013-11-08 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c9ba18198d5 8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351 Reviewed-by: alanb - src/share/native/java/lang/ref/Finalizer.c From stuart.marks at oracle.com Fri Nov 8 18:28:40 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 8 Nov 2013 10:28:40 -0800 (PST) Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <527CC45E.5050902@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> Message-ID: <527D2D58.1010703@oracle.com> Hi Tristan, Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed package. Classes in a named package cannot import classes from the unnamed package. We've run into problems with this before. Eventually, we should move TestLibrary a named package. I think it's possible to work around this without too much difficulty. Note that classes in the unnamed package can import classes from named packages. So, perhaps you can put the RmiBench main class in the unnamed package so it has access to TestLibrary. Then have the benchmarks themselves in the bench.rmi package. The config file already references the benchmarks by fully qualified class name (e.g., "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able to get this to work. s'marks On 11/8/13 3:00 AM, Tristan Yan wrote: > /Thank you, Stuart > There is one review point I want to ask you opinion. Which is the reason that > I moved from test/java/rmi/reliability/benchmark/bench/rmi to > test/java/rmi/reliability/benchmark is Main.java need access class TestLibrary > for supporting random port. TestLibrary is a unpackage class, I couldn't find > a way to let a class which has Package to access the class without package. Do > you have suggestion on that? > Thank you so much. > Tristan > > On 11/06/2013 09:50 AM, Stuart Marks wrote: > / >> / >> / / >> On 11/1/13 9:18 AM, Tristan Yan wrote: >> / >>> /Hi Everyone >>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>> / / >>> Description: >>> 1. Convert shell script test to Java program test. >>> 2. Using random server port by reusing Darryl Mocek's work to replace fixed >>> server port. >>> 3. Using java Process class to start client process. >>> 4. Also convert other shell script test runSerialBench.sh to java program >>> test also >>> / >> / >> Hi Tristan, >> / / >> Several comments on this webrev. >> / / >> / / >> ** The original arrangement within the test/java/rmi/reliability/benchmark >> directory had the main benchmark files (scripts) at the top, some benchmark >> framework files in the "bench" subdirectory, and the actual RMI and >> serialization benchmarks in bench/rmi and bench/serial subdirectories. >> / / >> The webrev moves all the RMI benchmarks to the top benchmark directory but >> leaves the serial benchmarks in bench/serial. The RMI benchmarks are now all >> cluttering the top directory, but the main serial benchmark test is now >> buried in the bench/serial directory. The nice organization that was there >> before is now spoiled. Is this rearrangement necessary in order to convert >> the scripts to Java? I would prefer the original arrangement be left in place. >> / / >> / / >> ** The RMI benchmark Main.java file has a @run tag of the form, >> / / >> @run main/othervm/policy=policy.all/timeout=1800 -server Main -c config >> / / >> There is a subtle but serious problem here: the -server option is passed to >> the >>JVM<< and not as an argument to the main() method. The main() method >> gets neither a -server nor a -client argument, so its default "run mode" as >> defined by the benchmark itself is SAMEVM. This runs the client and server in >> the same JVM, which is different from the shell script, which ran separate >> client and server JVMs. >> / / >> / / >> ** The logic to process the -server argument still expects to take a port, >> even though the port is assigned automatically. So the obvious fix to the above, >> / / >> @run main/othervm/policy=policy.all/timeout=1800 Main -server -c config >> / / >> doesn't work, since a port is missing. The logic to increment the argument >> index to collect the port argument should be removed. Also, the -server line >> should be restored to the usage message, but without the port argument. >> / / >> / / >> ** After this is done, the client's command line is constructed improperly. >> The command line ends up looking something like this: >> / / >> java client -cp Main client localhost:58583 -c config >> / / >> The word "client" appears twice, but what's really required is "-client" to >> appear as an argument after Main. >> / / >> / / >> ** The client is run using ProcessBuilder, which by default sends stdout and >> stderr to pipes to be read by the parent. But the parent never reads them, >> thus any messages from the client are never seen. The client is the one that >> emits the benchmark report, so its output needs to be seen. It might be >> sufficient to have the client inherit the parent's stdout and stderr. This >> might intermix the client's and server's output, but it's better than nothing. >> / / >> / / >> ** The config file is checked with the following code: >> / / >> try { >> confFile = args[i]; >> confstr = new FileInputStream(System.getProperty("test.src") >> + System.getProperty("file.separator") + confFile); >> } catch (IOException e) { >> die("Error: unable to open \"" + args[i] + "\""); >> } >> / / >> This is potentially misleading, as the message doesn't print the actual >> filename that was attempted to be opened. >> / / >> This is important, as the test.src property doesn't exist in the client JVM. >> / / >> Note that the original shell script passed full pathnames for the config file >> to both the client and the server. The new @run tag merely says "-c config" >> which redefines the config filename to be relative to the test.src directory. >> You could pass -Dtest.src=... to the client, but it seems like there should >> be something better than can be done. >> / / >> / / >> ** The client needs to have its security policy set up. This is missing from >> the construction of the client's command line. >> / / >> / / >> ** ProcessBuilder takes a List for its command; there is no need to >> turn the list into an array. >> / / >> / / >> ** In the benchmark main methods, code of the form, >> / / >> while (true) { >> runBenchmarks(); >> if (exitRequested) { >> System.exit(); >> } >> } >> / / >> was replaced with >> / / >> while (!exitRequested) { >> runBenchmarks(); >> } >> / / >> This is a subtle logic change, in that the former code always executed the >> loop at least once. It seems unlikely, but it's possible that a timer could >> set exitRequested before loop entry, resulting in the benchmark running zero >> times. I guess, if you really want to clean this up (we do need to avoid >> System.exit in jtreg tests), use a do-while loop instead. >> / / >> / / >> ** Don't forget to remove the 7190106/runRmiBench.sh entry from ProblemList.txt. >> / / >> / / >> ** Remove the references to RMISecurityManager and just use SecurityManager. >> This is just general cleanup. (I deprecated RMISecurityManager last week.) :-) >> / / >> / / >> It would be good if you could fix up these issues and post another webrev. >> / / >> Thanks. >> / / >> s'marks >> / / >> / / >> / / >> / / >> / >>> /Thank you >>> Tristan >>> / / >>> On 01/11/2013 23:58, Stuart Marks wrote: >>> / >>>> /On 10/31/13 10:22 PM, Tristan Yan wrote: >>>> / >>>>> /I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>> on my research, it looks like the issue of fixed port was already addressed >>>>> by Stuart Marks in other RMI tests which are Java based. I would like to >>>>> reuse his solution, however it does not work for shell based tests. >>>>> / >>>> / >>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>> / / >>>> Was the patch attached to your message? If so, it didn't get through. Most >>>> OpenJDK mailing lists strip off attachments before forwarding the message to >>>> the recipients. >>>> / / >>>> / >>>>> /2. My recommendation would be to convert this shell script test into Java >>>>> based test and re-use the dynamic port allocation solution by Stuart Marks to >>>>> address the issue >>>>> / / >>>>> 3. Also this test was written with server/client mode in shell script. In the >>>>> past there have been sync issues between server/client which caused the test >>>>> to fail. If we convert the shell script into Java based test, it would avoid >>>>> using "sleep 10" mechanism to allow for server and client to start up and >>>>> also give us better control in synchronizing server and client. >>>>> / >>>> / >>>> (Background for interested readers.) In general, yes, it's quite difficult to >>>> make reliable shell tests, especially for multi-process tests like this one. >>>> There is the unique port issue, and there is also the issue of how long for >>>> the client to wait until the server is ready. Error handling is also a >>>> problem, for example, if one of the JVMs gets an unexpected exception, it's >>>> easy for shell tests to mishandle this case. They might hang or erroneously >>>> report success. >>>> / / >>>> -- >>>> / / >>>> If this is a rewrite, it's probably fairly large, so you need to upload it >>>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>> / / >>>> Thanks. >>>> / / >>>> s'marks >>>> / >>> / >>> / > / > / From stuart.marks at oracle.com Fri Nov 8 18:47:59 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 08 Nov 2013 10:47:59 -0800 Subject: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: References: Message-ID: <527D31DF.3030106@oracle.com> On 11/8/13 7:20 AM, Yuri Gaevsky wrote: >> Well, it would be more consistent to check for existence of protected or public serialVersionUID with Reflection API and change the serialver output accordingly. > > Please see suggested fix and its output below. This change isn't consistent with the intent of the 'serialver' utility. Its intent is to produce a declaration that's "suitable for copying into an evolving class." [1] (Clearly, this means the source code of a class.) The spec [2] "strongly advises" that serialVersionUID be private. As such, serialver should follow the strong advice given in the spec. If there happens to be a declaration in the class that, probably mistakenly, goes against this advice, serialver shouldn't emit a line that perpetuates this mistake. One can use "javap -v" to determine the presence of serialVersionUID field, including its modifiers, if that's what's desired. s'marks [1] http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/serialver.html [2] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html > > Thanks, > -Yuri > > $ serialver java.security.PublicKey > java.security.PublicKey: public static final long serialVersionUID = 7187392471159151072L; > > $ serialver java.lang.Exception > java.lang.Exception: static final long serialVersionUID = -3387516993124229948L; > > $ serialver java.lang.AssertionError > java.lang.AssertionError: private static final long serialVersionUID = -5013299493970297370L; > > $ serialver javax.xml.ws.soap.SOAPFaultException > javax.xml.ws.soap.SOAPFaultException: private static final long serialVersionUID = -104968645459360720L; > > > $ hg diff > diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java b/src/share/classes/sun/tools/serialver/SerialVer.java > --- a/src/share/classes/sun/tools/serialver/SerialVer.java > +++ b/src/share/classes/sun/tools/serialver/SerialVer.java > @@ -38,6 +38,7 @@ > import java.net.MalformedURLException; > import java.util.StringTokenizer; > import sun.net.www.ParseUtil; > +import java.lang.reflect.Modifier; > > public class SerialVer extends Applet { > GridBagLayout gb; > @@ -211,7 +212,17 @@ > Class cl = Class.forName(classname, false, loader); > ObjectStreamClass desc = ObjectStreamClass.lookup(cl); > if (desc != null) { > - return " static final long serialVersionUID = " + > + String ams = ""; > + try { > + final int mod = > + cl.getDeclaredField("serialVersionUID").getModifiers(); > + ams = Modifier.isPublic(mod) ? "public" > + : Modifier.isProtected(mod) ? "protected" > + : Modifier.isPrivate(mod) ? "private" : ""; > + } catch (NoSuchFieldException nsfe) { > + ams = "private"; > + } > + return " " + ams + " static final long serialVersionUID = " + > desc.getSerialVersionUID() + "L;"; > } else { > return null; > From joe.darcy at oracle.com Fri Nov 8 19:40:17 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 08 Nov 2013 11:40:17 -0800 Subject: JDK RFR to clean-up lint warnings in reflection implementation Message-ID: <527D3E21.8090000@oracle.com> Hello, Please review the simple patch below which addresses a handful of raw types lint warning in the core reflection implementation code. (If memory serves, this code dates back from a time during the development of JDK 5 when wildcards could not be used with arrays; before the release shipped, that combination was allowed.) Thanks, -Joe diff -r 46982ca895b4 src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri Nov 08 18:54:29 2013 +0000 +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri Nov 08 11:37:54 2013 -0800 @@ -52,7 +52,7 @@ } private void validateConstructorArguments() { - TypeVariable/**/[] formals = rawType.getTypeParameters(); + TypeVariable[] formals = rawType.getTypeParameters(); // check correct arity of actual type args if (formals.length != actualTypeArguments.length){ throw new MalformedParameterizedTypeException(); diff -r 46982ca895b4 src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java --- a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Fri Nov 08 18:54:29 2013 +0000 +++ b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Fri Nov 08 11:37:54 2013 -0800 @@ -42,7 +42,7 @@ public abstract class GenericDeclRepository extends AbstractRepository { - private TypeVariable[] typeParams; // caches the formal type parameters + private TypeVariable[] typeParams; // caches the formal type parameters protected GenericDeclRepository(String rawSig, GenericsFactory f) { super(rawSig, f); @@ -64,7 +64,7 @@ * Return the formal type parameters of this generic declaration. * @return the formal type parameters of this generic declaration */ - public TypeVariable/**/[] getTypeParameters(){ + public TypeVariable[] getTypeParameters(){ if (typeParams == null) { // lazily initialize type parameters // first, extract type parameter subtree(s) from AST FormalTypeParameter[] ftps = getTree().getFormalTypeParameters(); From Lance.Andersen at oracle.com Fri Nov 8 19:58:13 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 8 Nov 2013 14:58:13 -0500 Subject: JDK RFR to clean-up lint warnings in reflection implementation In-Reply-To: <527D3E21.8090000@oracle.com> References: <527D3E21.8090000@oracle.com> Message-ID: looks fine Joe On Nov 8, 2013, at 2:40 PM, Joe Darcy wrote: > Hello, > > Please review the simple patch below which addresses a handful of raw types lint warning in the core reflection implementation code. > > (If memory serves, this code dates back from a time during the development of JDK 5 when wildcards could not be used with arrays; before the release shipped, that combination was allowed.) > > Thanks, > > -Joe > > diff -r 46982ca895b4 src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java > --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri Nov 08 18:54:29 2013 +0000 > +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri Nov 08 11:37:54 2013 -0800 > @@ -52,7 +52,7 @@ > } > > private void validateConstructorArguments() { > - TypeVariable/**/[] formals = rawType.getTypeParameters(); > + TypeVariable[] formals = rawType.getTypeParameters(); > // check correct arity of actual type args > if (formals.length != actualTypeArguments.length){ > throw new MalformedParameterizedTypeException(); > diff -r 46982ca895b4 src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java > --- a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Fri Nov 08 18:54:29 2013 +0000 > +++ b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Fri Nov 08 11:37:54 2013 -0800 > @@ -42,7 +42,7 @@ > public abstract class GenericDeclRepository > extends AbstractRepository { > > - private TypeVariable[] typeParams; // caches the formal type parameters > + private TypeVariable[] typeParams; // caches the formal type parameters > > protected GenericDeclRepository(String rawSig, GenericsFactory f) { > super(rawSig, f); > @@ -64,7 +64,7 @@ > * Return the formal type parameters of this generic declaration. > * @return the formal type parameters of this generic declaration > */ > - public TypeVariable/**/[] getTypeParameters(){ > + public TypeVariable[] getTypeParameters(){ > if (typeParams == null) { // lazily initialize type parameters > // first, extract type parameter subtree(s) from AST > FormalTypeParameter[] ftps = getTree().getFormalTypeParameters(); > -------------- next part -------------- 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 chris.hegarty at oracle.com Fri Nov 8 18:56:10 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Nov 2013 18:56:10 +0000 Subject: hg: jdk8/tl/jdk: 8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine Message-ID: <20131108185622.442AF6247A@hg.openjdk.java.net> Changeset: 46982ca895b4 Author: tyan Date: 2013-11-08 18:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46982ca895b4 8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6433018.java From Alan.Bateman at oracle.com Fri Nov 8 20:06:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Nov 2013 20:06:59 +0000 Subject: JDK RFR to clean-up lint warnings in reflection implementation In-Reply-To: <527D3E21.8090000@oracle.com> References: <527D3E21.8090000@oracle.com> Message-ID: <527D4463.5090404@oracle.com> On 08/11/2013 19:40, Joe Darcy wrote: > Hello, > > Please review the simple patch below which addresses a handful of raw > types lint warning in the core reflection implementation code. > > (If memory serves, this code dates back from a time during the > development of JDK 5 when wildcards could not be used with arrays; > before the release shipped, that combination was allowed.) This looks okay to me (and I think we have the same thing in a few other areas). -Alan From mandy.chung at oracle.com Fri Nov 8 20:14:00 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 08 Nov 2013 20:14:00 +0000 Subject: hg: jdk8/tl/jdk: 8025985: com.sun.management.OSMBeanFactory should not be public Message-ID: <20131108201413.E279E62480@hg.openjdk.java.net> Changeset: 40ca9e4866de Author: mchung Date: 2013-11-08 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40ca9e4866de 8025985: com.sun.management.OSMBeanFactory should not be public Reviewed-by: alanb, erikj, ihse, jbachorik ! makefiles/lib/ServiceabilityLibraries.gmk ! makefiles/mapfiles/libmanagement/mapfile-vers + src/share/classes/sun/management/BaseOperatingSystemImpl.java ! src/share/classes/sun/management/ManagementFactoryHelper.java - src/share/classes/sun/management/OperatingSystemImpl.java - src/solaris/classes/com/sun/management/OSMBeanFactory.java - src/solaris/classes/com/sun/management/UnixOperatingSystem.java + src/solaris/classes/sun/management/OperatingSystemImpl.java - src/solaris/native/com/sun/management/LinuxOperatingSystem.c - src/solaris/native/com/sun/management/MacosxOperatingSystem.c - src/solaris/native/com/sun/management/SolarisOperatingSystem.c - src/solaris/native/com/sun/management/UnixOperatingSystem_md.c + src/solaris/native/sun/management/LinuxOperatingSystem.c + src/solaris/native/sun/management/MacosxOperatingSystem.c + src/solaris/native/sun/management/OperatingSystemImpl.c + src/solaris/native/sun/management/SolarisOperatingSystem.c - src/windows/classes/com/sun/management/OSMBeanFactory.java - src/windows/classes/com/sun/management/OperatingSystem.java + src/windows/classes/sun/management/OperatingSystemImpl.java - src/windows/native/com/sun/management/OperatingSystem_md.c + src/windows/native/sun/management/OperatingSystemImpl.c From joe.darcy at oracle.com Fri Nov 8 20:19:39 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 08 Nov 2013 20:19:39 +0000 Subject: hg: jdk8/tl/jdk: 8028076: Correct raw type lint warnings in core reflection implementation classes Message-ID: <20131108201953.3E21B62483@hg.openjdk.java.net> Changeset: 11376ad23e21 Author: darcy Date: 2013-11-08 12:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11376ad23e21 8028076: Correct raw type lint warnings in core reflection implementation classes Reviewed-by: lancea, alanb ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java From joe.darcy at oracle.com Fri Nov 8 20:24:10 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 08 Nov 2013 12:24:10 -0800 Subject: JDK RFR to clean-up lint warnings in reflection implementation In-Reply-To: <527D4463.5090404@oracle.com> References: <527D3E21.8090000@oracle.com> <527D4463.5090404@oracle.com> Message-ID: <527D486A.20005@oracle.com> On 11/08/2013 12:06 PM, Alan Bateman wrote: > On 08/11/2013 19:40, Joe Darcy wrote: >> Hello, >> >> Please review the simple patch below which addresses a handful of raw >> types lint warning in the core reflection implementation code. >> >> (If memory serves, this code dates back from a time during the >> development of JDK 5 when wildcards could not be used with arrays; >> before the release shipped, that combination was allowed.) > This looks okay to me (and I think we have the same thing in a few > other areas). > Hi Alan, Yes; over 1/3 of the remaining lint warnings in core-libs are for the use of raw types. There are many uses of "Class" or "Class[]" instead of "Class" or "Class[]". -Joe From joel.franck at oracle.com Fri Nov 8 20:34:33 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Fri, 8 Nov 2013 21:34:33 +0100 Subject: JDK RFR to clean-up lint warnings in reflection implementation In-Reply-To: <527D3E21.8090000@oracle.com> References: <527D3E21.8090000@oracle.com> Message-ID: <4EFEE9F6-24FC-43DE-97A1-7A0E23688416@oracle.com> Looks good Joe. cheers /Joel On 8 nov 2013, at 20:40, Joe Darcy wrote: > Hello, > > Please review the simple patch below which addresses a handful of raw types lint warning in the core reflection implementation code. > > (If memory serves, this code dates back from a time during the development of JDK 5 when wildcards could not be used with arrays; before the release shipped, that combination was allowed.) > > Thanks, > > -Joe > > diff -r 46982ca895b4 src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java > --- a/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri Nov 08 18:54:29 2013 +0000 > +++ b/src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Fri Nov 08 11:37:54 2013 -0800 > @@ -52,7 +52,7 @@ > } > > private void validateConstructorArguments() { > - TypeVariable/**/[] formals = rawType.getTypeParameters(); > + TypeVariable[] formals = rawType.getTypeParameters(); > // check correct arity of actual type args > if (formals.length != actualTypeArguments.length){ > throw new MalformedParameterizedTypeException(); > diff -r 46982ca895b4 src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java > --- a/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Fri Nov 08 18:54:29 2013 +0000 > +++ b/src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Fri Nov 08 11:37:54 2013 -0800 > @@ -42,7 +42,7 @@ > public abstract class GenericDeclRepository > extends AbstractRepository { > > - private TypeVariable[] typeParams; // caches the formal type parameters > + private TypeVariable[] typeParams; // caches the formal type parameters > > protected GenericDeclRepository(String rawSig, GenericsFactory f) { > super(rawSig, f); > @@ -64,7 +64,7 @@ > * Return the formal type parameters of this generic declaration. > * @return the formal type parameters of this generic declaration > */ > - public TypeVariable/**/[] getTypeParameters(){ > + public TypeVariable[] getTypeParameters(){ > if (typeParams == null) { // lazily initialize type parameters > // first, extract type parameter subtree(s) from AST > FormalTypeParameter[] ftps = getTree().getFormalTypeParameters(); > From ygaevsky at azulsystems.com Fri Nov 8 20:52:28 2013 From: ygaevsky at azulsystems.com (Yuri Gaevsky) Date: Fri, 8 Nov 2013 20:52:28 +0000 Subject: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: <527D31DF.3030106@oracle.com> References: <527D31DF.3030106@oracle.com> Message-ID: Stuart, Sorry, but such inconsistency between serialver/javap is a bug (IMHO, of course). > If there happens to be a declaration in the class that, probably mistakenly, goes against this advice, serialver shouldn't emit a line that perpetuates this mistake. I would argue that for any real-life API it's almost impossible to fix such explicitly-defined "bad" (i.e. public/protected) SVUID in any compatible way, so emitting 'private' will not help there, unfortunately. -Yuri -----Original Message----- From: Stuart Marks [mailto:stuart.marks at oracle.com] Sent: Friday, November 8, 2013 10:48 PM To: Yuri Gaevsky Cc: Alan Bateman; core-libs-dev Subject: Re: 8028027: serialver should emit declaration with the 'private' modifier On 11/8/13 7:20 AM, Yuri Gaevsky wrote: >> Well, it would be more consistent to check for existence of protected or public serialVersionUID with Reflection API and change the serialver output accordingly. > > Please see suggested fix and its output below. This change isn't consistent with the intent of the 'serialver' utility. Its intent is to produce a declaration that's "suitable for copying into an evolving class." [1] (Clearly, this means the source code of a class.) The spec [2] "strongly advises" that serialVersionUID be private. As such, serialver should follow the strong advice given in the spec. If there happens to be a declaration in the class that, probably mistakenly, goes against this advice, serialver shouldn't emit a line that perpetuates this mistake. One can use "javap -v" to determine the presence of serialVersionUID field, including its modifiers, if that's what's desired. s'marks [1] http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/serialver.html [2] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html > > Thanks, > -Yuri > > $ serialver java.security.PublicKey > java.security.PublicKey: public static final long serialVersionUID = 7187392471159151072L; > > $ serialver java.lang.Exception > java.lang.Exception: static final long serialVersionUID = -3387516993124229948L; > > $ serialver java.lang.AssertionError > java.lang.AssertionError: private static final long serialVersionUID = -5013299493970297370L; > > $ serialver javax.xml.ws.soap.SOAPFaultException > javax.xml.ws.soap.SOAPFaultException: private static final long serialVersionUID = -104968645459360720L; > > > $ hg diff > diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java > b/src/share/classes/sun/tools/serialver/SerialVer.java > --- a/src/share/classes/sun/tools/serialver/SerialVer.java > +++ b/src/share/classes/sun/tools/serialver/SerialVer.java > @@ -38,6 +38,7 @@ > import java.net.MalformedURLException; > import java.util.StringTokenizer; > import sun.net.www.ParseUtil; > +import java.lang.reflect.Modifier; > > public class SerialVer extends Applet { > GridBagLayout gb; > @@ -211,7 +212,17 @@ > Class cl = Class.forName(classname, false, loader); > ObjectStreamClass desc = ObjectStreamClass.lookup(cl); > if (desc != null) { > - return " static final long serialVersionUID = " + > + String ams = ""; > + try { > + final int mod = > + cl.getDeclaredField("serialVersionUID").getModifiers(); > + ams = Modifier.isPublic(mod) ? "public" > + : Modifier.isProtected(mod) ? "protected" > + : Modifier.isPrivate(mod) ? "private" : ""; > + } catch (NoSuchFieldException nsfe) { > + ams = "private"; > + } > + return " " + ams + " static final long serialVersionUID = " + > desc.getSerialVersionUID() + "L;"; > } else { > return null; > From roger.riggs at oracle.com Fri Nov 8 20:56:31 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 08 Nov 2013 15:56:31 -0500 Subject: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation Message-ID: <527D4FFF.60303@oracle.com> Hi, Please review this correction to the documentation of the serialized form of String. There is no change to the specification or behavior of the serialization of strings. It seemed safer to refer to the serialization specification and remove the incorrect details instead of trying to correct the incorrect details by adding more detail. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/ Thanks, Roger [1 ] JDK-8028041 Serialized Form description of j.l.String is not consistent with the implementation From alan.bateman at oracle.com Fri Nov 8 21:14:47 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 08 Nov 2013 21:14:47 +0000 Subject: hg: jdk8/tl/jdk: 8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f Message-ID: <20131108211501.630EE62488@hg.openjdk.java.net> Changeset: 50df04934e86 Author: alanb Date: 2013-11-08 21:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50df04934e86 8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f Reviewed-by: chegar ! src/share/classes/java/net/InetAddress.java From Alan.Bateman at oracle.com Fri Nov 8 21:34:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Nov 2013 21:34:32 +0000 Subject: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation In-Reply-To: <527D4FFF.60303@oracle.com> References: <527D4FFF.60303@oracle.com> Message-ID: <527D58E8.9020703@oracle.com> On 08/11/2013 20:56, roger riggs wrote: > Hi, > > Please review this correction to the documentation of the serialized > form of String. > There is no change to the specification or behavior of the > serialization of strings. > > It seemed safer to refer to the serialization specification and remove > the > incorrect details instead of trying to correct the incorrect details > by adding more detail. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/ It make sense to reference the spec rather than duplicate how long strings are handled. So looks good to me (assuming the link works as expected when the docs are generated). -Alan. From stuart.marks at oracle.com Fri Nov 8 21:41:22 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 08 Nov 2013 13:41:22 -0800 Subject: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation In-Reply-To: <527D58E8.9020703@oracle.com> References: <527D4FFF.60303@oracle.com> <527D58E8.9020703@oracle.com> Message-ID: <527D5A82.90507@oracle.com> On 11/8/13 1:34 PM, Alan Bateman wrote: > On 08/11/2013 20:56, roger riggs wrote: >> Please review this correction to the documentation of the serialized form of >> String. >> There is no change to the specification or behavior of the serialization of >> strings. >> >> It seemed safer to refer to the serialization specification and remove the >> incorrect details instead of trying to correct the incorrect details by adding >> more detail. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/ > It make sense to reference the spec rather than duplicate how long strings are > handled. So looks good to me (assuming the link works as expected when the docs > are generated). Hi Roger, Yes, I agree with the approach of referencing the spec as well. On the link format, I'd recommend using {@docRoot} instead of a long chain of double dots. (Yes, this is used inconsistent in the javadoc. It's yet another thing to be cleaned up.) s'marks From xueming.shen at oracle.com Fri Nov 8 21:56:35 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Nov 2013 13:56:35 -0800 Subject: RFR: JDK-8027645: Pattern.split() with positive lookahead In-Reply-To: <69D00307-B80A-42F3-8744-DB0F4B5A9DB7@oracle.com> References: <527BE318.3050007@oracle.com> <69D00307-B80A-42F3-8744-DB0F4B5A9DB7@oracle.com> Message-ID: <527D5E13.7080001@oracle.com> On 11/08/2013 01:19 AM, Paul Sandoz wrote: > Hi Sherman. > > When you say: > > + * of the stream. A zero-width match at the beginning however never produces > + * such empty leading substring. > > Is it possible to have a starting sequence of one or more zero-width matches? The matcher.find() always increases its "next find start position" at least one as showed in Matcher.find() impl ("first" starts from -1), so the matcher.find() should keep going forward, never produce more than one zero-length substring. Matcher: public boolean find() { int nextSearchIndex = last; if (nextSearchIndex == first) nextSearchIndex++; ... The webrev has been updated to use your optimized version in splitAsStream(). http://cr.openjdk.java.net/~sherman/8027645/webrev/ Thanks! -Sherman > It would be useful to add a comment on skipping for zero-width match. > > IIUC you could simplify the code in splitAsStream: > > while (matcher.find()) { > nextElement = input.subSequence(current, matcher.start()).toString(); > current = matcher.end(); > if (!nextElement.isEmpty()) { > return true; > } else if (current> 0) // Ignore for zero-width match > emptyElementCount++; > } > } > > That is less efficient for zero-width matching, but how common is that? > > Paul. > > On Nov 7, 2013, at 7:59 PM, Xueming Shen wrote: > >> Hi, >> >> As suggested in the bug report [1] the spec of j.u.Pattern.split() >> does not clearly specify what the expected behavior should be for scenario >> like a zero-width match is found at the beginning of the input string >> (such as whether or not an empty leading string should be included into >> the resulting array), worse, the implementation is not consistent as well >> (for different input cases, such as "Abc".split(...) vs "AbcEfg".split(...)). >> >> The spec also is not clear regarding what the expected behavior should be >> if the size of the input string is 0 [2]. >> >> As a reference, Perl.split() function has clear/explicit spec regarding >> above use scenario [3]. >> >> So the proposed change here is to updatethe spec&impl of Pattern.split() to have >> clear specification for above use scanrio, as Perl does >> >> (1) A zero-length input sequence always results zero-length resulting array >> (instead of returning a string[] only contains an empty string) >> (2) An empty leading substring is included at the beginning of the resulting >> array, when there is a positive-width match at the beginning of the input >> sequence. A zero-width match at the beginning however never produces such >> empty leading substring. >> >> webrev: >> http://cr.openjdk.java.net/~sherman/8027645/webrev/ >> >> Thanks! >> -Sherman >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8027645 >> [2] https://bugs.openjdk.java.net/browse/JDK-6559590 >> [3] http://perldoc.perl.org/functions/split.html >> >> btw:the following perl script is used to verify the perl behavior >> ------------------ >> $str = "AbcEfgHij"; >> @substr = split(/(?=\p{Uppercase})/, $str); >> #$str = "abc efg hij"; >> #@substr = split(/ /, $str); >> print "split[sz=", scalar @substr, "]=[", join(",", @substr), "]\n"; >> ------------------ From xueming.shen at oracle.com Fri Nov 8 22:28:13 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Nov 2013 14:28:13 -0800 Subject: RFR: 8026330: java.util.Base64 urlEncoder should omit padding In-Reply-To: <527CEE8F.3040303@oracle.com> References: <527A8DF6.1070603@oracle.com> <527CEE8F.3040303@oracle.com> Message-ID: <527D657D.2010408@oracle.com> On 11/08/2013 06:00 AM, Alan Bateman wrote: > On 06/11/2013 18:44, Xueming Shen wrote: >> Hi, >> >> The latest spec and implementation of java.util.Base64.getXXXEncoder() >> is to add appropriate padding character(s) at the end of the output >> encoded data stream, to follow the note explicitly specified in the >> RFC >> >> Implementations MUST include appropriate pad characters at the end >> of encoded data unless the specification referring to this document >> explicitly states otherwise. >> >> However the RFE also mentions that >> >> In some circumstances, the use of padding ("=") in base-encoded data >> is not required or used... >> >> Feedback so far also suggests that Base64.encoder without padding might >> be desired in some real world use scenario. >> >> So here is the webrev to add a new method to the Encoder class to return >> a non-padding version. >> >> http://cr.openjdk.java.net/~sherman/8026330/webrev > The API looks okay although some developers might not initially recognize that an Encoder is immutable. In particularly, this statement might not be clear: > > "This instance of encoder is unaffected by this invocation." > > What you would think about including an example in the javadoc so that it's clear how to get an Encoder that doesn't emit padding? I have updated that statement to be more verbose and obvious * *

The encoding scheme of this encoder instance is unaffected by * this invocation. The returned encoder instance should be used for * non-padding encoding operation. * Hope it is now clear enough. Personally I feel it might be clearer than an example like Base64.Encoder nonPaddingEncoder = Base64.getEncoder().withoutPadding(); > > Otherwise this looks good except that I wonder about needing to eagerly create all 6 Encoders. > Given the non-padding encoder is supposed to not be used "frequently" as the standard one, and the encoder is really a "simple"/not-expensive object, I removed the singleton approach for the non-padding encoders. We can add any time later, if requested/ pointed out to be necessary. http://cr.openjdk.java.net/~sherman/8026330/webrev/ > So are you trying to get this into 8 or are you thinking of holding this to 9? > I hope it can get in, as it is requested couple weeks ago. But if it has to be cut off and leave for 9, then be it:-) thanks! -Sherman From bill.shannon at oracle.com Fri Nov 8 22:35:03 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Fri, 08 Nov 2013 14:35:03 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <526AEF87.4000804@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> Message-ID: <527D6717.6090702@oracle.com> Have you had a chance to think about this? Can the MIME decoder be made more lenient, or can I get an option to control this? Bill Shannon wrote on 10/25/13 15:24: > Xueming Shen wrote on 10/25/13 15:19: >> On 10/25/13 2:19 PM, Bill Shannon wrote: >>> If I understand this correctly, this proposes to remove the "lenient" >>> option we've been discussing and just make it always lenient. Is that >>> correct? >> >> Yes. Only for the mime type though. > > That's fine. > >>> Unfortunately, from what you say below, it's still not lenient enough. >>> I'd really like a version that never, ever, for any reason, throws an >>> exception. Yes, that means when you only get a final 6 bits of data >>> you have to make an assumption about what was intended, probably padding >>> it with zeros to 8 bits. >> >> This is something I'm hesitated to do. I can be lenient for the padding end >> because the >> padding character itself is not the real "data", whether or not it's present, >> it's missing or >> it's incorrect/incomplete, it does not impact the integrity of the data. But to >> feed the last >> 6 bits with zero, is really kinda of guessing, NOT decoding. > > I understand. And if the people who write spamming software knew how to > read a spec, we wouldn't have this problem! :-) > > Still, there's a lot of bad data out there on the internet, and people > want the software to do the best job it can to interpret the data. It's > better to guess at the missing 2 bits of data than to lose the last 6 bits > of data. From roger.riggs at oracle.com Fri Nov 8 22:43:12 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 8 Nov 2013 14:43:12 -0800 (PST) Subject: RFR: 8028041 Serialized Form description of j.l.String is not consistent with the implementation In-Reply-To: <527D5A82.90507@oracle.com> References: <527D4FFF.60303@oracle.com> <527D58E8.9020703@oracle.com> <527D5A82.90507@oracle.com> Message-ID: <527D6900.8050600@oracle.com> Hi Stuart, I agree that {@docroot} is preferred. The serialization spec is in a parallel directory to the API spec. The platform/ docs are above the api docs, so at least 1 "../" is needed. I tried it with {@docroot}/../... but the normal docs build defaulted docroot to "/" and the link did not work. Roger On 11/8/2013 4:41 PM, Stuart Marks wrote: > On 11/8/13 1:34 PM, Alan Bateman wrote: >> On 08/11/2013 20:56, roger riggs wrote: >>> Please review this correction to the documentation of the serialized >>> form of >>> String. >>> There is no change to the specification or behavior of the >>> serialization of >>> strings. >>> >>> It seemed safer to refer to the serialization specification and >>> remove the >>> incorrect details instead of trying to correct the incorrect details >>> by adding >>> more detail. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-string-serial-8028041/ >> It make sense to reference the spec rather than duplicate how long >> strings are >> handled. So looks good to me (assuming the link works as expected >> when the docs >> are generated). > > Hi Roger, > > Yes, I agree with the approach of referencing the spec as well. > > On the link format, I'd recommend using {@docRoot} instead of a long > chain of double dots. (Yes, this is used inconsistent in the javadoc. > It's yet another thing to be cleaned up.) > > s'marks From john.r.rose at oracle.com Fri Nov 8 23:26:13 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 8 Nov 2013 15:26:13 -0800 Subject: RFR (XS): 8027823: catchException combinator fails with 9 argument target In-Reply-To: <527D0268.3040407@oracle.com> References: <527D0268.3040407@oracle.com> Message-ID: Reviewed. Thanks for the fix. The test case will also be a useful quick test for unboxed catchEx paths. ? John On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/ > > MethodHandleImpl.makeGuardWithCatch has special invokers > (GuardWithCatch.invoke_L*) for methods with arity up to 8. > When method arity is larger, generic invoker (GuardWithCatch.invoke_V) > is used. > > Generic invoker expects GuardWithCatch.target & GuardWithCatch.catcher > method handles to have (Object... av)Object type, but they can reference > arbitrary methods, so type conversion is needed. > > makeSpreadArguments takes care of parameters' type conversion, but > return type is left as is. That's the reason why GuardWithCatch.invoke_V > fails to invoke both target or catcher. > > The fix is to add return type conversion on both paths. > > Testing: failing test, test/java/lang/invoke/ > > Thanks! > > Best regards, > Vladimir Ivanov > > JBS: https://bugs.openjdk.java.net/browse/JDK-8027823 > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From roger.riggs at oracle.com Fri Nov 8 23:52:52 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 08 Nov 2013 23:52:52 +0000 Subject: hg: jdk8/tl/jdk: 8028041: Serialized Form description of j.l.String is not consistent with the implementation Message-ID: <20131108235304.9453E6248E@hg.openjdk.java.net> Changeset: df2f7f288353 Author: rriggs Date: 2013-11-08 17:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df2f7f288353 8028041: Serialized Form description of j.l.String is not consistent with the implementation Summary: Replaced incorrect description with reference to the serialization specification Reviewed-by: alanb, smarks ! src/share/classes/java/lang/String.java From vladimir.x.ivanov at oracle.com Sat Nov 9 00:08:47 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 09 Nov 2013 04:08:47 +0400 Subject: RFR (XS): 8027823: catchException combinator fails with 9 argument target In-Reply-To: References: <527D0268.3040407@oracle.com> Message-ID: <527D7D0F.60604@oracle.com> Thank you, John. Since I'm not a Committer in JDK8, I need a sponsor to push this fix. Any volunteers? :-) Will provide the changeset at first demand. Best regards, Vladimir Ivanov On 11/9/13 3:26 AM, John Rose wrote: > Reviewed. Thanks for the fix. The test case will also be a useful quick test for unboxed catchEx paths. ? John > > On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/ >> >> MethodHandleImpl.makeGuardWithCatch has special invokers >> (GuardWithCatch.invoke_L*) for methods with arity up to 8. >> When method arity is larger, generic invoker (GuardWithCatch.invoke_V) >> is used. >> >> Generic invoker expects GuardWithCatch.target & GuardWithCatch.catcher >> method handles to have (Object... av)Object type, but they can reference >> arbitrary methods, so type conversion is needed. >> >> makeSpreadArguments takes care of parameters' type conversion, but >> return type is left as is. That's the reason why GuardWithCatch.invoke_V >> fails to invoke both target or catcher. >> >> The fix is to add return type conversion on both paths. >> >> Testing: failing test, test/java/lang/invoke/ >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8027823 >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Sat Nov 9 00:15:02 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 8 Nov 2013 16:15:02 -0800 Subject: RFR (XS): 8027823: catchException combinator fails with 9 argument target In-Reply-To: <527D7D0F.60604@oracle.com> References: <527D0268.3040407@oracle.com> <527D7D0F.60604@oracle.com> Message-ID: <6AA4C698-EC74-4CE7-84DD-98B5A02B23A9@oracle.com> I'll push it for you. ? John On Nov 8, 2013, at 4:08 PM, Vladimir Ivanov wrote: > Thank you, John. > > Since I'm not a Committer in JDK8, I need a sponsor to push this fix. Any volunteers? :-) Will provide the changeset at first demand. > > Best regards, > Vladimir Ivanov > > On 11/9/13 3:26 AM, John Rose wrote: >> Reviewed. Thanks for the fix. The test case will also be a useful quick test for unboxed catchEx paths. ? John >> >> On Nov 8, 2013, at 7:25 AM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8027823/webrev.00/ >>> >>> MethodHandleImpl.makeGuardWithCatch has special invokers >>> (GuardWithCatch.invoke_L*) for methods with arity up to 8. >>> When method arity is larger, generic invoker (GuardWithCatch.invoke_V) >>> is used. >>> >>> Generic invoker expects GuardWithCatch.target & GuardWithCatch.catcher >>> method handles to have (Object... av)Object type, but they can reference >>> arbitrary methods, so type conversion is needed. >>> >>> makeSpreadArguments takes care of parameters' type conversion, but >>> return type is left as is. That's the reason why GuardWithCatch.invoke_V >>> fails to invoke both target or catcher. >>> >>> The fix is to add return type conversion on both paths. >>> >>> Testing: failing test, test/java/lang/invoke/ >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8027823 >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> From lana.steuck at oracle.com Sat Nov 9 04:49:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:32 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20131109044935.16142624A0@hg.openjdk.java.net> Changeset: d425685e0b74 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d425685e0b74 Added tag jdk8-b114 for changeset 0bbccf77c23e ! .hgtags Changeset: 8d07115924b7 Author: lana Date: 2013-10-31 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8d07115924b7 Merge Changeset: 5fdc44652089 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5fdc44652089 Added tag jdk8-b115 for changeset 8d07115924b7 ! .hgtags Changeset: 4796555c4dc8 Author: lana Date: 2013-11-08 17:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4796555c4dc8 Merge From lana.steuck at oracle.com Sat Nov 9 04:49:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:45 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20131109044958.ECB0A624A4@hg.openjdk.java.net> Changeset: fea486d30d41 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fea486d30d41 Added tag jdk8-b114 for changeset 850d2602ae98 ! .hgtags Changeset: 6b4d6205366c Author: lana Date: 2013-10-31 16:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b4d6205366c Merge - test/tools/javac/ExtDirs/ext1/pkg1.jar - test/tools/javac/ExtDirs/ext2/pkg2.jar - test/tools/javac/ExtDirs/ext3/pkg1.jar - test/tools/javac/ExtDirs/ext3/pkg2.jar - test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 3c040b04af05 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3c040b04af05 Added tag jdk8-b115 for changeset 6b4d6205366c ! .hgtags Changeset: 21294feaf311 Author: lana Date: 2013-11-08 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/21294feaf311 Merge From lana.steuck at oracle.com Sat Nov 9 04:49:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:37 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20131109044945.B4268624A3@hg.openjdk.java.net> Changeset: d3b6da1b3e25 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d3b6da1b3e25 Added tag jdk8-b114 for changeset 1b1e12117fe2 ! .hgtags Changeset: f610fd46463e Author: lana Date: 2013-10-31 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f610fd46463e Merge Changeset: e757eb9aee3d Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e757eb9aee3d Added tag jdk8-b115 for changeset f610fd46463e ! .hgtags From lana.steuck at oracle.com Sat Nov 9 04:49:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:32 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20131109044932.DBA866249F@hg.openjdk.java.net> Changeset: b65d48f6938a Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b65d48f6938a Added tag jdk8-b114 for changeset 4f2011496393 ! .hgtags Changeset: 763ada2a1d8c Author: lana Date: 2013-10-31 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/763ada2a1d8c Merge Changeset: 40e892e2a4f2 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/40e892e2a4f2 Added tag jdk8-b115 for changeset 763ada2a1d8c ! .hgtags From lana.steuck at oracle.com Sat Nov 9 04:49:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:37 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20131109044943.86205624A2@hg.openjdk.java.net> Changeset: e126d8eca69b Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e126d8eca69b Added tag jdk8-b114 for changeset 9ad289610fc6 ! .hgtags Changeset: 587560c222a2 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/587560c222a2 Added tag jdk8-b115 for changeset e126d8eca69b ! .hgtags From lana.steuck at oracle.com Sat Nov 9 04:49:37 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:37 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131109044942.71D6A624A1@hg.openjdk.java.net> Changeset: f109bb255b80 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f109bb255b80 Added tag jdk8-b114 for changeset 79f7b79bf97b ! .hgtags Changeset: f0d3ac2474ee Author: lana Date: 2013-10-31 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f0d3ac2474ee Merge - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java Changeset: 0fb1a427fbf6 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0fb1a427fbf6 Added tag jdk8-b115 for changeset f0d3ac2474ee ! .hgtags Changeset: d091499d67fc Author: lana Date: 2013-11-08 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d091499d67fc Merge From lana.steuck at oracle.com Sat Nov 9 04:49:52 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:49:52 +0000 Subject: hg: jdk8/tl/hotspot: 37 new changesets Message-ID: <20131109045108.186F9624A5@hg.openjdk.java.net> Changeset: ddc3758f68db Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ddc3758f68db Added tag jdk8-b114 for changeset 7fd913010dbb ! .hgtags Changeset: 205834867346 Author: lana Date: 2013-10-31 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/205834867346 Merge Changeset: f94a9f0746d8 Author: amurillo Date: 2013-10-25 13:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f94a9f0746d8 8027173: new hotspot build - hs25-b57 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e64f1fe9756b Author: farvidsson Date: 2013-10-24 10:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e64f1fe9756b 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes. Reviewed-by: coleenp, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp Changeset: d70a665e25d7 Author: iklam Date: 2013-10-24 22:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d70a665e25d7 8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9 Reviewed-by: dcubed, iveresov Contributed-by: gerard.ziemski at oracle.com ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: e4f478e7781b Author: jbachorik Date: 2013-10-25 09:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4f478e7781b 8027294: Prepare hotspot for non TOD based uptime counter Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime. Reviewed-by: dholmes, sla ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: a6177f601c64 Author: hseigel Date: 2013-10-25 11:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6177f601c64 8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space. Reviewed-by: stefank, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 634715d59d9e Author: hseigel Date: 2013-10-25 11:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/634715d59d9e Merge Changeset: 209aa13ab8c0 Author: coleenp Date: 2013-10-25 15:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/209aa13ab8c0 8024927: Nashorn performance regression with CompressedOops Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops Reviewed-by: stefank, hseigel, goetz ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CompressedOops/CompressedClassPointers.java Changeset: b4aa8fc5d0d5 Author: ccheung Date: 2013-10-25 22:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4aa8fc5d0d5 Merge ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/memory/metaspace.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1a04de1aaedb Author: dsamersoff Date: 2013-10-28 21:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a04de1aaedb 8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot Summary: Fixed two compilation-breaking nits Reviewed-by: sla, dholmes ! agent/src/os/bsd/ps_proc.c Changeset: 85730a185147 Author: ccheung Date: 2013-10-30 14:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85730a185147 Merge Changeset: 292050e5d5ea Author: dholmes Date: 2013-10-24 00:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/292050e5d5ea 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build Reviewed-by: coleenp, twisti ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/thread.cpp Changeset: 066778844ed9 Author: jprovino Date: 2013-10-27 14:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/066778844ed9 Merge Changeset: f2f9139ccde9 Author: jprovino Date: 2013-10-30 16:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2f9139ccde9 Merge Changeset: a007575ea726 Author: vladidan Date: 2013-10-30 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a007575ea726 Merge Changeset: 3b3133d93fb6 Author: brutisso Date: 2013-10-28 13:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b3133d93fb6 8027132: Print deprecation warning message for the flags controlling the CMS foreground collector Reviewed-by: stefank, ehelin, ysr, tschatzl ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestCMSForegroundFlags.java Changeset: 6d965678f21e Author: ehelin Date: 2013-10-31 21:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d965678f21e Merge Changeset: bd3237e0e18d Author: twisti Date: 2013-10-24 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd3237e0e18d 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: jrose, roland ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/handles.cpp Changeset: cbe8ba0fb8fc Author: twisti Date: 2013-10-24 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cbe8ba0fb8fc Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: f01788f13696 Author: adlertz Date: 2013-10-25 10:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f01788f13696 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal Reviewed-by: roland ! src/share/vm/opto/postaloc.cpp Changeset: 7ae254fd0b3c Author: adlertz Date: 2013-10-25 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ae254fd0b3c Merge Changeset: 6c2f07d1495f Author: roland Date: 2013-10-28 09:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c2f07d1495f 8027140: Assertion in compiler when running bigapps/Kitchensink/stability Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced Reviewed-by: twisti, iveresov ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: bfdb530cdffa Author: roland Date: 2013-10-28 12:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bfdb530cdffa Merge Changeset: a196f1aaec86 Author: anoll Date: 2013-10-25 22:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a196f1aaec86 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Summary: Exit compiler threads early during startup so that wrong error message is not printed Reviewed-by: iveresov, twisti ! src/share/vm/compiler/compileBroker.cpp + test/compiler/startup/StartupOutput.java Changeset: 8c16f426dbb2 Author: iveresov Date: 2013-10-28 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c16f426dbb2 Merge Changeset: fc1632f5021a Author: iveresov Date: 2013-10-28 17:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fc1632f5021a Merge Changeset: a57a165b8296 Author: rbackman Date: 2013-10-28 08:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a57a165b8296 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Reviewed-by: kvn, roland ! src/share/vm/opto/library_call.cpp ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Changeset: 60a32bb8ff99 Author: rbackman Date: 2013-10-30 13:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/60a32bb8ff99 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Reviewed-by: duke ! src/share/vm/opto/loopTransform.cpp + test/compiler/intrinsics/mathexact/NestedMathExactTest.java Changeset: 4d3575d37a07 Author: iveresov Date: 2013-10-30 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d3575d37a07 8026735: Stream tests throw java.lang.IncompatibleClassChangeError Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1 Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp + test/compiler/inlining/InlineDefaultMethod.java Changeset: 946a8294ab15 Author: iveresov Date: 2013-10-31 04:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/946a8294ab15 8024919: G1: SPECjbb2013 crashes due to a broken object reference Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 2dcd0bd2920d Author: iveresov Date: 2013-10-31 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2dcd0bd2920d Merge Changeset: 0836a3c28c6a Author: iveresov Date: 2013-10-31 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0836a3c28c6a Merge Changeset: 3b32d287da89 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b32d287da89 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: afd012c940e4 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/afd012c940e4 Added tag hs25-b57 for changeset 3b32d287da89 ! .hgtags Changeset: 9ebaac78a8a0 Author: amurillo Date: 2013-11-05 14:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ebaac78a8a0 Merge Changeset: 842b6ce4dfb4 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/842b6ce4dfb4 Added tag jdk8-b115 for changeset 9ebaac78a8a0 ! .hgtags From lana.steuck at oracle.com Sat Nov 9 04:57:08 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 09 Nov 2013 04:57:08 +0000 Subject: hg: jdk8/tl/jdk: 70 new changesets Message-ID: <20131109051116.55949624A6@hg.openjdk.java.net> Changeset: 62982664dc72 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62982664dc72 Added tag jdk8-b114 for changeset f26a0c8071bd ! .hgtags Changeset: 180c05796c45 Author: bae Date: 2013-10-10 18:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/180c05796c45 7058618: PNG parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java Changeset: 0c2ba6a67b0d Author: morris Date: 2013-10-11 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c2ba6a67b0d 7195597: ThreadStateTest gets different results with -Xcomp Reviewed-by: kvn ! test/java/lang/Thread/ThreadStateTest.java Changeset: 124bffc749ea Author: lana Date: 2013-10-12 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/124bffc749ea Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java - test/java/util/regex/PatternTest.java Changeset: 7ed340e7d894 Author: bae Date: 2013-10-14 15:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ed340e7d894 7058602: BMP parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties ! src/share/classes/java/awt/image/ComponentSampleModel.java Changeset: cb9fa40f73f7 Author: bae Date: 2013-10-14 15:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb9fa40f73f7 7058607: GIF parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 478f7a9b3b12 Author: bae Date: 2013-10-14 16:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/478f7a9b3b12 7058611: JPG parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java Changeset: b164c8eb1295 Author: jgodinez Date: 2013-10-14 09:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b164c8eb1295 8022536: closed/javax/print/TextFlavorTest.java fails Reviewed-by: prr, jchen ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! test/java/awt/print/PrinterJob/PrintLatinCJKTest.java + test/javax/print/TextFlavorTest.java Changeset: 8a59181b3c6d Author: vadim Date: 2013-10-15 08:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a59181b3c6d 8023590: REGRESSION: large count of graphics artifacts with Java 8 on Windows 8 on Intel HD card. Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 0df5cda89a50 Author: jchen Date: 2013-10-15 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0df5cda89a50 8025429: [parfait] warnings from b107 for sun.java2d.cmm: JNI exception pending Reviewed-by: prr, bae ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: c9c945cea665 Author: jgodinez Date: 2013-10-15 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9c945cea665 8015586: [macosx] Test closed/java/awt/print/PrinterJob/PrintToDir.java fails on MacOSX Reviewed-by: prr, jchen ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java + test/java/awt/print/PrinterJob/PrintToDir.java Changeset: 070e8ec9d82c Author: bae Date: 2013-10-16 17:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/070e8ec9d82c 8026702: Fix for 8025429 breaks jdk build on windows Reviewed-by: serb ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 73d212a3b2eb Author: jchen Date: 2013-10-16 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73d212a3b2eb 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test Reviewed-by: prr, vadim, serb ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c Changeset: bcf8e9a59968 Author: jgodinez Date: 2013-10-18 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcf8e9a59968 8025988: [macosx] Attribute settings don't work for JobAttributes range 8025990: [macosx] Attribute settings don't work for JobAttributes setOrientationRequested, setMedia Reviewed-by: prr, jchen ! src/macosx/native/sun/awt/CPrinterJob.m ! src/share/classes/sun/print/RasterPrinterJob.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! test/java/awt/PrintJob/SaveDialogTitleTest.java Changeset: 2a3e21fe9d0d Author: jgodinez Date: 2013-10-21 13:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a3e21fe9d0d 8026951: Fix for 8025988 breaks jdk build on windows Reviewed-by: prr, jchen ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 923f39485651 Author: bae Date: 2013-10-22 13:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/923f39485651 8026780: Crash on PPC and PPC v2 for Java_awt test suit Reviewed-by: prr, jchen ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 739ed3f0e796 Author: ceisserer Date: 2013-10-22 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/739ed3f0e796 8023483: sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java failed with jdk8 on linux platforms Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/XRBackend.java ! src/solaris/classes/sun/java2d/xr/XRBackendNative.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/classes/sun/java2d/xr/XRPaints.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c + test/java/awt/GradientPaint/GradientTransformTest.java + test/java/awt/GradientPaint/LinearColorSpaceGradientTest.java ! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java Changeset: c55a8480cc27 Author: ceisserer Date: 2013-10-22 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c55a8480cc27 8023098: XRender : AlphaComposite test results are incorrect. Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java ! src/solaris/classes/sun/java2d/xr/XRColor.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java ! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java + src/solaris/classes/sun/java2d/xr/XRSolidSrcPict.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java Changeset: aca4a67e560d Author: vadim Date: 2013-10-23 08:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aca4a67e560d 8001173: [findbugs] Evaluate FindBug output for sun.font.CompositeFont, sun.font.CompositeFontDescriptor Reviewed-by: prr, bae ! src/share/classes/sun/font/StandardTextSource.java ! src/share/classes/sun/font/TextLabelFactory.java ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 92af0666c168 Author: prr Date: 2013-10-23 08:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92af0666c168 8027169: Xrender: Cleaner version of the fix for 7159455 Nimbus scrollbar glitch Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java Changeset: d27525c346fa Author: lana Date: 2013-10-24 21:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d27525c346fa Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/net/HttpURLPermission.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 3371047f56f3 Author: lana Date: 2013-10-31 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3371047f56f3 Merge Changeset: 2e59014ef38f Author: alexsch Date: 2013-10-09 13:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e59014ef38f 8025649: need test to cover JDK-8000423 Reviewed-by: anthony, serb Contributed-by: Alexander Stepanov + test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html + test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java Changeset: 84c766f6796b Author: bagiras Date: 2013-10-09 14:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84c766f6796b 8016356: Any swing frame resizes ugly. Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 929dc0915f8c Author: anthony Date: 2013-10-09 15:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/929dc0915f8c 7159266: [macosx] ApplicationDelegate should not be set in the headless mode Summary: Don't install ApplicationDelegate in headless mode Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m Changeset: 976e5f580124 Author: leonidr Date: 2013-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/976e5f580124 8019623: Lack of synchronization in AppContext.getAppContext() Reviewed-by: anthony, art ! src/share/classes/sun/awt/AppContext.java + test/sun/awt/AppContext/MultiThread/MultiThreadTest.java Changeset: fba62451d705 Author: leonidr Date: 2013-10-09 21:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fba62451d705 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons Reviewed-by: alexsch, serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java + test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java Changeset: cea6ca16142e Author: cl Date: 2013-10-09 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cea6ca16142e 8026021: more fix of javadoc errors and warnings reported by doclint, see the description Reviewed-by: anthony, serb ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/font/LineBreakMeasurer.java ! src/share/classes/java/awt/font/MultipleMaster.java ! src/share/classes/java/awt/font/NumericShaper.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java Changeset: 81ea6299230a Author: serb Date: 2013-10-10 02:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81ea6299230a 7058662: AiffFileReader throws java.lang.ArithmeticException: division by zero when frame size is zero 7058666: Unexpected exception in AU parser code 7058672: Unexpected exceptions and freezes in WAV parser code Reviewed-by: prr ! src/share/classes/com/sun/media/sound/AiffFileReader.java ! src/share/classes/com/sun/media/sound/AuFileReader.java ! src/share/classes/com/sun/media/sound/WaveFileReader.java + test/javax/sound/sampled/FileReader/ReadersExceptions.java Changeset: 857d6f78f241 Author: pchelko Date: 2013-10-10 11:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/857d6f78f241 8025588: [macosx] Frozen AppKit thread in 7u40 Reviewed-by: anthony, art, serb ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/event/InvocationEvent.java ! src/share/classes/sun/awt/AWTAccessor.java Changeset: 31a156bae7cb Author: pchelko Date: 2013-10-10 19:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31a156bae7cb 8024864: [macosx] Problems with rendering of controls Reviewed-by: serb, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/Paint/bug8024864.java Changeset: de36486eadd2 Author: pchelko Date: 2013-10-11 11:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de36486eadd2 8026143: [macosx] Maximized state could be inconsistent between peer and frame Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java Changeset: d96f9a8cf89a Author: kshefov Date: 2013-10-11 15:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d96f9a8cf89a 7124338: [macosx] Selection lost if a selected item removed from a java.awt.List Reviewed-by: serb, anthony + test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html + test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java Changeset: 2e04843f1c1d Author: art Date: 2013-10-11 16:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e04843f1c1d 8022185: Fix Raw and unchecked warnings in classes belonging to java.awt.datatransfer Reviewed-by: art, pchelko Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java Changeset: 2f7f6995fa64 Author: pchelko Date: 2013-10-11 17:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f7f6995fa64 8026262: NPE in SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of #JDK-8024987 Reviewed-by: art, serb ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: af273c9b564a Author: pchelko Date: 2013-10-11 18:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af273c9b564a 8024329: [macosx] JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java Changeset: f65895a2959e Author: lana Date: 2013-10-11 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f65895a2959e Merge - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java - test/java/util/regex/PatternTest.java Changeset: d874963706dc Author: yan Date: 2013-10-14 11:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d874963706dc 8025824: [cleanup] Fix tidy errors and warnings in preformatted HTML files related to 2d/awt/swing Reviewed-by: anthony, alexsch ! src/macosx/classes/com/apple/eawt/event/package.html ! src/macosx/classes/com/apple/eawt/package.html ! src/share/classes/java/awt/color/package.html ! src/share/classes/java/awt/datatransfer/package.html ! src/share/classes/java/awt/dnd/package.html ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/doc-files/FocusSpec.html ! src/share/classes/java/awt/doc-files/Modality.html ! src/share/classes/java/awt/event/package.html ! src/share/classes/java/awt/font/package.html ! src/share/classes/java/awt/geom/package.html ! src/share/classes/java/awt/image/package.html ! src/share/classes/java/awt/image/renderable/package.html ! src/share/classes/java/awt/package.html ! src/share/classes/java/awt/print/package.html ! src/share/classes/javax/print/attribute/package.html ! src/share/classes/javax/print/attribute/standard/package.html ! src/share/classes/javax/print/event/package.html ! src/share/classes/javax/print/package.html ! src/share/classes/javax/swing/border/package.html ! src/share/classes/javax/swing/colorchooser/package.html ! src/share/classes/javax/swing/event/package.html ! src/share/classes/javax/swing/filechooser/package.html ! src/share/classes/javax/swing/plaf/basic/package.html ! src/share/classes/javax/swing/plaf/metal/package.html ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/multi/package.html ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html ! src/share/classes/javax/swing/plaf/nimbus/package.html ! src/share/classes/javax/swing/plaf/package.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/classes/javax/swing/table/package.html ! src/share/classes/javax/swing/text/html/package.html ! src/share/classes/javax/swing/text/html/parser/package.html ! src/share/classes/javax/swing/text/package.html ! src/share/classes/javax/swing/text/rtf/package.html ! src/share/classes/javax/swing/tree/package.html ! src/share/classes/javax/swing/undo/package.html Changeset: 69a17384fe22 Author: malenkov Date: 2013-10-14 13:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69a17384fe22 7165112: Incomprehensible garbage in doc for RootPaneContainer Reviewed-by: alexsch ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/RootPaneContainer.java Changeset: 9f49b055e983 Author: malenkov Date: 2013-10-14 13:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f49b055e983 7016396: (spec) JCK test mentioned in 6735293 is still failing Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/View.java Changeset: 54a6e22b749c Author: malenkov Date: 2013-10-14 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54a6e22b749c 7035495: javax.swing.ImageIcon spec should be clarified Reviewed-by: alexsch ! src/share/classes/javax/swing/ImageIcon.java Changeset: 5e0ed469c36a Author: alexsch Date: 2013-10-14 18:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e0ed469c36a 8005391: Floating behavior of HTMLEditorKit parser Reviewed-by: malenkov, leonidr Contributed-by: Alexander Shusherov ! src/share/classes/javax/swing/text/SimpleAttributeSet.java + test/javax/swing/text/html/8005391/bug8005391.java Changeset: 24fd0716d8d6 Author: alexsch Date: 2013-10-14 18:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24fd0716d8d6 8020708: NLS mnemonics missing in SwingSet2/JInternalFrame demo Reviewed-by: malenkov, leonidr ! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java + test/javax/swing/JInternalFrame/8020708/bug8020708.java Changeset: 9546631f14ca Author: serb Date: 2013-10-14 20:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9546631f14ca 8019591: JCK: testICSEthrowing_fullScreen fails: no ICSE thrown Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/Window/WindowGCInFullScreen/WindowGCInFullScreen.java Changeset: f9548641d699 Author: serb Date: 2013-10-15 20:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9548641d699 7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue Reviewed-by: anthony, art Contributed-by: alexander.zvegintsev at oracle.com + src/solaris/classes/sun/misc/GThreadHelper.java ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c Changeset: 89546b9be510 Author: serb Date: 2013-10-15 20:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89546b9be510 8025225: Window.setAlwaysOnTop documentation should be updated Reviewed-by: anthony, art Contributed-by: alexander.zvegintsev at oracle.com ! src/share/classes/java/awt/Window.java Changeset: 229b10e97bd2 Author: bagiras Date: 2013-10-16 19:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/229b10e97bd2 2228674: Fix failed for CR 7162144 Reviewed-by: art, anthony ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 70242d821c66 Author: serb Date: 2013-10-17 20:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70242d821c66 8022657: Add FunctionalInterface annotation to awt interfaces Reviewed-by: anthony, art ! src/share/classes/java/awt/KeyEventDispatcher.java ! src/share/classes/java/awt/KeyEventPostProcessor.java Changeset: 3c2d4569a6a3 Author: serb Date: 2013-10-17 21:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c2d4569a6a3 8026356: [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main Reviewed-by: anthony, art ! src/share/classes/java/awt/Component.java Changeset: 5334c651c7ba Author: yan Date: 2013-10-18 15:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5334c651c7ba 7002846: Fix for 6989505 may be incomplete Reviewed-by: anthony, art Contributed-by: Andrei Eremeev ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h Changeset: 84ae644933b6 Author: serb Date: 2013-10-18 20:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84ae644933b6 8026476: Choice does not get mouse events if it does not have enough place for popup menu Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XChoicePeer.java Changeset: d72ca6dac444 Author: leonidr Date: 2013-10-22 16:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72ca6dac444 8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.m + test/java/awt/event/KeyEvent/8020209/bug8020209.java ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 4ad826a08e6f Author: serb Date: 2013-10-23 16:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad826a08e6f 8020851: java.awt.event.WindowEvent spec should state that WINDOW_CLOSED event may not be delivered under certain circumstances Reviewed-by: anthony, art ! src/share/classes/java/awt/event/WindowEvent.java Changeset: cd2e3c63ee42 Author: serb Date: 2013-10-24 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd2e3c63ee42 7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XButtonPeer.java ! src/solaris/classes/sun/awt/X11/XCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XLabelPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Paint/ButtonRepaint.java + test/java/awt/Paint/CheckboxRepaint.java + test/java/awt/Paint/ExposeOnEDT.java + test/java/awt/Paint/LabelRepaint.java + test/java/awt/Paint/ListRepaint.java Changeset: 7c84aff91033 Author: pchelko Date: 2013-10-24 19:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c84aff91033 8027030: AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: c561db53a24c Author: pchelko Date: 2013-10-24 19:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c561db53a24c 8027025: [macosx] getLocationOnScreen returns 0 if parent invisible Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Window/8027025/Test8027025.java Changeset: 6fe5443c3dde Author: alitvinov Date: 2013-10-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6fe5443c3dde 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays Reviewed-by: alexsch, malenkov Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + test/java/beans/XMLEncoder/Test8027066.java Changeset: 75ae2a980db5 Author: malenkov Date: 2013-10-25 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75ae2a980db5 8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed Reviewed-by: art, jfranck ! test/java/beans/Introspector/TestTypeResolver.java Changeset: dab1d3798016 Author: serb Date: 2013-10-25 19:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dab1d3798016 7172770: Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" Reviewed-by: anthony, art ! src/share/classes/java/awt/Toolkit.java Changeset: 162c57b874d4 Author: lana Date: 2013-10-25 10:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/162c57b874d4 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html ! src/share/classes/java/awt/datatransfer/DataFlavor.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/sun/awt/AppContext.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 55cab2211ae9 Author: ant Date: 2013-10-29 16:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55cab2211ae9 8027157: [SwingNode] needs explicit expose for JWindow Reviewed-by: art, anthony ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: bedc29a6d074 Author: malenkov Date: 2013-10-29 17:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bedc29a6d074 8022746: List of spelling errors in API doc Reviewed-by: alexsch, smarks ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTreeUI.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/font/CFontManager.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/CTextPipe.m ! src/share/back/commonRef.c ! src/share/back/eventFilter.c ! src/share/back/util.c ! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java ! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java ! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java ! src/share/classes/com/sun/beans/decoder/CharElementHandler.java ! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java ! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java ! src/share/classes/com/sun/beans/decoder/ElementHandler.java ! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java ! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java ! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java ! src/share/classes/com/sun/beans/decoder/IntElementHandler.java ! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java ! src/share/classes/com/sun/beans/decoder/LongElementHandler.java ! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java ! src/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/share/classes/com/sun/beans/decoder/NullElementHandler.java ! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java ! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java ! src/share/classes/com/sun/beans/decoder/StringElementHandler.java ! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java ! src/share/classes/com/sun/beans/decoder/VarElementHandler.java ! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/Filter.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/package.html ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java ! src/share/classes/com/sun/tools/jdi/ThreadListener.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/AlphaComposite.java ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Graphics.java ! src/share/classes/java/awt/Graphics2D.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MediaTracker.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MultipleGradientPaintContext.java ! src/share/classes/java/awt/Polygon.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/Shape.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/FlavorMap.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java ! src/share/classes/java/awt/dnd/DragGestureListener.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/font/FontRenderContext.java ! src/share/classes/java/awt/font/GlyphMetrics.java ! src/share/classes/java/awt/font/GlyphVector.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TransformAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/im/InputMethodRequests.java ! src/share/classes/java/awt/image/BandedSampleModel.java ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ComponentColorModel.java ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/ImageConsumer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/renderable/RenderableImage.java ! src/share/classes/java/awt/image/renderable/RenderableImageOp.java ! src/share/classes/java/beans/AppletInitializer.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectStreamConstants.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/net/Authenticator.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/java/net/InterfaceAddress.java ! src/share/classes/java/net/JarURLConnection.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/security/AccessControlException.java ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/spec/ECFieldF2m.java ! src/share/classes/java/sql/Array.java ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DataTruncation.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/DriverPropertyInfo.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java ! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java ! src/share/classes/java/sql/SQLNonTransientConnectionException.java ! src/share/classes/java/sql/SQLNonTransientException.java ! src/share/classes/java/sql/SQLRecoverableException.java ! src/share/classes/java/sql/SQLSyntaxErrorException.java ! src/share/classes/java/sql/SQLTimeoutException.java ! src/share/classes/java/sql/SQLTransactionRollbackException.java ! src/share/classes/java/sql/SQLTransientConnectionException.java ! src/share/classes/java/sql/SQLTransientException.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Struct.java ! src/share/classes/java/sql/package.html ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/FieldPosition.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RuleBasedCollator.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/MissingFormatWidthException.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/accessibility/AccessibleText.java ! src/share/classes/javax/crypto/NullCipher.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/IIOParam.java ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/event/IIOReadProgressListener.java ! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java ! src/share/classes/javax/imageio/event/IIOReadWarningListener.java ! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java ! src/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/remote/rmi/package.html ! src/share/classes/javax/naming/Binding.java ! src/share/classes/javax/naming/InsufficientResourcesException.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/print/CancelablePrintJob.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/attribute/standard/MediaTray.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/share/classes/javax/print/package.html ! src/share/classes/javax/script/AbstractScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptEngine.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/security/sasl/RealmChoiceCallback.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslException.java ! src/share/classes/javax/smartcardio/CardChannel.java ! src/share/classes/javax/smartcardio/CardTerminal.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiMessage.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/Soundbank.java ! src/share/classes/javax/sound/midi/Synthesizer.java ! src/share/classes/javax/sound/sampled/AudioFormat.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sound/sampled/ReverbType.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java ! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java ! src/share/classes/javax/sql/rowset/spi/XmlReader.java ! src/share/classes/javax/sql/rowset/spi/XmlWriter.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultRowSorter.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/ScrollPaneConstants.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/plaf/ComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/table/TableColumnModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GapVector.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/CSSParser.java ! src/share/classes/javax/swing/text/html/FormSubmitEvent.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/FrameSetView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/xml/crypto/KeySelector.java ! src/share/classes/javax/xml/crypto/MarshalException.java ! src/share/classes/javax/xml/crypto/dsig/TransformException.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java ! src/share/classes/jdi-overview.html ! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java ! src/share/classes/jdk/internal/util/xml/XMLStreamException.java ! src/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/share/classes/org/ietf/jgss/GSSContext.java ! src/share/classes/org/ietf/jgss/GSSCredential.java ! src/share/classes/org/ietf/jgss/GSSException.java ! src/share/classes/org/ietf/jgss/GSSManager.java ! src/share/classes/org/ietf/jgss/GSSName.java ! src/share/classes/org/ietf/jgss/package.html ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontRunIterator.java ! src/share/classes/sun/font/LayoutPathImpl.java ! src/share/classes/sun/font/ScriptRun.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/ProcessPath.java ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java ! src/share/classes/sun/management/counter/perf/InstrumentationException.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/misc/CRC16.java ! src/share/classes/sun/misc/CharacterDecoder.java ! src/share/classes/sun/misc/PerformanceLogger.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/TelnetOutputStream.java ! src/share/classes/sun/net/ftp/FtpClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/idn/StringPrep.java ! src/share/classes/sun/net/smtp/SmtpProtocolException.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/http/PosterOutputStream.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/print/PrintJob2D.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/rmi/rmic/RemoteClass.java ! src/share/classes/sun/rmi/rmic/Util.java ! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/x509/AlgIdDSA.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java ! src/share/classes/sun/text/resources/th/CollationData_th.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstat/ColumnFormat.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/tree/ExprExpression.java ! src/share/classes/sun/tools/tree/FieldExpression.java ! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/zip.cpp ! src/share/native/com/sun/media/sound/PlatformMidi.h ! src/share/native/common/jni_util.h ! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/awt/image/cvutils/img_dcm.h ! src/share/native/sun/awt/image/cvutils/img_replscale.h ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h ! src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/TibetanReordering.cpp ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/sample/jmx/jmx-scandir/index.html ! src/share/sample/nio/chatserver/ClientReader.java ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/font/XMap.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/multiVis.c ! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h ! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java ! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c ! src/windows/native/java/net/icmp.h ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp Changeset: d4eb25382baf Author: malenkov Date: 2013-10-29 19:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4eb25382baf 8027442: JDK compilation fails on MacOS Reviewed-by: alexsch, pchelko ! src/share/classes/java/awt/Component.java Changeset: a2b42e558211 Author: bagiras Date: 2013-10-29 21:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2b42e558211 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine Reviewed-by: anthony, pchelko ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: db2838f25a85 Author: pchelko Date: 2013-10-30 12:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db2838f25a85 8027152: Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 Reviewed-by: art, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java Changeset: 05f04b1c5bd0 Author: leonidr Date: 2013-10-30 20:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05f04b1c5bd0 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/FullScreen/8013581/bug8013581.java Changeset: 6f436140049d Author: lana Date: 2013-10-31 16:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f436140049d Merge ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: f82b730c798b Author: lana Date: 2013-10-31 16:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f82b730c798b Merge - src/share/classes/java/lang/invoke/MagicLambdaImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/tools/jar/Main.java - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/zip.cpp ! src/solaris/classes/sun/nio/fs/UnixPath.java - test/java/net/NetworkInterface/MemLeakTest.java - test/jdk/lambda/vm/DefaultMethodsTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out Changeset: a389b4f5723f Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a389b4f5723f Added tag jdk8-b115 for changeset f82b730c798b ! .hgtags Changeset: a579e2f73bca Author: lana Date: 2013-11-08 17:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a579e2f73bca Merge ! src/share/classes/java/lang/invoke/MethodType.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! test/java/lang/Thread/ThreadStateTest.java From jan.lahoda at oracle.com Sat Nov 9 14:30:13 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Sat, 09 Nov 2013 14:30:13 +0000 Subject: hg: jdk8/tl/langtools: 8027142: Invokedynamic instructions don't get line number table entries Message-ID: <20131109143017.187C7624B8@hg.openjdk.java.net> Changeset: 6e0f31d61e56 Author: jlahoda Date: 2013-11-09 15:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e0f31d61e56 8027142: Invokedynamic instructions don't get line number table entries Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. Reviewed-by: jjg, jrose, ksrini, vromero ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! test/tools/javac/T8019486/WrongLNTForLambdaTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java From Alan.Bateman at oracle.com Sat Nov 9 16:46:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 09 Nov 2013 16:46:05 +0000 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527CB943.8040207@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> <527CADB5.2060702@oracle.com> <527CB943.8040207@oracle.com> Message-ID: <527E66CD.3000408@oracle.com> On 08/11/2013 10:13, Patrick Zhang wrote: > Hi Alan, > > I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to > hold it. > Thanks, I'll push this for you with this new bug number. One thing that would be good to do is to go through all the issues in JDK-8019502 as it doesn't appear that the original issue (related to tests using ProcessBuilder and Runtime.exec) has been addressed by other changes. -Alan. From alan.bateman at oracle.com Sat Nov 9 16:48:10 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 09 Nov 2013 16:48:10 +0000 Subject: hg: jdk8/tl/jdk: 8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS Message-ID: <20131109164823.E49F0624BB@hg.openjdk.java.net> Changeset: 9130770fb6e3 Author: alanb Date: 2013-11-09 16:46 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9130770fb6e3 8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS Reviewed-by: dholmes, alanb Contributed-by: patrick.zhang at oracle.com ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Calendar/NarrowNamesTest.sh From roger.riggs at oracle.com Sat Nov 9 19:14:40 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 09 Nov 2013 14:14:40 -0500 Subject: RFR 8028092 Lint cleanup of java.time.format Message-ID: <527E89A0.2010208@oracle.com> Please review this lint cleanup in java.time.format classes. http://cr.openjdk.java.net/~rriggs/webrev-lint-time-8028092/ Thanks, Roger From joe.darcy at oracle.com Sat Nov 9 19:19:55 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 09 Nov 2013 11:19:55 -0800 Subject: RFR 8028092 Lint cleanup of java.time.format In-Reply-To: <527E89A0.2010208@oracle.com> References: <527E89A0.2010208@oracle.com> Message-ID: <527E8ADB.1090409@oracle.com> Looks good Roger; thanks, -Joe On 11/9/2013 11:14 AM, roger riggs wrote: > Please review this lint cleanup in java.time.format classes. > > http://cr.openjdk.java.net/~rriggs/webrev-lint-time-8028092/ > > Thanks, Roger > From lance.andersen at oracle.com Sat Nov 9 19:20:21 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Sat, 9 Nov 2013 14:20:21 -0500 Subject: RFR 8028092 Lint cleanup of java.time.format In-Reply-To: <527E89A0.2010208@oracle.com> References: <527E89A0.2010208@oracle.com> Message-ID: <3061CFE1-2C8A-4A90-B93F-5C429E4E5DD7@oracle.com> Looks good roger 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 Sent from my iPad On Nov 9, 2013, at 2:14 PM, roger riggs wrote: > Please review this lint cleanup in java.time.format classes. > > http://cr.openjdk.java.net/~rriggs/webrev-lint-time-8028092/ > > Thanks, Roger > From roger.riggs at oracle.com Sat Nov 9 19:32:24 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Sat, 09 Nov 2013 19:32:24 +0000 Subject: hg: jdk8/tl/jdk: 8028092: Lint cleanup of java.time.format Message-ID: <20131109193236.7865F624BE@hg.openjdk.java.net> Changeset: 3add16c86970 Author: rriggs Date: 2013-11-09 14:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3add16c86970 8028092: Lint cleanup of java.time.format Summary: correct declarations and add @SuppressWarnings Reviewed-by: darcy, lancea ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/Parsed.java From tristan.yan at oracle.com Sun Nov 10 03:19:39 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Sun, 10 Nov 2013 11:19:39 +0800 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <527D2D58.1010703@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> Message-ID: <527EFB4B.1010502@oracle.com> Hi Stuart I tried your suggestion but unfortunately all the benchmarks have dependencies to Main class because they need get stub from server. I suggest we move the benchmark tests to unnamed package unless we do want to put TestLibrary into a named package right now. Please let me know if you have objection on this. Thank you Tristan On 11/09/2013 02:28 AM, Stuart Marks wrote: > Hi Tristan, > > Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed > package. Classes in a named package cannot import classes from the > unnamed package. We've run into problems with this before. Eventually, > we should move TestLibrary a named package. > > I think it's possible to work around this without too much difficulty. > Note that classes in the unnamed package can import classes from named > packages. So, perhaps you can put the RmiBench main class in the > unnamed package so it has access to TestLibrary. Then have the > benchmarks themselves in the bench.rmi package. The config file > already references the benchmarks by fully qualified class name (e.g., > "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able > to get this to work. > > s'marks > > On 11/8/13 3:00 AM, Tristan Yan wrote: >> Thank you, Stuart >> There is one review point I want to ask you opinion. Which is the >> reason that I moved from >> test/java/rmi/reliability/benchmark/bench/rmi to >> test/java/rmi/reliability/benchmark is Main.java need access class >> TestLibrary for supporting random port. TestLibrary is a unpackage >> class, I couldn't find a way to let a class which has Package to >> access the class without package. Do you have suggestion on that? >> Thank you so much. >> Tristan >> >> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>> >>> >>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>> Hi Everyone >>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>> >>>> Description: >>>> 1. Convert shell script test to Java program test. >>>> 2. Using random server port by reusing Darryl Mocek's work to >>>> replace fixed >>>> server port. >>>> 3. Using java Process class to start client process. >>>> 4. Also convert other shell script test runSerialBench.sh to java >>>> program test also >>> >>> Hi Tristan, >>> >>> Several comments on this webrev. >>> >>> >>> ** The original arrangement within the >>> test/java/rmi/reliability/benchmark directory had the main benchmark >>> files (scripts) at the top, some benchmark framework files in the >>> "bench" subdirectory, and the actual RMI and serialization >>> benchmarks in bench/rmi and bench/serial subdirectories. >>> >>> The webrev moves all the RMI benchmarks to the top benchmark >>> directory but leaves the serial benchmarks in bench/serial. The RMI >>> benchmarks are now all cluttering the top directory, but the main >>> serial benchmark test is now buried in the bench/serial directory. >>> The nice organization that was there before is now spoiled. Is this >>> rearrangement necessary in order to convert the scripts to Java? I >>> would prefer the original arrangement be left in place. >>> >>> >>> ** The RMI benchmark Main.java file has a @run tag of the form, >>> >>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>> -c config >>> >>> There is a subtle but serious problem here: the -server option is >>> passed to the >>JVM<< and not as an argument to the main() method. >>> The main() method gets neither a -server nor a -client argument, so >>> its default "run mode" as defined by the benchmark itself is SAMEVM. >>> This runs the client and server in the same JVM, which is different >>> from the shell script, which ran separate client and server JVMs. >>> >>> >>> ** The logic to process the -server argument still expects to take a >>> port, even though the port is assigned automatically. So the obvious >>> fix to the above, >>> >>> @run main/othervm/policy=policy.all/timeout=1800 Main -server -c >>> config >>> >>> doesn't work, since a port is missing. The logic to increment the >>> argument index to collect the port argument should be removed. Also, >>> the -server line should be restored to the usage message, but >>> without the port argument. >>> >>> >>> ** After this is done, the client's command line is constructed >>> improperly. The command line ends up looking something like this: >>> >>> java client -cp Main client localhost:58583 -c config >>> >>> The word "client" appears twice, but what's really required is >>> "-client" to appear as an argument after Main. >>> >>> >>> ** The client is run using ProcessBuilder, which by default sends >>> stdout and stderr to pipes to be read by the parent. But the parent >>> never reads them, thus any messages from the client are never seen. >>> The client is the one that emits the benchmark report, so its output >>> needs to be seen. It might be sufficient to have the client inherit >>> the parent's stdout and stderr. This might intermix the client's and >>> server's output, but it's better than nothing. >>> >>> >>> ** The config file is checked with the following code: >>> >>> try { >>> confFile = args[i]; >>> confstr = new FileInputStream(System.getProperty("test.src") >>> + System.getProperty("file.separator") + confFile); >>> } catch (IOException e) { >>> die("Error: unable to open \"" + args[i] + "\""); >>> } >>> >>> This is potentially misleading, as the message doesn't print the >>> actual filename that was attempted to be opened. >>> >>> This is important, as the test.src property doesn't exist in the >>> client JVM. >>> >>> Note that the original shell script passed full pathnames for the >>> config file to both the client and the server. The new @run tag >>> merely says "-c config" which redefines the config filename to be >>> relative to the test.src directory. You could pass -Dtest.src=... to >>> the client, but it seems like there should be something better than >>> can be done. >>> >>> >>> ** The client needs to have its security policy set up. This is >>> missing from the construction of the client's command line. >>> >>> >>> ** ProcessBuilder takes a List for its command; there is no >>> need to turn the list into an array. >>> >>> >>> ** In the benchmark main methods, code of the form, >>> >>> while (true) { >>> runBenchmarks(); >>> if (exitRequested) { >>> System.exit(); >>> } >>> } >>> >>> was replaced with >>> >>> while (!exitRequested) { >>> runBenchmarks(); >>> } >>> >>> This is a subtle logic change, in that the former code always >>> executed the loop at least once. It seems unlikely, but it's >>> possible that a timer could set exitRequested before loop entry, >>> resulting in the benchmark running zero times. I guess, if you >>> really want to clean this up (we do need to avoid System.exit in >>> jtreg tests), use a do-while loop instead. >>> >>> >>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>> ProblemList.txt. >>> >>> >>> ** Remove the references to RMISecurityManager and just use >>> SecurityManager. This is just general cleanup. (I deprecated >>> RMISecurityManager last week.) :-) >>> >>> >>> It would be good if you could fix up these issues and post another >>> webrev. >>> >>> Thanks. >>> >>> s'marks >>> >>> >>> >>> >>>> Thank you >>>> Tristan >>>> >>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>> I am working on bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>> on my research, it looks like the issue of fixed port was already >>>>>> addressed >>>>>> by Stuart Marks in other RMI tests which are Java based. I would >>>>>> like to >>>>>> reuse his solution, however it does not work for shell based tests. >>>>> >>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>> >>>>> Was the patch attached to your message? If so, it didn't get >>>>> through. Most >>>>> OpenJDK mailing lists strip off attachments before forwarding the >>>>> message to >>>>> the recipients. >>>>> >>>>>> 2. My recommendation would be to convert this shell script test >>>>>> into Java >>>>>> based test and re-use the dynamic port allocation solution by >>>>>> Stuart Marks to >>>>>> address the issue >>>>>> >>>>>> 3. Also this test was written with server/client mode in shell >>>>>> script. In the >>>>>> past there have been sync issues between server/client which >>>>>> caused the test >>>>>> to fail. If we convert the shell script into Java based test, it >>>>>> would avoid >>>>>> using "sleep 10" mechanism to allow for server and client to >>>>>> start up and >>>>>> also give us better control in synchronizing server and client. >>>>> >>>>> (Background for interested readers.) In general, yes, it's quite >>>>> difficult to >>>>> make reliable shell tests, especially for multi-process tests like >>>>> this one. >>>>> There is the unique port issue, and there is also the issue of how >>>>> long for >>>>> the client to wait until the server is ready. Error handling is >>>>> also a >>>>> problem, for example, if one of the JVMs gets an unexpected >>>>> exception, it's >>>>> easy for shell tests to mishandle this case. They might hang or >>>>> erroneously >>>>> report success. >>>>> >>>>> -- >>>>> >>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>> upload it >>>>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>> >>>>> Thanks. >>>>> >>>>> s'marks >>>> >> > From robert.field at oracle.com Sun Nov 10 07:24:31 2013 From: robert.field at oracle.com (Robert Field) Date: Sat, 09 Nov 2013 23:24:31 -0800 Subject: RFR (XXS) 8027803: NPE in test infrastructure aka: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails Message-ID: <527F34AF.40208@oracle.com> Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8027803 Basically, the ClassFileInstaller test utility is getting a Null Pointer Exception when the installed class file is in the default package (no package declared). And the fix is to check for the null that occurs in that case -- test/lib/testlibrary/ClassFileInstaller.java ------------------------------------------------------------------------ 28 import java.nio.file.StandardCopyOption; 29 30 /** 31 * Dump a class file for a class on the class path in the current directory 32 */ 33 public class ClassFileInstaller { 34 /** 35 * @param args The names of the classes to dump 36 * @throws Exception 37 */ 38 public static void main(String... args) throws Exception { 39 for (String arg : args) { 40 ClassLoader cl = ClassFileInstaller.class.getClassLoader(); 41 42 // Convert dotted class name to a path to a class file 43 String pathName = arg.replace('.', '/').concat(".class"); 44 InputStream is = cl.getResourceAsStream(pathName); 45 46 // Create the class file's package directory 47 Path p = Paths.get(pathName); 48 Files.createDirectories(p.getParent()); 49 // Create the class file 50 Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); 51 } 52 } 53 } ------------------------------------------------------------------------ 28 import java.nio.file.StandardCopyOption; 29 30 /** 31 * Dump a class file for a class on the class path in the current directory 32 */ 33 public class ClassFileInstaller { 34 /** 35 * @param args The names of the classes to dump 36 * @throws Exception 37 */ 38 public static void main(String... args) throws Exception { 39 for (String arg : args) { 40 ClassLoader cl = ClassFileInstaller.class.getClassLoader(); 41 42 // Convert dotted class name to a path to a class file 43 String pathName = arg.replace('.', '/').concat(".class"); 44 InputStream is = cl.getResourceAsStream(pathName); 45 46 // Create the class file's package directory 47 Path p = Paths.get(pathName); 48 Path parent = p.getParent(); 49 if (parent != null) { 50 Files.createDirectories(parent); 51 } 52 // Create the class file 53 Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); 54 } 55 } 56 } Contributed by Alan Bateman. Thanks, Robert From joel.franck at oracle.com Sun Nov 10 11:17:50 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Sun, 10 Nov 2013 12:17:50 +0100 Subject: RFR (XXS) 8027803: NPE in test infrastructure aka: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails In-Reply-To: <527F34AF.40208@oracle.com> References: <527F34AF.40208@oracle.com> Message-ID: Hi Robert, Looks good. cheers /Joel On 10 nov 2013, at 08:24, Robert Field wrote: > Please review the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8027803 > > Basically, the ClassFileInstaller test utility is getting a Null Pointer Exception when the installed class file is in the default package (no package declared). And the fix is to check for the null that occurs in that case -- > test/lib/testlibrary/ClassFileInstaller.java > > 28 import java.nio.file.StandardCopyOption; > 29 > 30 /** > 31 * Dump a class file for a class on the class path in the current directory > 32 */ > 33 public class ClassFileInstaller { > 34 /** > 35 * @param args The names of the classes to dump > 36 * @throws Exception > 37 */ > 38 public static void main(String... args) throws Exception { > 39 for (String arg : args) { > 40 ClassLoader cl = ClassFileInstaller.class.getClassLoader(); > 41 > 42 // Convert dotted class name to a path to a class file > 43 String pathName = arg.replace('.', '/').concat(".class"); > 44 InputStream is = cl.getResourceAsStream(pathName); > 45 > 46 // Create the class file's package directory > 47 Path p = Paths.get(pathName); > > 48 Files.createDirectories(p.getParent()); > > > > > 49 // Create the class file > 50 Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); > 51 } > 52 } > 53 } > > 28 import java.nio.file.StandardCopyOption; > 29 > 30 /** > 31 * Dump a class file for a class on the class path in the current directory > 32 */ > 33 public class ClassFileInstaller { > 34 /** > 35 * @param args The names of the classes to dump > 36 * @throws Exception > 37 */ > 38 public static void main(String... args) throws Exception { > 39 for (String arg : args) { > 40 ClassLoader cl = ClassFileInstaller.class.getClassLoader(); > 41 > 42 // Convert dotted class name to a path to a class file > 43 String pathName = arg.replace('.', '/').concat(".class"); > 44 InputStream is = cl.getResourceAsStream(pathName); > 45 > 46 // Create the class file's package directory > 47 Path p = Paths.get(pathName); > > 48 Path parent = p.getParent(); > 49 if (parent != null) { > 50 Files.createDirectories(parent); > 51 } > > 52 // Create the class file > 53 Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); > 54 } > 55 } > 56 } > > > > Contributed by Alan Bateman. > > Thanks, > Robert > > From kumar.x.srinivasan at oracle.com Sun Nov 10 17:11:15 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sun, 10 Nov 2013 09:11:15 -0800 (PST) Subject: RFR (XXS) 8027803: NPE in test infrastructure aka: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails Message-ID: <04afad8e-982a-4e30-b61c-fece87fb793e@default> Looks good. Kumar ----- robert.field at oracle.com wrote: > From: robert.field at oracle.com > To: core-libs-dev at openjdk.java.net > Cc: joel.franck at oracle.com, kumar.x.srinivasan at oracle.com, Alan.Bateman at oracle.com > Sent: Saturday, November 9, 2013 11:24:40 PM GMT -08:00 US/Canada Pacific > Subject: RFR (XXS) 8027803: NPE in test infrastructure aka: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails > > Please review the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8027803 > > Basically, the ClassFileInstaller test utility is getting a Null Pointer Exception when the installed class file is in the default package (no package declared). And the fix is to check for the null that occurs in that case -- > test/lib/testlibrary/ClassFileInstaller.java 28 import java.nio.file.StandardCopyOption; 29 30 /** 31 * Dump a class file for a class on the class path in the current directory 32 */ 33 public class ClassFileInstaller { 34 /** 35 * @param args The names of the classes to dump 36 * @throws Exception 37 */ 38 public static void main(String... args) throws Exception { 39 for (String arg : args) { 40 ClassLoader cl = ClassFileInstaller.class.getClassLoader(); 41 42 // Convert dotted class name to a path to a class file 43 String pathName = arg.replace('.', '/').concat(".class"); 44 InputStream is = cl.getResourceAsStream(pathName); 45 46 // Create the class file's package directory 47 Path p = Paths.get(pathName); 48 Files.createDirectories(p.getParent()); 49 // Create the class file 50 Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); 51 } 52 } 53 } 28 import java.nio.file.StandardCopyOption; 29 30 /** 31 * Dump a class file for a class on the class path in the current directory 32 */ 33 public class ClassFileInstaller { 34 /** 35 * @param args The names of the classes to dump 36 * @throws Exception 37 */ 38 public static void main(String... args) throws Exception { 39 for (String arg : args) { 40 ClassLoader cl = ClassFileInstaller.class.getClassLoader(); 41 42 // Convert dotted class name to a path to a class file 43 String pathName = arg.replace('.', '/').concat(".class"); 44 InputStream is = cl.getResourceAsStream(pathName); 45 46 // Create the class file's package directory 47 Path p = Paths.get(pathName); 48 Path parent = p.getParent(); 49 if (parent != null) { 50 Files.createDirectories(parent); 51 } 52 // Create the class file 53 Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); 54 } 55 } 56 } > Contributed by Alan Bateman. > > Thanks, > Robert > > > From chris.hegarty at oracle.com Sun Nov 10 17:17:37 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 10 Nov 2013 09:17:37 -0800 (PST) Subject: RFR: All test targets, jdk/test/Makefile, fail on Windows Message-ID: <527FBFB1.5070406@oracle.com> Recent changes to jdk/test/Makefile, in TL, causes all test batches to fail on Windows. I would like to propose a temporary measure to get the tests running again. This will give us the time to come up with a better longer term solution. From what I can tell cygpath, with '-s', fails when the path does not exist. At least on version 1.7.17 & 1.7.18. Trivially, I would like to propose to remove the '-s', as a temporary measure to get the test running again. hg diff test/Makefile diff -r 46982ca895b4 test/Makefile --- a/test/Makefile Fri Nov 08 18:54:29 2013 +0000 +++ b/test/Makefile Sun Nov 10 10:34:39 2013 +0000 @@ -64,7 +64,7 @@ ifeq ($(UNAME_S), CYGWIN) ifeq ($(UNAME_S), CYGWIN) # Location of developer shared files SLASH_JAVA = J: - GETMIXEDPATH = cygpath -m -s + GETMIXEDPATH = cygpath -m else # Location of developer shared files SLASH_JAVA = /java -Chris. From jaroslav.bachorik at oracle.com Sun Nov 10 19:07:18 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Sun, 10 Nov 2013 19:07:18 +0000 Subject: hg: jdk8/tl/jdk: 6523160: RuntimeMXBean.getUptime() returns negative values Message-ID: <20131110190730.17488624D7@hg.openjdk.java.net> Changeset: 0c75cc07d264 Author: jbachorik Date: 2013-11-10 20:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c75cc07d264 6523160: RuntimeMXBean.getUptime() returns negative values Summary: RuntimeMXBean.getUptime() should be based on HR timers rather than on the OS time Reviewed-by: dholmes, sla ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/VMManagementImpl.c ! test/java/lang/management/RuntimeMXBean/UpTime.java From forax at univ-mlv.fr Sun Nov 10 22:29:29 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 10 Nov 2013 23:29:29 +0100 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough Message-ID: <528008C9.7000905@univ-mlv.fr> The is a stupid issue with the signature of MethodHandleInfo.reflectAs, j.l.r.Field, Method or Constructor implement two interfaces Member and AnnotatedElement, with the current signature, the code info.reflectAs(Member.class, lookup) works but the code info.reflectAs(AnnotatedElement.class, lookup) doesn't work. Because there is no way to do an 'or' between several bounds of a type variable, I think that the signature of reflectAs should be changed from : public T reflectAs(Class expected, Lookup lookup); to public T reflectAs(Class expected, Lookup lookup); and the javadoc should be modified to explain that a Member or AnnotatedElement are valid bounds of T. As a side effect, the signature of MethodHandles.reflectAs(Class, MethodHandle) should be updated accordingly. There is a workaround, one can write: (AnnotatedElement)info.reflectAs(Member.class, lookup) but it's at best weird. cheers, R?mi From ali.ebrahimi1781 at gmail.com Mon Nov 11 01:24:56 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 11 Nov 2013 04:54:56 +0330 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough In-Reply-To: <528008C9.7000905@univ-mlv.fr> References: <528008C9.7000905@univ-mlv.fr> Message-ID: This is another workaround: public R reflectAs(Class expected, Lookup lookup); info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Object.class, lookup);doesn't work. info.reflectAs(Other.class, lookup);doesn't work. with this does not need to your javadoc and is more type safe. . On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax wrote: > The is a stupid issue with the signature of MethodHandleInfo.reflectAs, > j.l.r.Field, Method or Constructor implement two interfaces Member and > AnnotatedElement, with the current signature, the code > info.reflectAs(Member.class, lookup) > works but the code > info.reflectAs(AnnotatedElement.class, lookup) > doesn't work. > > Because there is no way to do an 'or' between several bounds of > a type variable, I think that the signature of reflectAs should be > changed from : > public T reflectAs(Class expected, Lookup lookup); > to > public T reflectAs(Class expected, Lookup lookup); > > and the javadoc should be modified to explain that a Member or > AnnotatedElement are > valid bounds of T. > > As a side effect, the signature of MethodHandles.reflectAs(Class, > MethodHandle) > should be updated accordingly. > > There is a workaround, one can write: > (AnnotatedElement)info.reflectAs(Member.class, lookup) > but it's at best weird. > > cheers, > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From peter.levart at gmail.com Mon Nov 11 07:14:39 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 11 Nov 2013 08:14:39 +0100 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough In-Reply-To: References: <528008C9.7000905@univ-mlv.fr> Message-ID: <528083DF.8030004@gmail.com> On 11/11/2013 02:24 AM, Ali Ebrahimi wrote: > This is another workaround: > > public R reflectAs(Class super T> expected, Lookup lookup); > > info.reflectAs(Member.class, lookup);//works > info.reflectAs(AnnotatedElement.class, lookup);//works > info.reflectAs(Member.class, lookup);//works > info.reflectAs(AnnotatedElement.class, lookup);//works > > > info.reflectAs(Object.class, lookup);doesn't work. > info.reflectAs(Other.class, lookup);doesn't work. > > with this does not need to your javadoc and is more type safe. . Hm... it doesn't look very compile-time type-safe: String s = info.reflectAs(Method.class, lookup); // compiles !!! IMO, I would rather remove the Class parameter altogether. It serves no purpose in the method implementation other than to perform a cast-check on the returned object. The method could simply be: public T reflect(Lookup lookup); This would not solve the problem Remi put forward. I.e. this would not compile: AnnotatedElement ae = info.reflect(lookup); But with an explicit cast, It compiles: AnnotatedElement ae = (AnnotatedElement) info.reflect(lookup); And compared to what we would have with Class parameter and loosened compile-time type-safety as per Remi's suggestion, it is still shorter: AnnotatedElement ae = info.reflectAs(AnnotatedElement.class, lookup); // this is longer! A type-unsafe variant is possible too (I'm not advocating it): public T reflect(Lookup lookup); Now that Generalized Target-Type Inference is part of Java 8, using Class parameters just as hints to the compiler is not needed in many cases. But if one needs to hint the compiler, explicit type parameters can be used as an escape hatch as always: Object o = info.reflect(lookup); Regards, Peter > > > > > On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax > wrote: > > The is a stupid issue with the signature of > MethodHandleInfo.reflectAs, > j.l.r.Field, Method or Constructor implement two interfaces Member and > AnnotatedElement, with the current signature, the code > info.reflectAs(Member.class, lookup) > works but the code > info.reflectAs(AnnotatedElement.class, lookup) > doesn't work. > > Because there is no way to do an 'or' between several bounds of > a type variable, I think that the signature of reflectAs should be > changed from : > public T reflectAs(Class expected, Lookup > lookup); > to > public T reflectAs(Class expected, Lookup lookup); > > and the javadoc should be modified to explain that a Member or > AnnotatedElement are > valid bounds of T. > > As a side effect, the signature of MethodHandles.reflectAs(Class, > MethodHandle) > should be updated accordingly. > > There is a workaround, one can write: > (AnnotatedElement)info.reflectAs(Member.class, lookup) > but it's at best weird. > > cheers, > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From peter.levart at gmail.com Mon Nov 11 08:35:49 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 11 Nov 2013 09:35:49 +0100 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough In-Reply-To: <528083DF.8030004@gmail.com> References: <528008C9.7000905@univ-mlv.fr> <528083DF.8030004@gmail.com> Message-ID: <528096E5.8000909@gmail.com> On 11/11/2013 08:14 AM, Peter Levart wrote: > The method could simply be: > > public 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.reflect(lookup); > Well, well, explicit type parameters for method invocation are not needed in above example: Object o = info.reflect(lookup); // compiles One would only need them in situations like: info.reflect(lookup).invoke(...); Regards, Peter From alan.bateman at oracle.com Mon Nov 11 08:39:34 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 11 Nov 2013 08:39:34 +0000 Subject: hg: jdk8/tl/jdk: 8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win) Message-ID: <20131111083948.C6350624E3@hg.openjdk.java.net> Changeset: 2525b91ca5a6 Author: alanb Date: 2013-11-11 08:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2525b91ca5a6 8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win) Reviewed-by: mchung ! src/windows/classes/sun/management/OperatingSystemImpl.java From weijun.wang at oracle.com Mon Nov 11 08:56:02 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 11 Nov 2013 08:56:02 +0000 Subject: hg: jdk8/tl/jdk: 8027991: InputStream should be closed in sun.security.tools.jarsigner.Main Message-ID: <20131111085614.8B424624E4@hg.openjdk.java.net> Changeset: 7304b3195212 Author: weijun Date: 2013-11-11 16:54 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7304b3195212 8027991: InputStream should be closed in sun.security.tools.jarsigner.Main Reviewed-by: xuelei ! src/share/classes/sun/security/tools/jarsigner/Main.java + test/sun/security/tools/jarsigner/CertChainUnclosed.java From paul.sandoz at oracle.com Mon Nov 11 09:15:18 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 11 Nov 2013 10:15:18 +0100 Subject: RFR: JDK-8027645: Pattern.split() with positive lookahead In-Reply-To: <527D5E13.7080001@oracle.com> References: <527BE318.3050007@oracle.com> <69D00307-B80A-42F3-8744-DB0F4B5A9DB7@oracle.com> <527D5E13.7080001@oracle.com> Message-ID: <16313A46-E05F-42F2-8F14-F45073BEF7F6@oracle.com> On Nov 8, 2013, at 10:56 PM, Xueming Shen wrote: > On 11/08/2013 01:19 AM, Paul Sandoz wrote: >> Hi Sherman. >> >> When you say: >> >> + * of the stream. A zero-width match at the beginning however never produces >> + * such empty leading substring. >> >> Is it possible to have a starting sequence of one or more zero-width matches? > > The matcher.find() always increases its "next find start position" at least one > as showed in Matcher.find() impl ("first" starts from -1), so the matcher.find() > should keep going forward, never produce more than one zero-length substring. > OK. > Matcher: > public boolean find() { > int nextSearchIndex = last; > if (nextSearchIndex == first) > nextSearchIndex++; > ... > > The webrev has been updated to use your optimized version in splitAsStream(). > > http://cr.openjdk.java.net/~sherman/8027645/webrev/ +1 I still think it would be useful to add a comment at the relevant code location about zero-width match behaviour. Paul.. From mcnepp02 at googlemail.com Mon Nov 11 09:55:48 2013 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 11 Nov 2013 10:55:48 +0100 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough In-Reply-To: <528008C9.7000905@univ-mlv.fr> References: <528008C9.7000905@univ-mlv.fr> Message-ID: Hmm, maybe I don't understand you correctly, but I can see no compelling need to be able to do "info.reflectAs(AnnotatedElement.class, lookup)", as the method's spec clearly says that it will return one of the three types known to implement java.lang.reflect.Member. Those types all implement java.lang.reflect.AnnotatedElement, so you're on the safe side if you apply such a cast to the return value. That said, since we know that Java allows Annotations on all class members, a possibly more consistent API would make j.l.r.Member extend j.l.r.AnnotatedElement! (Now that we have default methods, such a change could even be made without breaking compatibility.) 2013/11/10 Remi Forax > The is a stupid issue with the signature of MethodHandleInfo.reflectAs, > j.l.r.Field, Method or Constructor implement two interfaces Member and > AnnotatedElement, with the current signature, the code > info.reflectAs(Member.class, lookup) > works but the code > info.reflectAs(AnnotatedElement.class, lookup) > doesn't work. > > Because there is no way to do an 'or' between several bounds of > a type variable, I think that the signature of reflectAs should be > changed from : > public T reflectAs(Class expected, Lookup lookup); > to > public T reflectAs(Class expected, Lookup lookup); > > and the javadoc should be modified to explain that a Member or > AnnotatedElement are > valid bounds of T. > > As a side effect, the signature of MethodHandles.reflectAs(Class, > MethodHandle) > should be updated accordingly. > > There is a workaround, one can write: > (AnnotatedElement)info.reflectAs(Member.class, lookup) > but it's at best weird. > > cheers, > R?mi > > From chris.hegarty at oracle.com Mon Nov 11 10:34:18 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Nov 2013 10:34:18 +0000 Subject: hg: jdk8/tl/jdk: 8028102: All test targets, jdk/test/Makefile, fail on Windows Message-ID: <20131111103441.A2965624F0@hg.openjdk.java.net> Changeset: b48eded97dff Author: chegar Date: 2013-11-11 10:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b48eded97dff 8028102: All test targets, jdk/test/Makefile, fail on Windows Reviewed-by: mduigou ! test/Makefile From peter.levart at gmail.com Mon Nov 11 12:58:23 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 11 Nov 2013 13:58:23 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <52782DD1.3020902@univ-mlv.fr> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278139B.1090508@univ-mlv.fr> <52782DD1.3020902@univ-mlv.fr> Message-ID: <5280D46F.1060908@gmail.com> 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: >> https://bugs.openjdk.java.net/browse/JDK-6824466 > > I remember writing a code like that a long time ago, to see if it was > possible, > as far as I remember, the main issue was to be able to say, please > compiler > compile this method handle chain into a blob that I can reuse. > >> >> ? John > > regards, > R?mi Hi John, Remi, I tried to create a prototype to see how it compares to bytecode-generated method accessor. Here it is: https://bugs.openjdk.java.net/browse/JDK-6824466#comment-13426571 It seems that lambda forms do their job quite well. Do experts have any suggestion how to improve it? Regards, Peter From Sergey.Bylokhov at oracle.com Mon Nov 11 13:39:24 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Nov 2013 17:39:24 +0400 Subject: [8] Review Request: 8027696 Incorrect copyright header in the tests In-Reply-To: <527B99BD.8050401@oracle.com> References: <52738E00.2070806@oracle.com> <5274E3FF.3070807@oracle.com> <52791C93.1060600@oracle.com> <527B77F0.4050109@oracle.com> <527B99BD.8050401@oracle.com> Message-ID: <5280DE0C.7000503@oracle.com> Hello. I'll push the changes, if there are no new objections. On 07.11.2013 17:46, Sergey Bylokhov wrote: > On 07.11.2013 15:22, Alan Bateman wrote: >> Thanks Sergey, I sampled a few and they look correct. >> >> The only thing is that I'm not sure about is test/Makefile, it's just >> not clear whether which header this should have. > I can skip it this time. > -- Best regards, Sergey. From tristan.yan at oracle.com Mon Nov 11 13:39:38 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 11 Nov 2013 21:39:38 +0800 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <527EFB4B.1010502@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> Message-ID: <5280DE1A.4040708@oracle.com> Hi Stuart Also there is one more solution, which is there is one jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same function as TestLibrary.getUnusedRandomPort() and it has named package. Do you mind I use this one? Since these two functions provide same functionality. Maybe we should think about to merge them at the same time. Thank you Tristan On 11/10/2013 11:19 AM, Tristan Yan wrote: > Hi Stuart > I tried your suggestion but unfortunately all the benchmarks have > dependencies to Main class because they need get stub from server. I > suggest we move the benchmark tests to unnamed package unless we do > want to put TestLibrary into a named package right now. > Please let me know if you have objection on this. > Thank you > Tristan > > On 11/09/2013 02:28 AM, Stuart Marks wrote: >> Hi Tristan, >> >> Yes, it's kind of a problem that the RMI TestLibrary is in the >> unnamed package. Classes in a named package cannot import classes >> from the unnamed package. We've run into problems with this before. >> Eventually, we should move TestLibrary a named package. >> >> I think it's possible to work around this without too much >> difficulty. Note that classes in the unnamed package can import >> classes from named packages. So, perhaps you can put the RmiBench >> main class in the unnamed package so it has access to TestLibrary. >> Then have the benchmarks themselves in the bench.rmi package. The >> config file already references the benchmarks by fully qualified >> class name (e.g., "bench.rmi.NullCalls") so with a bit of tinkering >> you ought to be able to get this to work. >> >> s'marks >> >> On 11/8/13 3:00 AM, Tristan Yan wrote: >>> Thank you, Stuart >>> There is one review point I want to ask you opinion. Which is the >>> reason that I moved from >>> test/java/rmi/reliability/benchmark/bench/rmi to >>> test/java/rmi/reliability/benchmark is Main.java need access class >>> TestLibrary for supporting random port. TestLibrary is a unpackage >>> class, I couldn't find a way to let a class which has Package to >>> access the class without package. Do you have suggestion on that? >>> Thank you so much. >>> Tristan >>> >>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>> >>>> >>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>> Hi Everyone >>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>> >>>>> Description: >>>>> 1. Convert shell script test to Java program test. >>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>> replace fixed >>>>> server port. >>>>> 3. Using java Process class to start client process. >>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>> program test also >>>> >>>> Hi Tristan, >>>> >>>> Several comments on this webrev. >>>> >>>> >>>> ** The original arrangement within the >>>> test/java/rmi/reliability/benchmark directory had the main >>>> benchmark files (scripts) at the top, some benchmark framework >>>> files in the "bench" subdirectory, and the actual RMI and >>>> serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>> >>>> The webrev moves all the RMI benchmarks to the top benchmark >>>> directory but leaves the serial benchmarks in bench/serial. The RMI >>>> benchmarks are now all cluttering the top directory, but the main >>>> serial benchmark test is now buried in the bench/serial directory. >>>> The nice organization that was there before is now spoiled. Is this >>>> rearrangement necessary in order to convert the scripts to Java? I >>>> would prefer the original arrangement be left in place. >>>> >>>> >>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>> >>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>> -c config >>>> >>>> There is a subtle but serious problem here: the -server option is >>>> passed to the >>JVM<< and not as an argument to the main() method. >>>> The main() method gets neither a -server nor a -client argument, so >>>> its default "run mode" as defined by the benchmark itself is >>>> SAMEVM. This runs the client and server in the same JVM, which is >>>> different from the shell script, which ran separate client and >>>> server JVMs. >>>> >>>> >>>> ** The logic to process the -server argument still expects to take >>>> a port, even though the port is assigned automatically. So the >>>> obvious fix to the above, >>>> >>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>> -c config >>>> >>>> doesn't work, since a port is missing. The logic to increment the >>>> argument index to collect the port argument should be removed. >>>> Also, the -server line should be restored to the usage message, but >>>> without the port argument. >>>> >>>> >>>> ** After this is done, the client's command line is constructed >>>> improperly. The command line ends up looking something like this: >>>> >>>> java client -cp Main client localhost:58583 -c config >>>> >>>> The word "client" appears twice, but what's really required is >>>> "-client" to appear as an argument after Main. >>>> >>>> >>>> ** The client is run using ProcessBuilder, which by default sends >>>> stdout and stderr to pipes to be read by the parent. But the parent >>>> never reads them, thus any messages from the client are never seen. >>>> The client is the one that emits the benchmark report, so its >>>> output needs to be seen. It might be sufficient to have the client >>>> inherit the parent's stdout and stderr. This might intermix the >>>> client's and server's output, but it's better than nothing. >>>> >>>> >>>> ** The config file is checked with the following code: >>>> >>>> try { >>>> confFile = args[i]; >>>> confstr = new FileInputStream(System.getProperty("test.src") >>>> + System.getProperty("file.separator") + confFile); >>>> } catch (IOException e) { >>>> die("Error: unable to open \"" + args[i] + "\""); >>>> } >>>> >>>> This is potentially misleading, as the message doesn't print the >>>> actual filename that was attempted to be opened. >>>> >>>> This is important, as the test.src property doesn't exist in the >>>> client JVM. >>>> >>>> Note that the original shell script passed full pathnames for the >>>> config file to both the client and the server. The new @run tag >>>> merely says "-c config" which redefines the config filename to be >>>> relative to the test.src directory. You could pass -Dtest.src=... >>>> to the client, but it seems like there should be something better >>>> than can be done. >>>> >>>> >>>> ** The client needs to have its security policy set up. This is >>>> missing from the construction of the client's command line. >>>> >>>> >>>> ** ProcessBuilder takes a List for its command; there is no >>>> need to turn the list into an array. >>>> >>>> >>>> ** In the benchmark main methods, code of the form, >>>> >>>> while (true) { >>>> runBenchmarks(); >>>> if (exitRequested) { >>>> System.exit(); >>>> } >>>> } >>>> >>>> was replaced with >>>> >>>> while (!exitRequested) { >>>> runBenchmarks(); >>>> } >>>> >>>> This is a subtle logic change, in that the former code always >>>> executed the loop at least once. It seems unlikely, but it's >>>> possible that a timer could set exitRequested before loop entry, >>>> resulting in the benchmark running zero times. I guess, if you >>>> really want to clean this up (we do need to avoid System.exit in >>>> jtreg tests), use a do-while loop instead. >>>> >>>> >>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>> ProblemList.txt. >>>> >>>> >>>> ** Remove the references to RMISecurityManager and just use >>>> SecurityManager. This is just general cleanup. (I deprecated >>>> RMISecurityManager last week.) :-) >>>> >>>> >>>> It would be good if you could fix up these issues and post another >>>> webrev. >>>> >>>> Thanks. >>>> >>>> s'marks >>>> >>>> >>>> >>>> >>>>> Thank you >>>>> Tristan >>>>> >>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>> I am working on bug >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>> on my research, it looks like the issue of fixed port was >>>>>>> already addressed >>>>>>> by Stuart Marks in other RMI tests which are Java based. I would >>>>>>> like to >>>>>>> reuse his solution, however it does not work for shell based tests. >>>>>> >>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>> >>>>>> Was the patch attached to your message? If so, it didn't get >>>>>> through. Most >>>>>> OpenJDK mailing lists strip off attachments before forwarding >>>>>> Hi Stuart >>>>>> Also there is one more solution, which is there is one >>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>> same function as TestLibrary.getUnusedRandomPort() and it has >>>>>> named package. Do you mind I use this one? >>>>>> Since these two function provide same functionality. Maybe we >>>>>> should think about to merge them. >>>>>> Thank you >>>>>> Tristan >>>>>> >>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>> Hi Stuart >>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>> have dependencies to Main class because they need get stub from >>>>>>> server. I suggest we move the benchmark tests to unnamed package >>>>>>> unless we do want to put TestLibrary into a named package right now. >>>>>>> Please let me know if you have objection on this. >>>>>>> Thank you >>>>>>> Tristan >>>>>>> >>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>> Hi Tristan, >>>>>>>> >>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>> this before. Eventually, we should move TestLibrary a named >>>>>>>> package. >>>>>>>> >>>>>>>> I think it's possible to work around this without too much >>>>>>>> difficulty. Note that classes in the unnamed package can import >>>>>>>> classes from named packages. So, perhaps you can put the >>>>>>>> RmiBench main class in the unnamed package so it has access to >>>>>>>> TestLibrary. Then have the benchmarks themselves in the >>>>>>>> bench.rmi package. The config file already references the >>>>>>>> benchmarks by fully qualified class name (e.g., >>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>> be able to get this to work. >>>>>>>> >>>>>>>> s'marks >>>>>>>> >>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>> Thank you, Stuart >>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>> the reason that I moved from >>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>>>>>>> test/java/rmi/reliability/benchmark is Main.java need access >>>>>>>>> class TestLibrary for supporting random port. TestLibrary is a >>>>>>>>> unpackage class, I couldn't find a way to let a class which >>>>>>>>> has Package to access the class without package. Do you have >>>>>>>>> suggestion on that? >>>>>>>>> Thank you so much. >>>>>>>>> Tristan >>>>>>>>> >>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>> Hi Everyone >>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>> >>>>>>>>>>> Description: >>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>> to replace fixed >>>>>>>>>>> server port. >>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh to >>>>>>>>>>> java program test also >>>>>>>>>> >>>>>>>>>> Hi Tristan, >>>>>>>>>> >>>>>>>>>> Several comments on this webrev. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** The original arrangement within the >>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>> RMI and serialization benchmarks in bench/rmi and >>>>>>>>>> bench/serial subdirectories. >>>>>>>>>> >>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>> but the main serial benchmark test is now buried in the >>>>>>>>>> bench/serial directory. The nice organization that was there >>>>>>>>>> before is now spoiled. Is this rearrangement necessary in >>>>>>>>>> order to convert the scripts to Java? I would prefer the >>>>>>>>>> original arrangement be left in place. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>>>>>>> >>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>>> Main -c config >>>>>>>>>> >>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>> option is passed to the >>JVM<< and not as an argument to the >>>>>>>>>> main() method. The main() method gets neither a -server nor a >>>>>>>>>> -client argument, so its default "run mode" as defined by the >>>>>>>>>> benchmark itself is SAMEVM. This runs the client and server >>>>>>>>>> in the same JVM, which is different from the shell script, >>>>>>>>>> which ran separate client and server JVMs. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** The logic to process the -server argument still expects to >>>>>>>>>> take a port, even though the port is assigned automatically. >>>>>>>>>> So the obvious fix to the above, >>>>>>>>>> >>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>> -server -c config >>>>>>>>>> >>>>>>>>>> doesn't work, since a port is missing. The logic to increment >>>>>>>>>> the argument index to collect the port argument should be >>>>>>>>>> removed. Also, the -server line should be restored to the >>>>>>>>>> usage message, but without the port argument. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>> constructed improperly. The command line ends up looking >>>>>>>>>> something like this: >>>>>>>>>> >>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>> -c config >>>>>>>>>> >>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>> But the parent never reads them, thus any messages from the >>>>>>>>>> client are never seen. The client is the one that emits the >>>>>>>>>> benchmark report, so its output needs to be seen. It might be >>>>>>>>>> sufficient to have the client inherit the parent's stdout and >>>>>>>>>> stderr. This might intermix the client's and server's output, >>>>>>>>>> but it's better than nothing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>> >>>>>>>>>> try { >>>>>>>>>> confFile = args[i]; >>>>>>>>>> confstr = new >>>>>>>>>> FileInputStream(System.getProperty("test.src") >>>>>>>>>> + System.getProperty("file.separator") + >>>>>>>>>> confFile); >>>>>>>>>> } catch (IOException e) { >>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>> >>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>> the client JVM. >>>>>>>>>> >>>>>>>>>> Note that the original shell script passed full pathnames for >>>>>>>>>> the config file to both the client and the server. The new >>>>>>>>>> @run tag merely says "-c config" which redefines the config >>>>>>>>>> filename to be relative to the test.src directory. You could >>>>>>>>>> pass -Dtest.src=... to the client, but it seems like there >>>>>>>>>> should be something better than can be done. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** ProcessBuilder takes a List for its command; there >>>>>>>>>> is no need to turn the list into an array. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>> >>>>>>>>>> while (true) { >>>>>>>>>> runBenchmarks(); >>>>>>>>>> if (exitRequested) { >>>>>>>>>> System.exit(); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> was replaced with >>>>>>>>>> >>>>>>>>>> while (!exitRequested) { >>>>>>>>>> runBenchmarks(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> This is a subtle logic change, in that the former code always >>>>>>>>>> executed the loop at least once. It seems unlikely, but it's >>>>>>>>>> possible that a timer could set exitRequested before loop >>>>>>>>>> entry, resulting in the benchmark running zero times. I >>>>>>>>>> guess, if you really want to clean this up (we do need to >>>>>>>>>> avoid System.exit in jtreg tests), use a do-while loop instead. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>> from ProblemList.txt. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>> another webrev. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> s'marks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thank you >>>>>>>>>>> Tristan >>>>>>>>>>> >>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>> already addressed >>>>>>>>>>>>> by Stuart Marks in other RMI tests which are Java based. I >>>>>>>>>>>>> would like to >>>>>>>>>>>>> reuse his solution, however it does not work for shell >>>>>>>>>>>>> based tests. >>>>>>>>>>>> >>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>> >>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>> get through. Most >>>>>>>>>>>> OpenJDK mailing lists strip off attachments before >>>>>>>>>>>> forwarding the message to >>>>>>>>>>>> the recipients. >>>>>>>>>>>> >>>>>>>>>>>>> 2. My recommendation would be to convert this shell script >>>>>>>>>>>>> test into Java >>>>>>>>>>>>> based test and re-use the dynamic port allocation solution >>>>>>>>>>>>> by Stuart Marks to >>>>>>>>>>>>> address the issue >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>> shell script. In the >>>>>>>>>>>>> past there have been sync issues between server/client >>>>>>>>>>>>> which caused the test >>>>>>>>>>>>> to fail. If we convert the shell script into Java based >>>>>>>>>>>>> test, it would avoid >>>>>>>>>>>>> using "sleep 10" mechanism to allow for server and client >>>>>>>>>>>>> to start up and >>>>>>>>>>>>> also give us better control in synchronizing server and >>>>>>>>>>>>> client. >>>>>>>>>>>> >>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>> quite difficult to >>>>>>>>>>>> make reliable shell tests, especially for multi-process >>>>>>>>>>>> tests like this one. >>>>>>>>>>>> There is the unique port issue, and there is also the issue >>>>>>>>>>>> of how long for >>>>>>>>>>>> the client to wait until the server is ready. Error >>>>>>>>>>>> handling is also a >>>>>>>>>>>> problem, for example, if one of the JVMs gets an unexpected >>>>>>>>>>>> exception, it's >>>>>>>>>>>> easy for shell tests to mishandle this case. They might >>>>>>>>>>>> hang or erroneously >>>>>>>>>>>> report success. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>> need to upload it >>>>>>>>>>>> somewhere (e.g., cr.openjdk.java.net) and then post a link >>>>>>>>>>>> to it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> s'marks >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> the message to >>>>>> the recipients. >>>>>> >>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>> into Java >>>>>>> based test and re-use the dynamic port allocation solution by >>>>>>> Stuart Marks to >>>>>>> address the issue >>>>>>> >>>>>>> 3. Also this test was written with server/client mode in shell >>>>>>> script. In the >>>>>>> past there have been sync issues between server/client which >>>>>>> caused the test >>>>>>> to fail. If we convert the shell script into Java based test, it >>>>>>> would avoid >>>>>>> using "sleep 10" mechanism to allow for server and client to >>>>>>> start up and >>>>>>> also give us better control in synchronizing server and client. >>>>>> >>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>> difficult to >>>>>> make reliable shell tests, especially for multi-process tests >>>>>> like this one. >>>>>> There is the unique port issue, and there is also the issue of >>>>>> how long for >>>>>> the client to wait until the server is ready. Error handling is >>>>>> also a >>>>>> problem, for example, if one of the JVMs gets an unexpected >>>>>> exception, it's >>>>>> easy for shell tests to mishandle this case. They might hang or >>>>>> erroneously >>>>>> report success. >>>>>> >>>>>> -- >>>>>> >>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>> upload it >>>>>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> s'marks >>>>> >>> >> > From alexyursha at gmail.com Mon Nov 11 15:13:03 2013 From: alexyursha at gmail.com (Alex Yursha) Date: Mon, 11 Nov 2013 18:13:03 +0300 Subject: Redundant downcast in openjdk-7u40/jdk/src/share/classes/java/util/Arrays.java Message-ID: I found a minor issue on openjdk-7u40 sources. Is this the right place to discuss such things and if not could you please give me a hint on where this right place is? I am really lost trying to find the right place to open the issue. The issue itself is laid below. Redundant downcast to java.lang.Object is made in method copyOf(U[] original, int newLength, Class newType) (line 2245): 2244 public static T[] copyOf(U[] original, int newLength, Class newType) { 2245 T[] copy = ((Object)newType == (Object)Object[].class) 2246 ? (T[]) new Object[newLength] 2247 : (T[]) Array.newInstance(newType.getComponentType(), newLength); 2248 System.arraycopy(original, 0, copy, 0, 2249 Math.min(original.length, newLength)); 2250 return copy; 2251 } Actually, we need only to downcast one of the operands in order to avoid compiler complaints about incomparable types. The patch can look like this: - 2245 T[] copy = ((Object)newType == (Object)Object[].class) +2245 T[] copy = ((Object)newType == Object[].class) Regards, Alex Yursha From eric.mccorkle at oracle.com Mon Nov 11 14:48:13 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Mon, 11 Nov 2013 14:48:13 +0000 Subject: hg: jdk8/tl/langtools: 8027439: Compile-time error in the case of ((Integer[] & Serializable)new Integer[1]).getClass(); ... Message-ID: <20131111144816.61A23624F7@hg.openjdk.java.net> Changeset: 4788eb38cac5 Author: emc Date: 2013-11-11 09:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4788eb38cac5 8027439: Compile-time error in the case of ((Integer[] & Serializable)new Integer[1]).getClass() 8027253: javac illegally accepts array as bound Summary: backing out change allowing arrays in intersection types Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/ArraysInIntersections.java - test/tools/javac/InferArraysInIntersections.java - test/tools/javac/diags/examples/InterfaceOrArrayExpected.java ! test/tools/javac/generics/typevars/6680106/T6680106.out From joel.franck at oracle.com Mon Nov 11 16:29:23 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 11 Nov 2013 16:29:23 +0000 Subject: hg: jdk8/tl/langtools: 8027375: javac asserts on nested erroneous annotations Message-ID: <20131111162926.A5F28624FD@hg.openjdk.java.net> Changeset: f3ca12d680f3 Author: jfranck Date: 2013-11-11 17:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3ca12d680f3 8027375: javac asserts on nested erroneous annotations Summary: make sure JCAnnotation trees have type != null before annotation processing Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/testCrashNestedAnnos/TestCrashNestedAnnos.java + test/tools/javac/annotations/testCrashNestedAnnos/TestCrashNestedAnnos.out From michael.x.mcmahon at oracle.com Mon Nov 11 16:06:42 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 11 Nov 2013 16:06:42 +0000 Subject: hg: jdk8/tl/jdk: 8028060: test/java/net/URLPermission/nstest/lookup.sh failing (win) Message-ID: <20131111160655.11C41624FB@hg.openjdk.java.net> Changeset: 0e47462f03a0 Author: michaelm Date: 2013-11-11 16:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e47462f03a0 8028060: test/java/net/URLPermission/nstest/lookup.sh failing (win) Reviewed-by: alanb ! test/java/net/URLPermission/nstest/LookupTest.java ! test/java/net/URLPermission/nstest/lookup.sh From xueming.shen at oracle.com Mon Nov 11 18:02:44 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 11 Nov 2013 10:02:44 -0800 Subject: RFR: JDK-8027645: Pattern.split() with positive lookahead In-Reply-To: <16313A46-E05F-42F2-8F14-F45073BEF7F6@oracle.com> References: <527BE318.3050007@oracle.com> <69D00307-B80A-42F3-8744-DB0F4B5A9DB7@oracle.com> <527D5E13.7080001@oracle.com> <16313A46-E05F-42F2-8F14-F45073BEF7F6@oracle.com> Message-ID: <52811BC4.5090607@oracle.com> On 11/11/2013 01:15 AM, Paul Sandoz wrote: > On Nov 8, 2013, at 10:56 PM, Xueming Shen wrote: > >> On 11/08/2013 01:19 AM, Paul Sandoz wrote: >>> Hi Sherman. >>> >>> When you say: >>> >>> + * of the stream. A zero-width match at the beginning however never produces >>> + * such empty leading substring. >>> >>> Is it possible to have a starting sequence of one or more zero-width matches? >> The matcher.find() always increases its "next find start position" at least one >> as showed in Matcher.find() impl ("first" starts from -1), so the matcher.find() >> should keep going forward, never produce more than one zero-length substring. >> > OK. > > >> Matcher: >> public boolean find() { >> int nextSearchIndex = last; >> if (nextSearchIndex == first) >> nextSearchIndex++; >> ... >> >> The webrev has been updated to use your optimized version in splitAsStream(). >> >> http://cr.openjdk.java.net/~sherman/8027645/webrev/ > +1 > > I still think it would be useful to add a comment at the relevant code location about zero-width match behaviour. Thanks Paul! I added two lines of comment as suggested. http://cr.openjdk.java.net/~sherman/8027645/webrev -Sherman From christine.lu at oracle.com Tue Nov 5 01:39:26 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Tue, 05 Nov 2013 01:39:26 +0000 Subject: hg: jdk8/tl/langtools: 8025844: Need test to provide coverage for new DocumentationTool.Location enum Message-ID: <20131105013930.5E02C62A44@hg.openjdk.java.net> Changeset: 106b8fa32d71 Author: cl Date: 2013-11-04 17:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/106b8fa32d71 8025844: Need test to provide coverage for new DocumentationTool.Location enum Reviewed-by: jjg + test/tools/javadoc/api/basic/DocumentationToolLocationTest.java From christine.lu at oracle.com Tue Nov 5 02:05:45 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Tue, 05 Nov 2013 02:05:45 +0000 Subject: hg: jdk8/tl/langtools: 8027411: javap tonga tests cleanup: write a java program to test invalid options -h and -b Message-ID: <20131105020548.ACB8262A47@hg.openjdk.java.net> Changeset: 658861d1b36e Author: cl Date: 2013-11-04 18:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/658861d1b36e 8027411: javap tonga tests cleanup: write a java program to test invalid options -h and -b Reviewed-by: jjg + test/tools/javap/InvalidOptions.java From christine.lu at oracle.com Tue Nov 5 02:52:45 2013 From: christine.lu at oracle.com (christine.lu at oracle.com) Date: Tue, 05 Nov 2013 02:52:45 +0000 Subject: hg: jdk8/tl/langtools: 8027530: javap tonga tests cleanup: test -public, -protected, -package, -private options Message-ID: <20131105025248.5695E62A4C@hg.openjdk.java.net> Changeset: 126dc007ba3f Author: cl Date: 2013-11-04 18:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/126dc007ba3f 8027530: javap tonga tests cleanup: test -public, -protected, -package, -private options Reviewed-by: jjg + test/tools/javap/AccessModifiers.java From snazy at gmx.de Wed Nov 6 21:14:23 2013 From: snazy at gmx.de (Robert Stupp) Date: Wed, 6 Nov 2013 22:14:23 +0100 Subject: Please help - OSX 10.9 build fails In-Reply-To: References: Message-ID: <2D39CE59-C5E8-4B26-B679-6A10F0400338@gmx.de> Hi, I'm trying to build openjdk8 on OSX 10.9 but it fails. The first issue is that cc complains about "undefined symbols __FreeBSD__, __OpenBSD__, __NetBSD". I worked around that by changing the "#elif (symbol)" lines with #endif/#ifdef lines. The next flood of errors look very strange - it seems that objc sources are used in "plain K&R C" context... The latest change in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m was on Oct 13th (7098194: integrate macosx-port changes) Compiling /Users/snazy/devel/openjdk8/hotspot/src/share/vm/utilities/workgroup.cpp Compiling /Users/snazy/devel/openjdk8/hotspot/src/share/vm/utilities/xmlstream.cpp Compiling /Users/snazy/devel/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp Making signal interposition lib... Making SA debugger back-end... In file included from /System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:6, from /System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:5, from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:10, from /Users/snazy/devel/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /usr/include/objc/NSObject.h:41: error: stray '@' in program /usr/include/objc/NSObject.h:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '-' token /usr/include/objc/NSObject.h:50: error: expected identifier or '(' before 'interface' /usr/include/objc/NSObject.h:56: error: expected '{' before '+' token /usr/include/objc/NSObject.h:87: error: expected '{' before '__attribute__' /usr/include/objc/NSObject.h:91: error: expected '{' before '+' token In file included from /System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:8, from /System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:5, from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:10, from /Users/snazy/devel/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:14: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:15: error: expected ')' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:16: error: expected ')' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:17: error: expected ')' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:20: error: expected ')' before '*' token /System/Library/Frameworks/Foundation.framework/Headers/NSZone.h:21: error: expected ')' before '*' token - Robert From snazy at gmx.de Wed Nov 6 21:54:47 2013 From: snazy at gmx.de (Robert Stupp) Date: Wed, 6 Nov 2013 22:54:47 +0100 Subject: shared "value" in java.lang.StringBuilder In-Reply-To: References: Message-ID: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> Hi, I was wondering why the mostly allocated class in nearly all applications is char[]. A deeper inspection showed that a lot of these char[] allocations are "caused" by the code from java.lang.StringBuilder.toString(), which created a copy of its internal char array. Most StringBuilder instances are no longer used after the call to StringBuilder.toString(). Many of these instances have been created by javac caused by "plain" string concatenation in source code. Wouldn't it worth to try whether passing the (Abstract)StringBuilder's value+count values to String results in less temporary object creations and therefore reduce pressure on new generation (and reduce GC effort)? My idea is to add a field 'shared' to AbstractStringBuilder, which is set when StringBuilder.toString() is called. If the StringBuilder is really modified after calling toString(), the StringBuilder creates a new copy of the value array and resets the 'shared' field. Since the value array might be longer than the current count, String class would need a "re-invention" of the count field. Another think I noticed is that the StringBuilder instances transiently created by javac seem to use the default constructor. But a huge amount of string concatenations in Java code result in (much) longer Strings, which means that each append creates a new, larger copy of the value array in AbstractStringBuilder. Is it possible to add some "guessing" for the initial capacity - this would eliminate a lot of temporary objects and reduce GC effort. Is it worth to check this out? Are the two places in com.sun.tools.javac.jvm.Gen#visitAssignop/visitBinary the only places where these StringBuilder instances are created? - Robert From snazy at gmx.de Wed Nov 6 22:55:16 2013 From: snazy at gmx.de (Robert Stupp) Date: Wed, 6 Nov 2013 23:55:16 +0100 Subject: javac: optimized for-each over RandomAccess List In-Reply-To: References: Message-ID: <164066A6-E777-4D86-B7A3-A0FAF4017063@gmx.de> Hi, is it ok to optimize for-each-loop code generation for instances of java.util.List that also implement java.util.RandomAccess by expanding to List lst$ = listexpr; int len$ = lst$.size(); for (int i$ = 0 ; i$ < len$ ; i$++) { T loopvar = lst$.get(i$); } I am not sure whether this would break existing code, that relies on Iterator. RandomAccess declares that access using size()+get(int) are faster than using an iterator. The necessary modifications to com.sun.tools.javac.comp.Lower#visitForeachLoop may look like this: /** Translate away the foreach loop. */ public void visitForeachLoop(JCEnhancedForLoop tree) { if (types.elemtype(tree.expr.type) == null) { if (tree.var.vartype.type.contains(syms.listType) && tree.var.vartype.type.contains(syms.randomAccessType)) visitRandomAccessListLoop(tree); else visitIterableForeachLoop(tree); } else visitArrayForeachLoop(tree); } // where /** * A statement of the form * * 

         *     for ( T v : listexpr ) stmt;
         *
* * (where listexpr is of an randomaccess-list type) gets translated to * * 
{@code
         *     for ( { listtype #lst = listexpr;
         *             int #len = lst.size();
         *             int #i = 0; };
         *           #i < #len; i$++ ) {
         *         T v = lst$.get(#i);
         *         stmt;
         *     }
         * }
* * where #arr, #len, and #i are freshly named synthetic local variables. */ private void visitRandomAccessListLoop(JCEnhancedForLoop tree) { make_at(tree.expr.pos()); VarSymbol listcache = new VarSymbol(SYNTHETIC, names.fromString("lst" + target.syntheticNameChar()), tree.expr.type, currentMethodSym); JCStatement listcachedef = make.VarDef(listcache, tree.expr); VarSymbol lencache = new VarSymbol(SYNTHETIC, names.fromString("len" + target.syntheticNameChar()), syms.intType, currentMethodSym); Symbol size = lookupMethod(tree.expr.pos(), names.size, tree.expr.type, List.nil()); Symbol get = lookupMethod(tree.expr.pos(), names.get, tree.expr.type, List.nil()); JCStatement lencachedef = make. VarDef(lencache, make.App(make.Select(make.Ident(listcache), size))); VarSymbol index = new VarSymbol(SYNTHETIC, names.fromString("i" + target.syntheticNameChar()), syms.intType, currentMethodSym); JCVariableDecl indexdef = make.VarDef(index, make.Literal(INT, 0)); indexdef.init.type = indexdef.type = syms.intType.constType(0); List loopinit = List.of(listcachedef, lencachedef, indexdef); JCBinary cond = makeBinary(LT, make.Ident(index), make.Ident(lencache)); JCExpressionStatement step = make.Exec(makeUnary(PREINC, make.Ident(index))); Type elemtype = types.elemtype(tree.expr.type); JCExpression loopvarinit = make.App(make.Select(make.Ident(listcache), get), List.of(make.Ident(indexdef))); JCVariableDecl loopvardef = (JCVariableDecl)make.VarDef(tree.var.mods, tree.var.name, tree.var.vartype, loopvarinit).setType(tree.var.type); loopvardef.sym = tree.var.sym; JCBlock body = make. Block(0, List.of(loopvardef, tree.body)); result = translate(make. ForLoop(loopinit, cond, List.of(step), body)); patchTargets(body, tree, result); } From snazy at gmx.de Thu Nov 7 00:19:19 2013 From: snazy at gmx.de (Robert Stupp) Date: Thu, 7 Nov 2013 01:19:19 +0100 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: References: Message-ID: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> Hi, the current implementation of java.util.UUID.fromName() and java.util.UUID.toString() unnecessarily produce a lot of temporary objects. Especially the fromName() method creates some instances of java.lang.Long and indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString() creates at least 10 String objects plus the implicitly created char[] instances. Here's a hg diff which reduces the temporary object count while still providing the same functionality. - Robert diff --git a/src/share/classes/java/util/UUID.java b/src/share/classes/java/util/UUID.java --- a/src/share/classes/java/util/UUID.java +++ b/src/share/classes/java/util/UUID.java @@ -189,23 +189,68 @@ * */ public static UUID fromString(String name) { - String[] components = name.split("-"); - if (components.length != 5) + if (name.length() != 36) throw new IllegalArgumentException("Invalid UUID string: "+name); - for (int i=0; i<5; i++) - components[i] = "0x"+components[i]; - long mostSigBits = Long.decode(components[0]).longValue(); - mostSigBits <<= 16; - mostSigBits |= Long.decode(components[1]).longValue(); - mostSigBits <<= 16; - mostSigBits |= Long.decode(components[2]).longValue(); + long lo; + long hi; + lo = hi = 0; - long leastSigBits = Long.decode(components[3]).longValue(); - leastSigBits <<= 48; - leastSigBits |= Long.decode(components[4]).longValue(); + for (int i = 0, j = 0; i < 36; ++j) { + // Need to bypass hyphens: - return new UUID(mostSigBits, leastSigBits); + switch (i) { + case 8: + case 13: + case 18: + case 23: + if (name.charAt(i) != '-') + throw new IllegalArgumentException("Invalid UUID string: "+name); + + ++i; + } // switch + + int curr; + char c = name.charAt(i); + + if (c >= '0' && c <= '9') + curr = (c - '0'); + + else if (c >= 'a' && c <= 'f') + curr = (c - 'a' + 10); + + else if (c >= 'A' && c <= 'F') + curr = (c - 'A' + 10); + + else + throw new IllegalArgumentException("Invalid UUID string: "+name); + + curr <<= 4; + + c = name.charAt(++i); + + if (c >= '0' && c <= '9') + curr |= (c - '0'); + + else if (c >= 'a' && c <= 'f') + curr |= (c - 'a' + 10); + + else if (c >= 'A' && c <= 'F') + curr |= (c - 'A' + 10); + + else + throw new IllegalArgumentException("Invalid UUID string: "+name); + + if (j < 8) + hi = (hi << 8) | curr; + + else + lo = (lo << 8) | curr; + + ++i; + } // for + + return new UUID(hi, lo); } // Field Accessor Methods @@ -373,17 +418,27 @@ * @return A string representation of this {@code UUID} */ public String toString() { - return (digits(mostSigBits >> 32, 8) + "-" + - digits(mostSigBits >> 16, 4) + "-" + - digits(mostSigBits, 4) + "-" + - digits(leastSigBits >> 48, 4) + "-" + - digits(leastSigBits, 12)); + char[] arr = new char[36]; + arr[8] = arr[13] = arr[18] = arr[23] = '-'; + long msb = mostSigBits; + long lsb = leastSigBits; + // upper 32 bit of MSB + digits(msb >> 32, 8, arr, 0); + // upper 16 bit of lower 32 bit of MSB + digits(msb >> 16, 4, arr, 9); + // lower 16 bit of lower 32 bit of MSB + digits(msb, 4, arr, 14); + // upper 16 bit of LSB + digits(lsb, 4, arr, 19); + // lower 48 bit of LSB + digits(lsb, 12, arr, 24); + return new String(arr); } - /** Returns val represented by the specified number of hex digits. */ - private static String digits(long val, int digits) { - long hi = 1L << (digits * 4); - return Long.toHexString(hi | (val & (hi - 1))).substring(1); + private static final char[] HEX = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'}; + private void digits(long v, int digits, char[] arr, int off) { + for ( ; digits > 0 ; off++ ) + arr[off] = HEX[ (int)(v&15) ]; } /** From stevenschlansker at gmail.com Mon Nov 11 18:39:38 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 11 Nov 2013 10:39:38 -0800 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> References: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> Message-ID: On Nov 6, 2013, at 4:19 PM, Robert Stupp wrote: > Hi, > > the current implementation of java.util.UUID.fromName() and java.util.UUID.toString() unnecessarily produce a lot of temporary objects. Especially the fromName() method creates some instances of java.lang.Long and indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString() creates at least 10 String objects plus the implicitly created char[] instances. > > Here's a hg diff which reduces the temporary object count while still providing the same functionality. > Hi Robert, I identified the same problem and submitted a patch earlier this year: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013494.html http://osdir.com/ml/core-libs-dev/2013-03/msg00403.html Sorry I don?t have the best list message references here, Oracle seems to have decided to break all the links through the old Sun bug database, so all my references are gone. Bummer. :( It?s currently living at CR 8006627 and CR 8007398, although I?m having real trouble finding a public link to the bugs. Last I heard, Mike (CCed) has this in a patch queue somewhere waiting to commit it. Maybe he will take the good parts from my patch and the good parts from your patch and make an even better patch :) Regards, Steven Schlansker From rieberandreas at gmail.com Mon Nov 11 18:55:26 2013 From: rieberandreas at gmail.com (Andreas Rieber) Date: Mon, 11 Nov 2013 19:55:26 +0100 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: References: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> Message-ID: <5281281E.3010306@gmail.com> On 11.11.2013 19:39, Steven Schlansker wrote: > On Nov 6, 2013, at 4:19 PM, Robert Stupp wrote: > >> Hi, >> >> the current implementation of java.util.UUID.fromName() and java.util.UUID.toString() unnecessarily produce a lot of temporary objects. Especially the fromName() method creates some instances of java.lang.Long and indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString() creates at least 10 String objects plus the implicitly created char[] instances. >> >> Here's a hg diff which reduces the temporary object count while still providing the same functionality. >> > > Hi Robert, > > I identified the same problem and submitted a patch earlier this year: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013494.html > http://osdir.com/ml/core-libs-dev/2013-03/msg00403.html > > Sorry I don?t have the best list message references here, Oracle seems to have decided to break all the links through the old Sun bug database, so all my references are gone. Bummer. :( > > It?s currently living at CR 8006627 and CR 8007398, although I?m having real trouble finding a public link to the bugs. With the new JBS its so easy to find: https://bugs.openjdk.java.net/browse/JDK-8006627 cheers Andreas > > Last I heard, Mike (CCed) has this in a patch queue somewhere waiting to commit it. Maybe he will take the good parts from my patch and the good parts from your patch and make an even better patch :) > > Regards, > Steven Schlansker > From tom.hawtin at oracle.com Mon Nov 11 19:01:34 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 11 Nov 2013 19:01:34 +0000 Subject: shared "value" in java.lang.StringBuilder In-Reply-To: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> References: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> Message-ID: <5281298E.6040508@oracle.com> On 06/11/2013 21:54, Robert Stupp wrote: > Wouldn't it worth to try whether passing the > (Abstract)StringBuilder's value+count values to String results in > less temporary object creations and therefore reduce pressure on new > generation (and reduce GC effort)? My idea is to add a field 'shared' > to AbstractStringBuilder, Unfortunately that would result in mutable Strings. You also end up with overly long Strings, with the extra never getting collected. Even StringBuffer with its synchronisation overhead was problematic. In any case, the current String drops the offset and length fields for faster implementation that uses less memory (if only we could merge the char[] into the main object). Tom From lance.andersen at oracle.com Mon Nov 11 19:01:11 2013 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 Nov 2013 14:01:11 -0500 Subject: Request for review: 8028149, clean up javac -Xlint errors com.sun.rowset.* Message-ID: <6BA2DD9E-2277-440F-A9EA-19CA00ED451E@oracle.com> Hi, Need a reviewer to close down these two lint warning in com.sun.rowset.* $ serialver com.sun.rowset.internal.BaseRow com.sun.rowset.internal.BaseRow: static final long serialVersionUID = 4152013523511412238L; $ hg status -ma M src/share/classes/com/sun/rowset/CachedRowSetImpl.java M src/share/classes/com/sun/rowset/internal/BaseRow.java ljanders-mac:rowset ljanders$ hg diff diff -r cb8946eda85b src/share/classes/com/sun/rowset/CachedRowSetImpl.java --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Oct 02 19:13:42 2013 -0400 +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Mon Nov 11 13:46:47 2013 -0500 @@ -541,7 +541,7 @@ if (rowSetWriter != null) { Class c = rowSetWriter.getClass(); if (c != null) { - Class[] theInterfaces = c.getInterfaces(); + Class[] theInterfaces = c.getInterfaces(); for (int i = 0; i < theInterfaces.length; i++) { if ((theInterfaces[i].getName()).indexOf("TransactionalWriter") > 0) { tXWriter = true; diff -r cb8946eda85b src/share/classes/com/sun/rowset/internal/BaseRow.java --- a/src/share/classes/com/sun/rowset/internal/BaseRow.java Wed Oct 02 19:13:42 2013 -0400 +++ b/src/share/classes/com/sun/rowset/internal/BaseRow.java Mon Nov 11 13:46:47 2013 -0500 @@ -52,6 +52,11 @@ public abstract class BaseRow implements Serializable, Cloneable { /** + * Specify the serialVersionUID + */ +private static final long serialVersionUID = 4152013523511412238L; + +/** * The array containing the original values for this BaseRow * object. * @serial @@ -77,7 +82,7 @@ * @param idx the index of the element to return * @return the Object value at the given index into this * row's array of original values - * @throws SQLException if there is an error + * @throws SQLException if there is an error */ public abstract Object getColumnObject(int idx) throws SQLException; @@ -90,7 +95,7 @@ * @param idx the index of the element to be set * @param obj the Object to which the element at index * idx to be set - * @throws SQLException if there is an error + * @throws SQLException if there is an error */ public abstract void setColumnObject(int idx, Object obj) throws SQLException; } From joe.darcy at oracle.com Mon Nov 11 19:07:28 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 11 Nov 2013 11:07:28 -0800 Subject: Request for review: 8028149, clean up javac -Xlint errors com.sun.rowset.* In-Reply-To: <6BA2DD9E-2277-440F-A9EA-19CA00ED451E@oracle.com> References: <6BA2DD9E-2277-440F-A9EA-19CA00ED451E@oracle.com> Message-ID: <52812AF0.1060102@oracle.com> Hi Lance, Approved! Thanks, -Joe On 11/11/2013 11:01 AM, Lance Andersen wrote: > Hi, > > Need a reviewer to close down these two lint warning in com.sun.rowset.* > > $ serialver com.sun.rowset.internal.BaseRow > com.sun.rowset.internal.BaseRow: static final long serialVersionUID = 4152013523511412238L; > > $ hg status -ma > M src/share/classes/com/sun/rowset/CachedRowSetImpl.java > M src/share/classes/com/sun/rowset/internal/BaseRow.java > ljanders-mac:rowset ljanders$ hg diff > diff -r cb8946eda85b src/share/classes/com/sun/rowset/CachedRowSetImpl.java > --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Wed Oct 02 19:13:42 2013 -0400 > +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Mon Nov 11 13:46:47 2013 -0500 > @@ -541,7 +541,7 @@ > if (rowSetWriter != null) { > Class c = rowSetWriter.getClass(); > if (c != null) { > - Class[] theInterfaces = c.getInterfaces(); > + Class[] theInterfaces = c.getInterfaces(); > for (int i = 0; i < theInterfaces.length; i++) { > if ((theInterfaces[i].getName()).indexOf("TransactionalWriter") > 0) { > tXWriter = true; > diff -r cb8946eda85b src/share/classes/com/sun/rowset/internal/BaseRow.java > --- a/src/share/classes/com/sun/rowset/internal/BaseRow.java Wed Oct 02 19:13:42 2013 -0400 > +++ b/src/share/classes/com/sun/rowset/internal/BaseRow.java Mon Nov 11 13:46:47 2013 -0500 > @@ -52,6 +52,11 @@ > public abstract class BaseRow implements Serializable, Cloneable { > > /** > + * Specify the serialVersionUID > + */ > +private static final long serialVersionUID = 4152013523511412238L; > + > +/** > * The array containing the original values for this BaseRow > * object. > * @serial > @@ -77,7 +82,7 @@ > * @param idx the index of the element to return > * @return the Object value at the given index into this > * row's array of original values > - * @throws SQLException if there is an error > + * @throws SQLException if there is an error > */ > public abstract Object getColumnObject(int idx) throws SQLException; > > @@ -90,7 +95,7 @@ > * @param idx the index of the element to be set > * @param obj the Object to which the element at index > * idx to be set > - * @throws SQLException if there is an error > + * @throws SQLException if there is an error > */ > public abstract void setColumnObject(int idx, Object obj) throws SQLException; > } From lance.andersen at oracle.com Mon Nov 11 19:22:50 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 11 Nov 2013 19:22:50 +0000 Subject: hg: jdk8/tl/jdk: 8028149: Clean-up javac -Xlint warnings in com.sun.rowset and com.sun.rowset.internal Message-ID: <20131111192304.9BEBB62502@hg.openjdk.java.net> Changeset: 59ff7957c26f Author: lancea Date: 2013-11-11 14:22 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59ff7957c26f 8028149: Clean-up javac -Xlint warnings in com.sun.rowset and com.sun.rowset.internal Reviewed-by: darcy ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java From stevenschlansker at gmail.com Mon Nov 11 19:28:02 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 11 Nov 2013 11:28:02 -0800 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: <5281281E.3010306@gmail.com> References: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> <5281281E.3010306@gmail.com> Message-ID: <1DA4FF77-E1BD-4766-B6AD-3D3C04CF57E5@gmail.com> On Nov 11, 2013, at 10:55 AM, Andreas Rieber wrote: > On 11.11.2013 19:39, Steven Schlansker wrote: >> Sorry I don?t have the best list message references here, Oracle seems to have decided to break all the links through the old Sun bug database, so all my references are gone. Bummer. :( >> >> It?s currently living at CR 8006627 and CR 8007398, although I?m having real trouble finding a public link to the bugs. > > With the new JBS its so easy to find: > > https://bugs.openjdk.java.net/browse/JDK-8006627 Thanks, Andreas! That?s great! It?s worth noting that doing a search for any of "jdk-8006627?, ?jdk 8006627?, ?8006627?, ?cr 8006627? show no Google or DuckDuckGo results pointing to this page, they all dead end at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006627 Maybe someone has a robots.txt file that bans crawlers from finding the bugs. Not sure if this can / should be reported or to who... From Alan.Bateman at oracle.com Mon Nov 11 20:30:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Nov 2013 20:30:14 +0000 Subject: shared "value" in java.lang.StringBuilder In-Reply-To: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> References: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> Message-ID: <52813E56.4080202@oracle.com> On 06/11/2013 21:54, Robert Stupp wrote: > Hi, > > I was wondering why the mostly allocated class in nearly all applications is char[]. A deeper inspection showed that a lot of these char[] allocations are "caused" by the code from java.lang.StringBuilder.toString(), which created a copy of its internal char array. Most StringBuilder instances are no longer used after the call to StringBuilder.toString(). Many of these instances have been created by javac caused by "plain" string concatenation in source code. > > Wouldn't it worth to try whether passing the (Abstract)StringBuilder's value+count values to String results in less temporary object creations and therefore reduce pressure on new generation (and reduce GC effort)? My idea is to add a field 'shared' to AbstractStringBuilder, which is set when StringBuilder.toString() is called. If the StringBuilder is really modified after calling toString(), the StringBuilder creates a new copy of the value array and resets the 'shared' field. Since the value array might be longer than the current count, String class would need a "re-invention" of the count field. > > Another think I noticed is that the StringBuilder instances transiently created by javac seem to use the default constructor. But a huge amount of string concatenations in Java code result in (much) longer Strings, which means that each append creates a new, larger copy of the value array in AbstractStringBuilder. Is it possible to add some "guessing" for the initial capacity - this would eliminate a lot of temporary objects and reduce GC effort. Is it worth to check this out? Are the two places in com.sun.tools.javac.jvm.Gen#visitAssignop/visitBinary the only places where these StringBuilder instances are created? > > - > Robert I can't speak to the details but HotSpot has an optimization that recognizes some cases like new-StringBuilder(...).append(...).append(...).toString() where it can avoid the copy. This may be something to follow-up on the hotspot list if you want to get into the details. -Alan. From Alan.Bateman at oracle.com Mon Nov 11 20:32:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Nov 2013 20:32:11 +0000 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> References: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> Message-ID: <52813ECB.6050602@oracle.com> On 07/11/2013 00:19, Robert Stupp wrote: > Hi, > > the current implementation of java.util.UUID.fromName() and java.util.UUID.toString() unnecessarily produce a lot of temporary objects. Especially the fromName() method creates some instances of java.lang.Long and indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString() creates at least 10 String objects plus the implicitly created char[] instances. > > Here's a hg diff which reduces the temporary object count while still providing the same functionality. > > - > Robert > I see others have replied to point out the existing bug tracking this and also the patches that have been proposed in this area. One other thing to mention is the "How to contribute" page [1] in case you haven't read it. -Alan [1] http://openjdk.java.net/contribute/ From Alan.Bateman at oracle.com Mon Nov 11 20:33:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Nov 2013 20:33:56 +0000 Subject: Please help - OSX 10.9 build fails In-Reply-To: <2D39CE59-C5E8-4B26-B679-6A10F0400338@gmx.de> References: <2D39CE59-C5E8-4B26-B679-6A10F0400338@gmx.de> Message-ID: <52813F34.7090100@oracle.com> On 06/11/2013 21:14, Robert Stupp wrote: > Hi, > > I'm trying to build openjdk8 on OSX 10.9 but it fails. > This may be something to bring up on the build-dev list, I think there was a bit of discussion recently on this list about Xcode 5 and clang. -Alan. From staffan.larsen at oracle.com Mon Nov 11 20:17:23 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 11 Nov 2013 20:17:23 +0000 Subject: hg: jdk8/tl/jdk: 8014506: Test of Jdp feature Message-ID: <20131111201735.59C2462503@hg.openjdk.java.net> Changeset: 0cacac7f5c37 Author: sla Date: 2013-11-08 18:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cacac7f5c37 8014506: Test of Jdp feature Reviewed-by: sla Contributed-by: Alex Schenkman + test/sun/management/jdp/ClientConnection.java + test/sun/management/jdp/DynamicLauncher.java ! test/sun/management/jdp/JdpClient.java + test/sun/management/jdp/JdpDefaultsTest.java ! test/sun/management/jdp/JdpDoSomething.java + test/sun/management/jdp/JdpOffTest.java + test/sun/management/jdp/JdpOffTestCase.java + test/sun/management/jdp/JdpOnTestCase.java + test/sun/management/jdp/JdpSpecificAddressTest.java ! test/sun/management/jdp/JdpTest.sh + test/sun/management/jdp/JdpTestCase.java + test/sun/management/jdp/JdpTestUtil.java + test/sun/management/jdp/JdpTestUtilTest.java ! test/sun/management/jdp/JdpUnitTest.java + test/sun/management/jdp/PacketTest.java + test/sun/management/jdp/PortAlreadyInUseTest.java + test/sun/management/jdp/README From ali.ebrahimi1781 at gmail.com Mon Nov 11 21:53:52 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 12 Nov 2013 01:23:52 +0330 Subject: Signature of MethodHandleInfo.reflectAs is not specific enough In-Reply-To: <528083DF.8030004@gmail.com> References: <528008C9.7000905@univ-mlv.fr> <528083DF.8030004@gmail.com> Message-ID: Hi, I know this is not fully type safe, in fact java generics is not fully type safe. We don't have any better solution with current language support. if we had: or we had better solutions: public T reflectAs(Class expected, Lookup lookup) public R reflectAs(Class expected, Lookup lookup) but we don't have such support in language. But I think there is another solution that require change in j.l.r API Make Member an AnnotatedElement interface Member implements AnnotatedElement { ...} and public T reflectAs(Class expected, Lookup lookup) On Mon, Nov 11, 2013 at 10:44 AM, Peter Levart wrote: > On 11/11/2013 02:24 AM, Ali Ebrahimi wrote: > > This is another workaround: > > public R reflectAs(Class > expected, Lookup lookup); > > info.reflectAs(Member.class, lookup);//works > info.reflectAs(AnnotatedElement.class, lookup);//works > info.reflectAs(Member.class, lookup);//works > info.reflectAs(AnnotatedElement.class, lookup);//works > > > info.reflectAs(Object.class, lookup);doesn't work. > info.reflectAs(Other.class, lookup);doesn't work. > > with this does not need to your javadoc and is more type safe. . > > > Hm... it doesn't look very compile-time type-safe: > > String s = info.reflectAs(Method.class, lookup); // compiles !!! > > > IMO, I would rather remove the Class parameter altogether. It serves no > purpose in the method implementation other than to perform a cast-check on > the returned object. The method could simply be: > > public T reflect(Lookup lookup); > > This would not solve the problem Remi put forward. I.e. this would not > compile: > > AnnotatedElement ae = info.reflect(lookup); > > But with an explicit cast, It compiles: > > AnnotatedElement ae = (AnnotatedElement) info.reflect(lookup); > > And compared to what we would have with Class parameter and loosened > compile-time type-safety as per Remi's suggestion, it is still shorter: > > AnnotatedElement ae = info.reflectAs(AnnotatedElement.class, lookup); > // this is longer! > > A type-unsafe variant is possible too (I'm not advocating it): > > public T reflect(Lookup lookup); > > Now that Generalized Target-Type Inferenceis part of Java 8, using Class parameters just as hints to the compiler > is not needed in many cases. But if one needs to hint the compiler, > explicit type parameters can be used as an escape hatch as always: > > Object o = info.reflect(lookup); > > > Regards, Peter > > > > > > > On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax wrote: > >> The is a stupid issue with the signature of MethodHandleInfo.reflectAs, >> j.l.r.Field, Method or Constructor implement two interfaces Member and >> AnnotatedElement, with the current signature, the code >> info.reflectAs(Member.class, lookup) >> works but the code >> info.reflectAs(AnnotatedElement.class, lookup) >> doesn't work. >> >> Because there is no way to do an 'or' between several bounds of >> a type variable, I think that the signature of reflectAs should be >> changed from : >> public T reflectAs(Class expected, Lookup >> lookup); >> to >> public T reflectAs(Class expected, Lookup lookup); >> >> and the javadoc should be modified to explain that a Member or >> AnnotatedElement are >> valid bounds of T. >> >> As a side effect, the signature of MethodHandles.reflectAs(Class, >> MethodHandle) >> should be updated accordingly. >> >> There is a workaround, one can write: >> (AnnotatedElement)info.reflectAs(Member.class, lookup) >> but it's at best weird. >> >> cheers, >> R?mi >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > > > _______________________________________________ > mlvm-dev mailing listmlvm-dev at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > From xueming.shen at oracle.com Mon Nov 11 22:05:53 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 11 Nov 2013 14:05:53 -0800 Subject: RFR: JDK-8027645: Pattern.split() with positive lookahead In-Reply-To: <527BE318.3050007@oracle.com> References: <527BE318.3050007@oracle.com> Message-ID: <528154C1.1030203@oracle.com> Alan, Paul, My apology, it appears I forgot my "fastpath" in String.split(String, int) and the fact that it also duplicates most of the spec of Pattern.split(). The webrev has been updated to close the loophole. http://cr.openjdk.java.net/~sherman/8027645/webrev thanks! -Sherman On 11/07/2013 10:59 AM, Xueming Shen wrote: > Hi, > > As suggested in the bug report [1] the spec of j.u.Pattern.split() > does not clearly specify what the expected behavior should be for scenario > like a zero-width match is found at the beginning of the input string > (such as whether or not an empty leading string should be included into > the resulting array), worse, the implementation is not consistent as well > (for different input cases, such as "Abc".split(...) vs "AbcEfg".split(...)). > > The spec also is not clear regarding what the expected behavior should be > if the size of the input string is 0 [2]. > > As a reference, Perl.split() function has clear/explicit spec regarding > above use scenario [3]. > > So the proposed change here is to updatethe spec&impl of Pattern.split() to have > clear specification for above use scanrio, as Perl does > > (1) A zero-length input sequence always results zero-length resulting array > (instead of returning a string[] only contains an empty string) > (2) An empty leading substring is included at the beginning of the resulting > array, when there is a positive-width match at the beginning of the input > sequence. A zero-width match at the beginning however never produces such > empty leading substring. > > webrev: > http://cr.openjdk.java.net/~sherman/8027645/webrev/ > > Thanks! > -Sherman > > [1] https://bugs.openjdk.java.net/browse/JDK-8027645 > [2] https://bugs.openjdk.java.net/browse/JDK-6559590 > [3] http://perldoc.perl.org/functions/split.html > > btw:the following perl script is used to verify the perl behavior > ------------------ > $str = "AbcEfgHij"; > @substr = split(/(?=\p{Uppercase})/, $str); > #$str = "abc efg hij"; > #@substr = split(/ /, $str); > print "split[sz=", scalar @substr, "]=[", join(",", @substr), "]\n"; > ------------------ From brian.goetz at oracle.com Mon Nov 11 22:14:11 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 11 Nov 2013 23:14:11 +0100 Subject: shared "value" in java.lang.StringBuilder In-Reply-To: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> References: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> Message-ID: I believe a long time ago it used to work this way; there was a private "handoff" constructor in String that StringBuffer would use. Probably got changed when we added StringBuilder? On Nov 6, 2013, at 10:54 PM, Robert Stupp wrote: > Hi, > > I was wondering why the mostly allocated class in nearly all applications is char[]. A deeper inspection showed that a lot of these char[] allocations are "caused" by the code from java.lang.StringBuilder.toString(), which created a copy of its internal char array. Most StringBuilder instances are no longer used after the call to StringBuilder.toString(). Many of these instances have been created by javac caused by "plain" string concatenation in source code. > > Wouldn't it worth to try whether passing the (Abstract)StringBuilder's value+count values to String results in less temporary object creations and therefore reduce pressure on new generation (and reduce GC effort)? My idea is to add a field 'shared' to AbstractStringBuilder, which is set when StringBuilder.toString() is called. If the StringBuilder is really modified after calling toString(), the StringBuilder creates a new copy of the value array and resets the 'shared' field. Since the value array might be longer than the current count, String class would need a "re-invention" of the count field. > > Another think I noticed is that the StringBuilder instances transiently created by javac seem to use the default constructor. But a huge amount of string concatenations in Java code result in (much) longer Strings, which means that each append creates a new, larger copy of the value array in AbstractStringBuilder. Is it possible to add some "guessing" for the initial capacity - this would eliminate a lot of temporary objects and reduce GC effort. Is it worth to check this out? Are the two places in com.sun.tools.javac.jvm.Gen#visitAssignop/visitBinary the only places where these StringBuilder instances are created? > > - > Robert > From xueming.shen at oracle.com Mon Nov 11 22:41:14 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 11 Nov 2013 22:41:14 +0000 Subject: hg: jdk8/tl/jdk: 8026330: java.util.Base64 urlEncoder should omit padding Message-ID: <20131111224131.E205562510@hg.openjdk.java.net> Changeset: 8e8e423fa3dc Author: sherman Date: 2013-11-11 14:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e8e423fa3dc 8026330: java.util.Base64 urlEncoder should omit padding Summary: to add Encoder.withoutPadding() Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From robert.field at oracle.com Tue Nov 12 00:14:35 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 12 Nov 2013 00:14:35 +0000 Subject: hg: jdk8/tl/jdk: 8027803: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails Message-ID: <20131112001448.1A5AD62519@hg.openjdk.java.net> Changeset: c04e46dbfea8 Author: rfield Date: 2013-11-11 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c04e46dbfea8 8027803: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails Summary: fix NPE in test infrastructure Reviewed-by: ksrini, jfranck, alanb, rfield Contributed-by: alan.bateman at oracle.com ! test/lib/testlibrary/ClassFileInstaller.java From vitalyd at gmail.com Tue Nov 12 01:08:02 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 11 Nov 2013 20:08:02 -0500 Subject: javac: optimized for-each over RandomAccess List In-Reply-To: <164066A6-E777-4D86-B7A3-A0FAF4017063@gmx.de> References: <164066A6-E777-4D86-B7A3-A0FAF4017063@gmx.de> Message-ID: You'd lose the concurrent mod checking that the iterator may do, which would change behavior. Vitaly Sent from my phone On Nov 11, 2013 1:12 PM, "Robert Stupp" wrote: > Hi, > > is it ok to optimize for-each-loop code generation for instances of > java.util.List that also implement java.util.RandomAccess by expanding to > List lst$ = listexpr; > int len$ = lst$.size(); > for (int i$ = 0 ; i$ < len$ ; i$++) { > T loopvar = lst$.get(i$); > > } > > I am not sure whether this would break existing code, that relies on > Iterator. RandomAccess declares that access using size()+get(int) are > faster than using an iterator. > > The necessary modifications to > com.sun.tools.javac.comp.Lower#visitForeachLoop may look like this: > > /** Translate away the foreach loop. */ > public void visitForeachLoop(JCEnhancedForLoop tree) { > if (types.elemtype(tree.expr.type) == null) { > if (tree.var.vartype.type.contains(syms.listType) && > tree.var.vartype.type.contains(syms.randomAccessType)) > visitRandomAccessListLoop(tree); > else > visitIterableForeachLoop(tree); > } > else > visitArrayForeachLoop(tree); > } > // where > /** > * A statement of the form > * > * 
>          *     for ( T v : listexpr ) stmt;
>          *
> * > * (where listexpr is of an randomaccess-list type) gets > translated to > * > * 
{@code
>          *     for ( { listtype #lst = listexpr;
>          *             int #len = lst.size();
>          *             int #i = 0; };
>          *           #i < #len; i$++ ) {
>          *         T v = lst$.get(#i);
>          *         stmt;
>          *     }
>          * }
> * > * where #arr, #len, and #i are freshly named synthetic local > variables. > */ > private void visitRandomAccessListLoop(JCEnhancedForLoop tree) { > make_at(tree.expr.pos()); > VarSymbol listcache = new VarSymbol(SYNTHETIC, > names.fromString("lst" + target.syntheticNameChar()), > tree.expr.type, > currentMethodSym); > JCStatement listcachedef = make.VarDef(listcache, tree.expr); > VarSymbol lencache = new VarSymbol(SYNTHETIC, > names.fromString("len" + target.syntheticNameChar()), > syms.intType, > currentMethodSym); > Symbol size = lookupMethod(tree.expr.pos(), > names.size, > tree.expr.type, > List.nil()); > Symbol get = lookupMethod(tree.expr.pos(), > names.get, > tree.expr.type, > List.nil()); > JCStatement lencachedef = make. > VarDef(lencache, > make.App(make.Select(make.Ident(listcache), > size))); > VarSymbol index = new VarSymbol(SYNTHETIC, > names.fromString("i" + target.syntheticNameChar()), > syms.intType, > currentMethodSym); > > JCVariableDecl indexdef = make.VarDef(index, make.Literal(INT, > 0)); > indexdef.init.type = indexdef.type = syms.intType.constType(0); > > List loopinit = List.of(listcachedef, > lencachedef, indexdef); > JCBinary cond = makeBinary(LT, make.Ident(index), > make.Ident(lencache)); > > JCExpressionStatement step = make.Exec(makeUnary(PREINC, > make.Ident(index))); > > Type elemtype = types.elemtype(tree.expr.type); > JCExpression loopvarinit = > make.App(make.Select(make.Ident(listcache), get), > List.of(make.Ident(indexdef))); > JCVariableDecl loopvardef = > (JCVariableDecl)make.VarDef(tree.var.mods, > tree.var.name, > tree.var.vartype, > loopvarinit).setType(tree.var.type); > loopvardef.sym = tree.var.sym; > JCBlock body = make. > Block(0, List.of(loopvardef, tree.body)); > > result = translate(make. > ForLoop(loopinit, > cond, > List.of(step), > body)); > patchTargets(body, tree, result); > } > > From john.r.rose at oracle.com Tue Nov 12 04:14:01 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Nov 2013 20:14:01 -0800 Subject: shared "value" in java.lang.StringBuilder In-Reply-To: References: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> Message-ID: On Nov 11, 2013, at 2:14 PM, Brian Goetz wrote: > I believe a long time ago it used to work this way; there was a private "handoff" constructor in String that StringBuffer would use. Probably got changed when we added StringBuilder? As you might expect, we've been exploring this territory for a long time. Since 1.4.2 circa 2003, StringBuffer had a boolean field called (wait for it...) "shared" with a package-private constructor in String. That was the aboriginal form of the String class. IIRC, we got rid of it because (a) there was no foolproof way to right-size the shared buffer array, and (b) it is better on modern systems to co-locate the string header and body. Some sort of "chop" operator for right-sizing (which would be unsafe and/or hard to implement) could also address (a), but in the long run memory locality wins over almost everything. I think the next interesting version of String will mix header and body together in a hybrid layout, with private char (or byte) elements and a few instance variables at the beginning of the layout. For good measure, it should deprecate or disallow object identity operations, so that equivalent strings can be shared by the JVM, even after creation. Those changes will require difficult JVM cuts, which is why we haven't done it yet, except in some research projects. ? John > On Nov 6, 2013, at 10:54 PM, Robert Stupp wrote: > >> Hi, >> >> I was wondering why the mostly allocated class in nearly all applications is char[]. A deeper inspection showed that a lot of these char[] allocations are "caused" by the code from java.lang.StringBuilder.toString(), which created a copy of its internal char array. Most StringBuilder instances are no longer used after the call to StringBuilder.toString(). Many of these instances have been created by javac caused by "plain" string concatenation in source code. >> >> Wouldn't it worth to try whether passing the (Abstract)StringBuilder's value+count values to String results in less temporary object creations and therefore reduce pressure on new generation (and reduce GC effort)? My idea is to add a field 'shared' to AbstractStringBuilder, which is set when StringBuilder.toString() is called. If the StringBuilder is really modified after calling toString(), the StringBuilder creates a new copy of the value array and resets the 'shared' field. Since the value array might be longer than the current count, String class would need a "re-invention" of the count field. >> >> Another think I noticed is that the StringBuilder instances transiently created by javac seem to use the default constructor. But a huge amount of string concatenations in Java code result in (much) longer Strings, which means that each append creates a new, larger copy of the value array in AbstractStringBuilder. Is it possible to add some "guessing" for the initial capacity - this would eliminate a lot of temporary objects and reduce GC effort. Is it worth to check this out? Are the two places in com.sun.tools.javac.jvm.Gen#visitAssignop/visitBinary the only places where these StringBuilder instances are created? >> >> - >> Robert >> > From john.r.rose at oracle.com Tue Nov 12 04:34:34 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 12 Nov 2013 04:34:34 +0000 Subject: hg: jdk8/tl/jdk: 8027823: catchException combinator fails with 9 argument target Message-ID: <20131112043449.1415862520@hg.openjdk.java.net> Changeset: 9fcb07df1c92 Author: vlivanov Date: 2013-11-09 04:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fcb07df1c92 8027823: catchException combinator fails with 9 argument target Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + test/java/lang/invoke/MethodHandles/TestCatchException.java From jeroen at sumatra.nl Tue Nov 12 07:33:39 2013 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Tue, 12 Nov 2013 07:33:39 +0000 Subject: shared "value" in java.lang.StringBuilder In-Reply-To: References: <338627D9-0DFD-49FB-A961-12C42C61FF2E@gmx.de> Message-ID: <66c36d6f3c1c4dc1949ec53a920850ef@mane.sumatrasoftware.com> John Rose wrote: > I think the next interesting version of String will mix header and body > together in a hybrid layout, with private char (or byte) elements and a > few instance variables at the beginning of the layout. It would be good to prepare for this by modifying the JNI spec to explicitly disallow AllocObject (and subsequent constructor invocations) on String. Regards, Jeroen From alexyursha at gmail.com Tue Nov 12 08:43:50 2013 From: alexyursha at gmail.com (Alex Yursha) Date: Tue, 12 Nov 2013 11:43:50 +0300 Subject: Optimization of java.io.DataInputStream Message-ID: The following methods in java.io.DataInputStream perform right shift to zero positions in their implementations: - short readShort() - int readUnsignedShort() - char readChar() - int readInt() - long readLong() - String readUTF(DataInput in) For example: public final short readShort() throws IOException { int ch1 = in.read(); int ch2 = in.read(); if ((ch1 | ch2) < 0) throw new EOFException(); return (short)((ch1 << 8) + *(ch2 << 0)*); } It can be optimizied as follows: public final short readShort() throws IOException { int ch1 = in.read(); int ch2 = in.read(); if ((ch1 | ch2) < 0) throw new EOFException(); return (short)((ch1 << 8) + *ch2*); } This optimization saves 2 bytecode instructions in the class file code arrays of each method mentioned above. From sundararajan.athijegannathan at oracle.com Tue Nov 12 08:47:45 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 12 Nov 2013 08:47:45 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20131112084747.6305262530@hg.openjdk.java.net> Changeset: e65a98146b94 Author: attila Date: 2013-11-11 14:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e65a98146b94 8028020: Function parameter as last expression in comma in return value causes bad type calculation Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8028020.js + test/script/basic/JDK-8028020.js.EXPECTED Changeset: 2f0f8d1d0753 Author: sundar Date: 2013-11-12 10:23 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2f0f8d1d0753 Merge From joe.darcy at oracle.com Tue Nov 12 09:28:20 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Nov 2013 01:28:20 -0800 Subject: JDK 8 RFR: more core libs raw warnings cleanup Message-ID: <5281F4B4.50602@oracle.com> Hello, Please review the patch below which would remove another batch of raw type javac lint warnings from the core libraries. No signatures of public or protected methods in the Java SE specification have been modified. Regression tests in affected areas pass. Thanks, -Joe diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java --- a/src/share/classes/java/io/ObjectOutputStream.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/io/ObjectOutputStream.java Tue Nov 12 00:51:15 2013 -0800 @@ -1248,7 +1248,7 @@ handles.assign(unshared ? null : desc); Class cl = desc.forClass(); - Class[] ifaces = cl.getInterfaces(); + Class[] ifaces = cl.getInterfaces(); bout.writeInt(ifaces.length); for (int i = 0; i < ifaces.length; i++) { bout.writeUTF(ifaces[i].getName()); diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java --- a/src/share/classes/java/io/ObjectStreamClass.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/io/ObjectStreamClass.java Tue Nov 12 00:51:15 2013 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1746,7 +1746,7 @@ dout.writeUTF("()V"); } - Constructor[] cons = cl.getDeclaredConstructors(); + Constructor[] cons = cl.getDeclaredConstructors(); MemberSignature[] consSigs = new MemberSignature[cons.length]; for (int i = 0; i < cons.length; i++) { consSigs[i] = new MemberSignature(cons[i]); diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java --- a/src/share/classes/java/lang/reflect/Proxy.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/lang/reflect/Proxy.java Tue Nov 12 00:51:15 2013 -0800 @@ -494,9 +494,10 @@ private final int hash; private final WeakReference>[] refs; + @SuppressWarnings({"rawtypes", "unchecked"}) KeyX(Class[] interfaces) { hash = Arrays.hashCode(interfaces); - refs = new WeakReference[interfaces.length]; + refs = (WeakReference>[])new WeakReference[interfaces.length]; for (int i = 0; i < interfaces.length; i++) { refs[i] = new WeakReference<>(interfaces[i]); } diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java --- a/src/share/classes/java/nio/file/TempFileHelper.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/nio/file/TempFileHelper.java Tue Nov 12 00:51:15 2013 -0800 @@ -81,7 +81,7 @@ String prefix, String suffix, boolean createDirectory, - FileAttribute[] attrs) + FileAttribute[] attrs) throws IOException { if (prefix == null) @@ -155,7 +155,7 @@ static Path createTempFile(Path dir, String prefix, String suffix, - FileAttribute[] attrs) + FileAttribute[] attrs) throws IOException { return create(dir, prefix, suffix, false, attrs); @@ -167,7 +167,7 @@ */ static Path createTempDirectory(Path dir, String prefix, - FileAttribute[] attrs) + FileAttribute[] attrs) throws IOException { return create(dir, prefix, null, true, attrs); diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java --- a/src/share/classes/java/util/IdentityHashMap.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/util/IdentityHashMap.java Tue Nov 12 00:51:15 2013 -0800 @@ -1243,7 +1243,7 @@ if (ti >= size) { throw new ConcurrentModificationException(); } - a[ti++] = (T) new AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]); + a[ti++] = (T) new AbstractMap.SimpleEntry<>(unmaskNull(key), tab[si + 1]); } } // fewer elements than expected or concurrent modification from other thread detected diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java --- a/src/share/classes/java/util/logging/Logger.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/util/logging/Logger.java Tue Nov 12 00:51:15 2013 -0800 @@ -351,7 +351,7 @@ ? caller.getClassLoader() : null); if (callersClassLoader != null) { - this.callersClassLoaderRef = new WeakReference(callersClassLoader); + this.callersClassLoaderRef = new WeakReference<>(callersClassLoader); } } diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logging.java --- a/src/share/classes/java/util/logging/Logging.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/java/util/logging/Logging.java Tue Nov 12 00:51:15 2013 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -55,11 +55,11 @@ } public List getLoggerNames() { - Enumeration loggers = logManager.getLoggerNames(); + Enumeration loggers = logManager.getLoggerNames(); ArrayList array = new ArrayList<>(); for (; loggers.hasMoreElements();) { - array.add((String) loggers.nextElement()); + array.add(loggers.nextElement()); } return array; } diff -r 9fcb07df1c92 src/share/classes/sun/misc/Cleaner.java --- a/src/share/classes/sun/misc/Cleaner.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/sun/misc/Cleaner.java Tue Nov 12 00:51:15 2013 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2008, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -57,14 +57,14 @@ */ public class Cleaner - extends PhantomReference + extends PhantomReference { // Dummy reference queue, needed because the PhantomReference constructor // insists that we pass a queue. Nothing will ever be placed on this queue // since the reference handler invokes cleaners explicitly. // - private static final ReferenceQueue dummyQueue = new ReferenceQueue(); + private static final ReferenceQueue dummyQueue = new ReferenceQueue<>(); // Doubly-linked list of live cleaners, which prevents the cleaners // themselves from being GC'd before their referents @@ -119,6 +119,7 @@ /** * Creates a new cleaner. * + * @param ob the referent object to be cleaned * @param thunk * The cleanup code to be run when the cleaner is invoked. The * cleanup code is run directly from the reference-handler thread, diff -r 9fcb07df1c92 src/share/classes/sun/misc/ProxyGenerator.java --- a/src/share/classes/sun/misc/ProxyGenerator.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/sun/misc/ProxyGenerator.java Tue Nov 12 00:51:15 2013 -0800 @@ -384,7 +384,7 @@ private String className; /** proxy interfaces */ - private Class[] interfaces; + private Class[] interfaces; /** proxy class access flags */ private int accessFlags; diff -r 9fcb07df1c92 src/share/classes/sun/rmi/rmic/Main.java --- a/src/share/classes/sun/rmi/rmic/Main.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/sun/rmi/rmic/Main.java Tue Nov 12 00:51:15 2013 -0800 @@ -494,7 +494,7 @@ extDirsArg); BatchEnvironment result = null; try { - Class[] ctorArgTypes = {OutputStream.class,ClassPath.class,Main.class}; + Class[] ctorArgTypes = {OutputStream.class,ClassPath.class,Main.class}; Object[] ctorArgs = {out,classPath,this}; Constructor constructor = environmentClass.getConstructor(ctorArgTypes); diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/LoaderHandler.java --- a/src/share/classes/sun/rmi/server/LoaderHandler.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Tue Nov 12 00:51:15 2013 -0800 @@ -692,7 +692,7 @@ * Define a proxy class in the given class loader. The proxy * class will implement the given interfaces Classes. */ - private static Class loadProxyClass(ClassLoader loader, Class[] interfaces) + private static Class loadProxyClass(ClassLoader loader, Class[] interfaces) throws ClassNotFoundException { try { @@ -719,7 +719,7 @@ */ private static ClassLoader loadProxyInterfaces(String[] interfaces, ClassLoader loader, - Class[] classObjs, + Class[] classObjs, boolean[] nonpublic) throws ClassNotFoundException { diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/UnicastServerRef.java --- a/src/share/classes/sun/rmi/server/UnicastServerRef.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/sun/rmi/server/UnicastServerRef.java Tue Nov 12 00:51:15 2013 -0800 @@ -299,7 +299,7 @@ logCall(obj, method); // unmarshal parameters - Class[] types = method.getParameterTypes(); + Class[] types = method.getParameterTypes(); Object[] params = new Object[types.length]; try { diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/Util.java --- a/src/share/classes/sun/rmi/server/Util.java Sat Nov 09 04:21:28 2013 +0400 +++ b/src/share/classes/sun/rmi/server/Util.java Tue Nov 12 00:51:15 2013 -0800 @@ -87,7 +87,7 @@ Collections.synchronizedMap(new WeakHashMap, Void>(11)); /** parameter types for stub constructor */ - private static final Class[] stubConsParamTypes = { RemoteRef.class }; + private static final Class[] stubConsParamTypes = { RemoteRef.class }; private Util() { } @@ -143,7 +143,7 @@ } final ClassLoader loader = implClass.getClassLoader(); - final Class[] interfaces = getRemoteInterfaces(implClass); + final Class[] interfaces = getRemoteInterfaces(implClass); final InvocationHandler handler = new RemoteObjectInvocationHandler(clientRef); From chris.hegarty at oracle.com Tue Nov 12 09:51:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Nov 2013 09:51:19 +0000 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <5281F4B4.50602@oracle.com> References: <5281F4B4.50602@oracle.com> Message-ID: <5281FA17.3030700@oracle.com> Looks ok to me Joe. -Chris. On 12/11/13 09:28, Joe Darcy wrote: > Hello, > > Please review the patch below which would remove another batch of raw > type javac lint warnings from the core libraries. > > No signatures of public or protected methods in the Java SE > specification have been modified. Regression tests in affected areas pass. > > Thanks, > > -Joe > > diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java > --- a/src/share/classes/java/io/ObjectOutputStream.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/io/ObjectOutputStream.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1248,7 +1248,7 @@ > handles.assign(unshared ? null : desc); > > Class cl = desc.forClass(); > - Class[] ifaces = cl.getInterfaces(); > + Class[] ifaces = cl.getInterfaces(); > bout.writeInt(ifaces.length); > for (int i = 0; i < ifaces.length; i++) { > bout.writeUTF(ifaces[i].getName()); > diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java > --- a/src/share/classes/java/io/ObjectStreamClass.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/io/ObjectStreamClass.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1746,7 +1746,7 @@ > dout.writeUTF("()V"); > } > > - Constructor[] cons = cl.getDeclaredConstructors(); > + Constructor[] cons = cl.getDeclaredConstructors(); > MemberSignature[] consSigs = new > MemberSignature[cons.length]; > for (int i = 0; i < cons.length; i++) { > consSigs[i] = new MemberSignature(cons[i]); > diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java > --- a/src/share/classes/java/lang/reflect/Proxy.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/lang/reflect/Proxy.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -494,9 +494,10 @@ > private final int hash; > private final WeakReference>[] refs; > > + @SuppressWarnings({"rawtypes", "unchecked"}) > KeyX(Class[] interfaces) { > hash = Arrays.hashCode(interfaces); > - refs = new WeakReference[interfaces.length]; > + refs = (WeakReference>[])new > WeakReference[interfaces.length]; > for (int i = 0; i < interfaces.length; i++) { > refs[i] = new WeakReference<>(interfaces[i]); > } > diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java > --- a/src/share/classes/java/nio/file/TempFileHelper.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/nio/file/TempFileHelper.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -81,7 +81,7 @@ > String prefix, > String suffix, > boolean createDirectory, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > if (prefix == null) > @@ -155,7 +155,7 @@ > static Path createTempFile(Path dir, > String prefix, > String suffix, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > return create(dir, prefix, suffix, false, attrs); > @@ -167,7 +167,7 @@ > */ > static Path createTempDirectory(Path dir, > String prefix, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > return create(dir, prefix, null, true, attrs); > diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java > --- a/src/share/classes/java/util/IdentityHashMap.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/IdentityHashMap.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1243,7 +1243,7 @@ > if (ti >= size) { > throw new ConcurrentModificationException(); > } > - a[ti++] = (T) new > AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]); > + a[ti++] = (T) new > AbstractMap.SimpleEntry<>(unmaskNull(key), tab[si + 1]); > } > } > // fewer elements than expected or concurrent modification > from other thread detected > diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java > --- a/src/share/classes/java/util/logging/Logger.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/logging/Logger.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -351,7 +351,7 @@ > ? caller.getClassLoader() > : null); > if (callersClassLoader != null) { > - this.callersClassLoaderRef = new > WeakReference(callersClassLoader); > + this.callersClassLoaderRef = new > WeakReference<>(callersClassLoader); > } > } > > diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logging.java > --- a/src/share/classes/java/util/logging/Logging.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/logging/Logging.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -55,11 +55,11 @@ > } > > public List getLoggerNames() { > - Enumeration loggers = logManager.getLoggerNames(); > + Enumeration loggers = logManager.getLoggerNames(); > ArrayList array = new ArrayList<>(); > > for (; loggers.hasMoreElements();) { > - array.add((String) loggers.nextElement()); > + array.add(loggers.nextElement()); > } > return array; > } > diff -r 9fcb07df1c92 src/share/classes/sun/misc/Cleaner.java > --- a/src/share/classes/sun/misc/Cleaner.java Sat Nov 09 04:21:28 > 2013 +0400 > +++ b/src/share/classes/sun/misc/Cleaner.java Tue Nov 12 00:51:15 > 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2008, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -57,14 +57,14 @@ > */ > > public class Cleaner > - extends PhantomReference > + extends PhantomReference > { > > // Dummy reference queue, needed because the PhantomReference > constructor > // insists that we pass a queue. Nothing will ever be placed on > this queue > // since the reference handler invokes cleaners explicitly. > // > - private static final ReferenceQueue dummyQueue = new ReferenceQueue(); > + private static final ReferenceQueue dummyQueue = new > ReferenceQueue<>(); > > // Doubly-linked list of live cleaners, which prevents the cleaners > // themselves from being GC'd before their referents > @@ -119,6 +119,7 @@ > /** > * Creates a new cleaner. > * > + * @param ob the referent object to be cleaned > * @param thunk > * The cleanup code to be run when the cleaner is > invoked. The > * cleanup code is run directly from the reference-handler > thread, > diff -r 9fcb07df1c92 src/share/classes/sun/misc/ProxyGenerator.java > --- a/src/share/classes/sun/misc/ProxyGenerator.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/misc/ProxyGenerator.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -384,7 +384,7 @@ > private String className; > > /** proxy interfaces */ > - private Class[] interfaces; > + private Class[] interfaces; > > /** proxy class access flags */ > private int accessFlags; > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/rmic/Main.java > --- a/src/share/classes/sun/rmi/rmic/Main.java Sat Nov 09 04:21:28 > 2013 +0400 > +++ b/src/share/classes/sun/rmi/rmic/Main.java Tue Nov 12 00:51:15 > 2013 -0800 > @@ -494,7 +494,7 @@ > extDirsArg); > BatchEnvironment result = null; > try { > - Class[] ctorArgTypes = > {OutputStream.class,ClassPath.class,Main.class}; > + Class[] ctorArgTypes = > {OutputStream.class,ClassPath.class,Main.class}; > Object[] ctorArgs = {out,classPath,this}; > Constructor constructor = > environmentClass.getConstructor(ctorArgTypes); > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/LoaderHandler.java > --- a/src/share/classes/sun/rmi/server/LoaderHandler.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -692,7 +692,7 @@ > * Define a proxy class in the given class loader. The proxy > * class will implement the given interfaces Classes. > */ > - private static Class loadProxyClass(ClassLoader loader, Class[] > interfaces) > + private static Class loadProxyClass(ClassLoader loader, > Class[] interfaces) > throws ClassNotFoundException > { > try { > @@ -719,7 +719,7 @@ > */ > private static ClassLoader loadProxyInterfaces(String[] interfaces, > ClassLoader loader, > - Class[] classObjs, > + Class[] classObjs, > boolean[] nonpublic) > throws ClassNotFoundException > { > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/UnicastServerRef.java > --- a/src/share/classes/sun/rmi/server/UnicastServerRef.java Sat Nov > 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/UnicastServerRef.java Tue Nov > 12 00:51:15 2013 -0800 > @@ -299,7 +299,7 @@ > logCall(obj, method); > > // unmarshal parameters > - Class[] types = method.getParameterTypes(); > + Class[] types = method.getParameterTypes(); > Object[] params = new Object[types.length]; > > try { > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/Util.java > --- a/src/share/classes/sun/rmi/server/Util.java Sat Nov 09 04:21:28 > 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/Util.java Tue Nov 12 00:51:15 > 2013 -0800 > @@ -87,7 +87,7 @@ > Collections.synchronizedMap(new WeakHashMap, Void>(11)); > > /** parameter types for stub constructor */ > - private static final Class[] stubConsParamTypes = { RemoteRef.class }; > + private static final Class[] stubConsParamTypes = { > RemoteRef.class }; > > private Util() { > } > @@ -143,7 +143,7 @@ > } > > final ClassLoader loader = implClass.getClassLoader(); > - final Class[] interfaces = getRemoteInterfaces(implClass); > + final Class[] interfaces = getRemoteInterfaces(implClass); > final InvocationHandler handler = > new RemoteObjectInvocationHandler(clientRef); > From Alan.Bateman at oracle.com Tue Nov 12 09:51:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 09:51:58 +0000 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <5281F4B4.50602@oracle.com> References: <5281F4B4.50602@oracle.com> Message-ID: <5281FA3E.90902@oracle.com> On 12/11/2013 09:28, Joe Darcy wrote: > Hello, > > Please review the patch below which would remove another batch of raw > type javac lint warnings from the core libraries. > > No signatures of public or protected methods in the Java SE > specification have been modified. Regression tests in affected areas > pass. > > Thanks, > > -Joe These looks okay to me too. -Alan. From forax at univ-mlv.fr Tue Nov 12 09:48:17 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Nov 2013 10:48:17 +0100 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <5281FA17.3030700@oracle.com> References: <5281F4B4.50602@oracle.com> <5281FA17.3030700@oracle.com> Message-ID: <5281F961.5000900@univ-mlv.fr> On 11/12/2013 10:51 AM, Chris Hegarty wrote: > Looks ok to me Joe. > > -Chris. A small issue, refs = (WeakReference>[])new WeakReference[interfaces.length]; should be refs = (WeakReference>[])new WeakReference[interfaces.length]; otherwise, looks good. R?mi > > On 12/11/13 09:28, Joe Darcy wrote: >> Hello, >> >> Please review the patch below which would remove another batch of raw >> type javac lint warnings from the core libraries. >> >> No signatures of public or protected methods in the Java SE >> specification have been modified. Regression tests in affected areas >> pass. >> >> Thanks, >> >> -Joe >> >> diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java >> --- a/src/share/classes/java/io/ObjectOutputStream.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/io/ObjectOutputStream.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -1248,7 +1248,7 @@ >> handles.assign(unshared ? null : desc); >> >> Class cl = desc.forClass(); >> - Class[] ifaces = cl.getInterfaces(); >> + Class[] ifaces = cl.getInterfaces(); >> bout.writeInt(ifaces.length); >> for (int i = 0; i < ifaces.length; i++) { >> bout.writeUTF(ifaces[i].getName()); >> diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java >> --- a/src/share/classes/java/io/ObjectStreamClass.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/io/ObjectStreamClass.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -1746,7 +1746,7 @@ >> dout.writeUTF("()V"); >> } >> >> - Constructor[] cons = cl.getDeclaredConstructors(); >> + Constructor[] cons = cl.getDeclaredConstructors(); >> MemberSignature[] consSigs = new >> MemberSignature[cons.length]; >> for (int i = 0; i < cons.length; i++) { >> consSigs[i] = new MemberSignature(cons[i]); >> diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java >> --- a/src/share/classes/java/lang/reflect/Proxy.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/lang/reflect/Proxy.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -494,9 +494,10 @@ >> private final int hash; >> private final WeakReference>[] refs; >> >> + @SuppressWarnings({"rawtypes", "unchecked"}) >> KeyX(Class[] interfaces) { >> hash = Arrays.hashCode(interfaces); >> - refs = new WeakReference[interfaces.length]; >> + refs = (WeakReference>[])new >> WeakReference[interfaces.length]; >> for (int i = 0; i < interfaces.length; i++) { >> refs[i] = new WeakReference<>(interfaces[i]); >> } >> diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java >> --- a/src/share/classes/java/nio/file/TempFileHelper.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/nio/file/TempFileHelper.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -81,7 +81,7 @@ >> String prefix, >> String suffix, >> boolean createDirectory, >> - FileAttribute[] attrs) >> + FileAttribute[] attrs) >> throws IOException >> { >> if (prefix == null) >> @@ -155,7 +155,7 @@ >> static Path createTempFile(Path dir, >> String prefix, >> String suffix, >> - FileAttribute[] attrs) >> + FileAttribute[] attrs) >> throws IOException >> { >> return create(dir, prefix, suffix, false, attrs); >> @@ -167,7 +167,7 @@ >> */ >> static Path createTempDirectory(Path dir, >> String prefix, >> - FileAttribute[] attrs) >> + FileAttribute[] attrs) >> throws IOException >> { >> return create(dir, prefix, null, true, attrs); >> diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java >> --- a/src/share/classes/java/util/IdentityHashMap.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/util/IdentityHashMap.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -1243,7 +1243,7 @@ >> if (ti >= size) { >> throw new ConcurrentModificationException(); >> } >> - a[ti++] = (T) new >> AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]); >> + a[ti++] = (T) new >> AbstractMap.SimpleEntry<>(unmaskNull(key), tab[si + 1]); >> } >> } >> // fewer elements than expected or concurrent modification >> from other thread detected >> diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java >> --- a/src/share/classes/java/util/logging/Logger.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/util/logging/Logger.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -351,7 +351,7 @@ >> ? caller.getClassLoader() >> : null); >> if (callersClassLoader != null) { >> - this.callersClassLoaderRef = new >> WeakReference(callersClassLoader); >> + this.callersClassLoaderRef = new >> WeakReference<>(callersClassLoader); >> } >> } >> >> diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logging.java >> --- a/src/share/classes/java/util/logging/Logging.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/java/util/logging/Logging.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -55,11 +55,11 @@ >> } >> >> public List getLoggerNames() { >> - Enumeration loggers = logManager.getLoggerNames(); >> + Enumeration loggers = logManager.getLoggerNames(); >> ArrayList array = new ArrayList<>(); >> >> for (; loggers.hasMoreElements();) { >> - array.add((String) loggers.nextElement()); >> + array.add(loggers.nextElement()); >> } >> return array; >> } >> diff -r 9fcb07df1c92 src/share/classes/sun/misc/Cleaner.java >> --- a/src/share/classes/sun/misc/Cleaner.java Sat Nov 09 04:21:28 >> 2013 +0400 >> +++ b/src/share/classes/sun/misc/Cleaner.java Tue Nov 12 00:51:15 >> 2013 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2003, 2008, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights >> reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -57,14 +57,14 @@ >> */ >> >> public class Cleaner >> - extends PhantomReference >> + extends PhantomReference >> { >> >> // Dummy reference queue, needed because the PhantomReference >> constructor >> // insists that we pass a queue. Nothing will ever be placed on >> this queue >> // since the reference handler invokes cleaners explicitly. >> // >> - private static final ReferenceQueue dummyQueue = new >> ReferenceQueue(); >> + private static final ReferenceQueue dummyQueue = new >> ReferenceQueue<>(); >> >> // Doubly-linked list of live cleaners, which prevents the >> cleaners >> // themselves from being GC'd before their referents >> @@ -119,6 +119,7 @@ >> /** >> * Creates a new cleaner. >> * >> + * @param ob the referent object to be cleaned >> * @param thunk >> * The cleanup code to be run when the cleaner is >> invoked. The >> * cleanup code is run directly from the reference-handler >> thread, >> diff -r 9fcb07df1c92 src/share/classes/sun/misc/ProxyGenerator.java >> --- a/src/share/classes/sun/misc/ProxyGenerator.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/sun/misc/ProxyGenerator.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -384,7 +384,7 @@ >> private String className; >> >> /** proxy interfaces */ >> - private Class[] interfaces; >> + private Class[] interfaces; >> >> /** proxy class access flags */ >> private int accessFlags; >> diff -r 9fcb07df1c92 src/share/classes/sun/rmi/rmic/Main.java >> --- a/src/share/classes/sun/rmi/rmic/Main.java Sat Nov 09 04:21:28 >> 2013 +0400 >> +++ b/src/share/classes/sun/rmi/rmic/Main.java Tue Nov 12 00:51:15 >> 2013 -0800 >> @@ -494,7 +494,7 @@ >> extDirsArg); >> BatchEnvironment result = null; >> try { >> - Class[] ctorArgTypes = >> {OutputStream.class,ClassPath.class,Main.class}; >> + Class[] ctorArgTypes = >> {OutputStream.class,ClassPath.class,Main.class}; >> Object[] ctorArgs = {out,classPath,this}; >> Constructor constructor = >> environmentClass.getConstructor(ctorArgTypes); >> diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/LoaderHandler.java >> --- a/src/share/classes/sun/rmi/server/LoaderHandler.java Sat Nov 09 >> 04:21:28 2013 +0400 >> +++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Tue Nov 12 >> 00:51:15 2013 -0800 >> @@ -692,7 +692,7 @@ >> * Define a proxy class in the given class loader. The proxy >> * class will implement the given interfaces Classes. >> */ >> - private static Class loadProxyClass(ClassLoader loader, Class[] >> interfaces) >> + private static Class loadProxyClass(ClassLoader loader, >> Class[] interfaces) >> throws ClassNotFoundException >> { >> try { >> @@ -719,7 +719,7 @@ >> */ >> private static ClassLoader loadProxyInterfaces(String[] >> interfaces, >> ClassLoader loader, >> - Class[] classObjs, >> + Class[] classObjs, >> boolean[] >> nonpublic) >> throws ClassNotFoundException >> { >> diff -r 9fcb07df1c92 >> src/share/classes/sun/rmi/server/UnicastServerRef.java >> --- a/src/share/classes/sun/rmi/server/UnicastServerRef.java Sat Nov >> 09 04:21:28 2013 +0400 >> +++ b/src/share/classes/sun/rmi/server/UnicastServerRef.java Tue Nov >> 12 00:51:15 2013 -0800 >> @@ -299,7 +299,7 @@ >> logCall(obj, method); >> >> // unmarshal parameters >> - Class[] types = method.getParameterTypes(); >> + Class[] types = method.getParameterTypes(); >> Object[] params = new Object[types.length]; >> >> try { >> diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/Util.java >> --- a/src/share/classes/sun/rmi/server/Util.java Sat Nov 09 04:21:28 >> 2013 +0400 >> +++ b/src/share/classes/sun/rmi/server/Util.java Tue Nov 12 00:51:15 >> 2013 -0800 >> @@ -87,7 +87,7 @@ >> Collections.synchronizedMap(new WeakHashMap, >> Void>(11)); >> >> /** parameter types for stub constructor */ >> - private static final Class[] stubConsParamTypes = { >> RemoteRef.class }; >> + private static final Class[] stubConsParamTypes = { >> RemoteRef.class }; >> >> private Util() { >> } >> @@ -143,7 +143,7 @@ >> } >> >> final ClassLoader loader = implClass.getClassLoader(); >> - final Class[] interfaces = getRemoteInterfaces(implClass); >> + final Class[] interfaces = getRemoteInterfaces(implClass); >> final InvocationHandler handler = >> new RemoteObjectInvocationHandler(clientRef); >> From joel.franck at oracle.com Tue Nov 12 10:34:54 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Tue, 12 Nov 2013 11:34:54 +0100 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <5281F4B4.50602@oracle.com> References: <5281F4B4.50602@oracle.com> Message-ID: <20131112103454.GG17332@oracle.com> Hi Joe, Looks good, but your mailer trashes the patch. Please fix your mailer linewrap settings. cheers /Joel On 2013-11-12, Joe Darcy wrote: > Hello, > > Please review the patch below which would remove another batch of > raw type javac lint warnings from the core libraries. > > No signatures of public or protected methods in the Java SE > specification have been modified. Regression tests in affected areas > pass. > > Thanks, > > -Joe > > diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java > --- a/src/share/classes/java/io/ObjectOutputStream.java Sat Nov > 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/io/ObjectOutputStream.java Tue Nov > 12 00:51:15 2013 -0800 > @@ -1248,7 +1248,7 @@ > handles.assign(unshared ? null : desc); > > Class cl = desc.forClass(); > - Class[] ifaces = cl.getInterfaces(); > + Class[] ifaces = cl.getInterfaces(); > bout.writeInt(ifaces.length); > for (int i = 0; i < ifaces.length; i++) { > bout.writeUTF(ifaces[i].getName()); > diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java > --- a/src/share/classes/java/io/ObjectStreamClass.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/io/ObjectStreamClass.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All > rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1746,7 +1746,7 @@ > dout.writeUTF("()V"); > } > > - Constructor[] cons = cl.getDeclaredConstructors(); > + Constructor[] cons = cl.getDeclaredConstructors(); > MemberSignature[] consSigs = new MemberSignature[cons.length]; > for (int i = 0; i < cons.length; i++) { > consSigs[i] = new MemberSignature(cons[i]); > diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java > --- a/src/share/classes/java/lang/reflect/Proxy.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/lang/reflect/Proxy.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -494,9 +494,10 @@ > private final int hash; > private final WeakReference>[] refs; > > + @SuppressWarnings({"rawtypes", "unchecked"}) > KeyX(Class[] interfaces) { > hash = Arrays.hashCode(interfaces); > - refs = new WeakReference[interfaces.length]; > + refs = (WeakReference>[])new > WeakReference[interfaces.length]; > for (int i = 0; i < interfaces.length; i++) { > refs[i] = new WeakReference<>(interfaces[i]); > } > diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java > --- a/src/share/classes/java/nio/file/TempFileHelper.java Sat Nov > 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/nio/file/TempFileHelper.java Tue Nov > 12 00:51:15 2013 -0800 > @@ -81,7 +81,7 @@ > String prefix, > String suffix, > boolean createDirectory, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > if (prefix == null) > @@ -155,7 +155,7 @@ > static Path createTempFile(Path dir, > String prefix, > String suffix, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > return create(dir, prefix, suffix, false, attrs); > @@ -167,7 +167,7 @@ > */ > static Path createTempDirectory(Path dir, > String prefix, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > return create(dir, prefix, null, true, attrs); > diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java > --- a/src/share/classes/java/util/IdentityHashMap.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/IdentityHashMap.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1243,7 +1243,7 @@ > if (ti >= size) { > throw new ConcurrentModificationException(); > } > - a[ti++] = (T) new > AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]); > + a[ti++] = (T) new > AbstractMap.SimpleEntry<>(unmaskNull(key), tab[si + 1]); > } > } > // fewer elements than expected or concurrent > modification from other thread detected > diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java > --- a/src/share/classes/java/util/logging/Logger.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/logging/Logger.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -351,7 +351,7 @@ > ? caller.getClassLoader() > : null); > if (callersClassLoader != null) { > - this.callersClassLoaderRef = new > WeakReference(callersClassLoader); > + this.callersClassLoaderRef = new > WeakReference<>(callersClassLoader); > } > } > > diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logging.java > --- a/src/share/classes/java/util/logging/Logging.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/logging/Logging.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All > rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -55,11 +55,11 @@ > } > > public List getLoggerNames() { > - Enumeration loggers = logManager.getLoggerNames(); > + Enumeration loggers = logManager.getLoggerNames(); > ArrayList array = new ArrayList<>(); > > for (; loggers.hasMoreElements();) { > - array.add((String) loggers.nextElement()); > + array.add(loggers.nextElement()); > } > return array; > } > diff -r 9fcb07df1c92 src/share/classes/sun/misc/Cleaner.java > --- a/src/share/classes/sun/misc/Cleaner.java Sat Nov 09 04:21:28 > 2013 +0400 > +++ b/src/share/classes/sun/misc/Cleaner.java Tue Nov 12 00:51:15 > 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2008, Oracle and/or its affiliates. All > rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All > rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -57,14 +57,14 @@ > */ > > public class Cleaner > - extends PhantomReference > + extends PhantomReference > { > > // Dummy reference queue, needed because the PhantomReference > constructor > // insists that we pass a queue. Nothing will ever be placed > on this queue > // since the reference handler invokes cleaners explicitly. > // > - private static final ReferenceQueue dummyQueue = new ReferenceQueue(); > + private static final ReferenceQueue dummyQueue = new > ReferenceQueue<>(); > > // Doubly-linked list of live cleaners, which prevents the cleaners > // themselves from being GC'd before their referents > @@ -119,6 +119,7 @@ > /** > * Creates a new cleaner. > * > + * @param ob the referent object to be cleaned > * @param thunk > * The cleanup code to be run when the cleaner is > invoked. The > * cleanup code is run directly from the > reference-handler thread, > diff -r 9fcb07df1c92 src/share/classes/sun/misc/ProxyGenerator.java > --- a/src/share/classes/sun/misc/ProxyGenerator.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/misc/ProxyGenerator.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -384,7 +384,7 @@ > private String className; > > /** proxy interfaces */ > - private Class[] interfaces; > + private Class[] interfaces; > > /** proxy class access flags */ > private int accessFlags; > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/rmic/Main.java > --- a/src/share/classes/sun/rmi/rmic/Main.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/rmic/Main.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -494,7 +494,7 @@ > extDirsArg); > BatchEnvironment result = null; > try { > - Class[] ctorArgTypes = > {OutputStream.class,ClassPath.class,Main.class}; > + Class[] ctorArgTypes = > {OutputStream.class,ClassPath.class,Main.class}; > Object[] ctorArgs = {out,classPath,this}; > Constructor constructor = > environmentClass.getConstructor(ctorArgTypes); > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/LoaderHandler.java > --- a/src/share/classes/sun/rmi/server/LoaderHandler.java Sat Nov > 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Tue Nov > 12 00:51:15 2013 -0800 > @@ -692,7 +692,7 @@ > * Define a proxy class in the given class loader. The proxy > * class will implement the given interfaces Classes. > */ > - private static Class loadProxyClass(ClassLoader loader, > Class[] interfaces) > + private static Class loadProxyClass(ClassLoader loader, > Class[] interfaces) > throws ClassNotFoundException > { > try { > @@ -719,7 +719,7 @@ > */ > private static ClassLoader loadProxyInterfaces(String[] interfaces, > ClassLoader loader, > - Class[] classObjs, > + Class[] classObjs, > boolean[] nonpublic) > throws ClassNotFoundException > { > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/UnicastServerRef.java > --- a/src/share/classes/sun/rmi/server/UnicastServerRef.java Sat > Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/UnicastServerRef.java Tue > Nov 12 00:51:15 2013 -0800 > @@ -299,7 +299,7 @@ > logCall(obj, method); > > // unmarshal parameters > - Class[] types = method.getParameterTypes(); > + Class[] types = method.getParameterTypes(); > Object[] params = new Object[types.length]; > > try { > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/Util.java > --- a/src/share/classes/sun/rmi/server/Util.java Sat Nov 09 > 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/Util.java Tue Nov 12 > 00:51:15 2013 -0800 > @@ -87,7 +87,7 @@ > Collections.synchronizedMap(new WeakHashMap, Void>(11)); > > /** parameter types for stub constructor */ > - private static final Class[] stubConsParamTypes = { RemoteRef.class }; > + private static final Class[] stubConsParamTypes = { > RemoteRef.class }; > > private Util() { > } > @@ -143,7 +143,7 @@ > } > > final ClassLoader loader = implClass.getClassLoader(); > - final Class[] interfaces = getRemoteInterfaces(implClass); > + final Class[] interfaces = getRemoteInterfaces(implClass); > final InvocationHandler handler = > new RemoteObjectInvocationHandler(clientRef); > From patrick.zhang at oracle.com Tue Nov 12 11:01:05 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Tue, 12 Nov 2013 19:01:05 +0800 Subject: RFR for JDK-8016519. closed/javax/xml/ws/8005432/TestProxyCreation.java uses fixed port to publish webservice In-Reply-To: <527B0D72.703@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> Message-ID: <52820A71.6010804@oracle.com> Hi Everyone, I am working on https://bugs.openjdk.java.net/browse/JDK-8016519. The test uses fixed port(8080) to publish webservice and it will fail periodically when the port has been occupied by other tests or applications. The fix will use new InetSocketAddress(0).getPort() to retrieve one free port. webrev: http://cr.openjdk.java.net/~pzhang/8016519/webrev/ result: http://cr.openjdk.java.net/~pzhang/8016519/TestProxyCreation.jtr Regards Patrick From Alan.Bateman at oracle.com Tue Nov 12 11:09:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 11:09:28 +0000 Subject: RFR for JDK-8016519. closed/javax/xml/ws/8005432/TestProxyCreation.java uses fixed port to publish webservice In-Reply-To: <52820A71.6010804@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <52820A71.6010804@oracle.com> Message-ID: <52820C68.9080501@oracle.com> On 12/11/2013 11:01, Patrick Zhang wrote: > Hi Everyone, > > I am working on https://bugs.openjdk.java.net/browse/JDK-8016519. The > test uses fixed port(8080) to publish webservice and it will fail > periodically when the port has been occupied by other tests or > applications. This test is not in OpenJDK so this is not the place to review this. -Alan. From Lance.Andersen at oracle.com Tue Nov 12 12:07:17 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Nov 2013 07:07:17 -0500 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <5281F4B4.50602@oracle.com> References: <5281F4B4.50602@oracle.com> Message-ID: <564A97AA-53D7-49AA-974E-B73E14732DE8@oracle.com> Looks Ok Joe On Nov 12, 2013, at 4:28 AM, Joe Darcy wrote: > Hello, > > Please review the patch below which would remove another batch of raw type javac lint warnings from the core libraries. > > No signatures of public or protected methods in the Java SE specification have been modified. Regression tests in affected areas pass. > > Thanks, > > -Joe > > diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java > --- a/src/share/classes/java/io/ObjectOutputStream.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/io/ObjectOutputStream.java Tue Nov 12 00:51:15 2013 -0800 > @@ -1248,7 +1248,7 @@ > handles.assign(unshared ? null : desc); > > Class cl = desc.forClass(); > - Class[] ifaces = cl.getInterfaces(); > + Class[] ifaces = cl.getInterfaces(); > bout.writeInt(ifaces.length); > for (int i = 0; i < ifaces.length; i++) { > bout.writeUTF(ifaces[i].getName()); > diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java > --- a/src/share/classes/java/io/ObjectStreamClass.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/io/ObjectStreamClass.java Tue Nov 12 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -1746,7 +1746,7 @@ > dout.writeUTF("()V"); > } > > - Constructor[] cons = cl.getDeclaredConstructors(); > + Constructor[] cons = cl.getDeclaredConstructors(); > MemberSignature[] consSigs = new MemberSignature[cons.length]; > for (int i = 0; i < cons.length; i++) { > consSigs[i] = new MemberSignature(cons[i]); > diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java > --- a/src/share/classes/java/lang/reflect/Proxy.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/lang/reflect/Proxy.java Tue Nov 12 00:51:15 2013 -0800 > @@ -494,9 +494,10 @@ > private final int hash; > private final WeakReference>[] refs; > > + @SuppressWarnings({"rawtypes", "unchecked"}) > KeyX(Class[] interfaces) { > hash = Arrays.hashCode(interfaces); > - refs = new WeakReference[interfaces.length]; > + refs = (WeakReference>[])new WeakReference[interfaces.length]; > for (int i = 0; i < interfaces.length; i++) { > refs[i] = new WeakReference<>(interfaces[i]); > } > diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java > --- a/src/share/classes/java/nio/file/TempFileHelper.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/nio/file/TempFileHelper.java Tue Nov 12 00:51:15 2013 -0800 > @@ -81,7 +81,7 @@ > String prefix, > String suffix, > boolean createDirectory, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > if (prefix == null) > @@ -155,7 +155,7 @@ > static Path createTempFile(Path dir, > String prefix, > String suffix, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > return create(dir, prefix, suffix, false, attrs); > @@ -167,7 +167,7 @@ > */ > static Path createTempDirectory(Path dir, > String prefix, > - FileAttribute[] attrs) > + FileAttribute[] attrs) > throws IOException > { > return create(dir, prefix, null, true, attrs); > diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java > --- a/src/share/classes/java/util/IdentityHashMap.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/IdentityHashMap.java Tue Nov 12 00:51:15 2013 -0800 > @@ -1243,7 +1243,7 @@ > if (ti >= size) { > throw new ConcurrentModificationException(); > } > - a[ti++] = (T) new AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]); > + a[ti++] = (T) new AbstractMap.SimpleEntry<>(unmaskNull(key), tab[si + 1]); > } > } > // fewer elements than expected or concurrent modification from other thread detected > diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java > --- a/src/share/classes/java/util/logging/Logger.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/logging/Logger.java Tue Nov 12 00:51:15 2013 -0800 > @@ -351,7 +351,7 @@ > ? caller.getClassLoader() > : null); > if (callersClassLoader != null) { > - this.callersClassLoaderRef = new WeakReference(callersClassLoader); > + this.callersClassLoaderRef = new WeakReference<>(callersClassLoader); > } > } > > diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logging.java > --- a/src/share/classes/java/util/logging/Logging.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/java/util/logging/Logging.java Tue Nov 12 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -55,11 +55,11 @@ > } > > public List getLoggerNames() { > - Enumeration loggers = logManager.getLoggerNames(); > + Enumeration loggers = logManager.getLoggerNames(); > ArrayList array = new ArrayList<>(); > > for (; loggers.hasMoreElements();) { > - array.add((String) loggers.nextElement()); > + array.add(loggers.nextElement()); > } > return array; > } > diff -r 9fcb07df1c92 src/share/classes/sun/misc/Cleaner.java > --- a/src/share/classes/sun/misc/Cleaner.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/misc/Cleaner.java Tue Nov 12 00:51:15 2013 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2008, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -57,14 +57,14 @@ > */ > > public class Cleaner > - extends PhantomReference > + extends PhantomReference > { > > // Dummy reference queue, needed because the PhantomReference constructor > // insists that we pass a queue. Nothing will ever be placed on this queue > // since the reference handler invokes cleaners explicitly. > // > - private static final ReferenceQueue dummyQueue = new ReferenceQueue(); > + private static final ReferenceQueue dummyQueue = new ReferenceQueue<>(); > > // Doubly-linked list of live cleaners, which prevents the cleaners > // themselves from being GC'd before their referents > @@ -119,6 +119,7 @@ > /** > * Creates a new cleaner. > * > + * @param ob the referent object to be cleaned > * @param thunk > * The cleanup code to be run when the cleaner is invoked. The > * cleanup code is run directly from the reference-handler thread, > diff -r 9fcb07df1c92 src/share/classes/sun/misc/ProxyGenerator.java > --- a/src/share/classes/sun/misc/ProxyGenerator.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/misc/ProxyGenerator.java Tue Nov 12 00:51:15 2013 -0800 > @@ -384,7 +384,7 @@ > private String className; > > /** proxy interfaces */ > - private Class[] interfaces; > + private Class[] interfaces; > > /** proxy class access flags */ > private int accessFlags; > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/rmic/Main.java > --- a/src/share/classes/sun/rmi/rmic/Main.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/rmic/Main.java Tue Nov 12 00:51:15 2013 -0800 > @@ -494,7 +494,7 @@ > extDirsArg); > BatchEnvironment result = null; > try { > - Class[] ctorArgTypes = {OutputStream.class,ClassPath.class,Main.class}; > + Class[] ctorArgTypes = {OutputStream.class,ClassPath.class,Main.class}; > Object[] ctorArgs = {out,classPath,this}; > Constructor constructor = > environmentClass.getConstructor(ctorArgTypes); > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/LoaderHandler.java > --- a/src/share/classes/sun/rmi/server/LoaderHandler.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Tue Nov 12 00:51:15 2013 -0800 > @@ -692,7 +692,7 @@ > * Define a proxy class in the given class loader. The proxy > * class will implement the given interfaces Classes. > */ > - private static Class loadProxyClass(ClassLoader loader, Class[] interfaces) > + private static Class loadProxyClass(ClassLoader loader, Class[] interfaces) > throws ClassNotFoundException > { > try { > @@ -719,7 +719,7 @@ > */ > private static ClassLoader loadProxyInterfaces(String[] interfaces, > ClassLoader loader, > - Class[] classObjs, > + Class[] classObjs, > boolean[] nonpublic) > throws ClassNotFoundException > { > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/UnicastServerRef.java > --- a/src/share/classes/sun/rmi/server/UnicastServerRef.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/UnicastServerRef.java Tue Nov 12 00:51:15 2013 -0800 > @@ -299,7 +299,7 @@ > logCall(obj, method); > > // unmarshal parameters > - Class[] types = method.getParameterTypes(); > + Class[] types = method.getParameterTypes(); > Object[] params = new Object[types.length]; > > try { > diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/Util.java > --- a/src/share/classes/sun/rmi/server/Util.java Sat Nov 09 04:21:28 2013 +0400 > +++ b/src/share/classes/sun/rmi/server/Util.java Tue Nov 12 00:51:15 2013 -0800 > @@ -87,7 +87,7 @@ > Collections.synchronizedMap(new WeakHashMap, Void>(11)); > > /** parameter types for stub constructor */ > - private static final Class[] stubConsParamTypes = { RemoteRef.class }; > + private static final Class[] stubConsParamTypes = { RemoteRef.class }; > > private Util() { > } > @@ -143,7 +143,7 @@ > } > > final ClassLoader loader = implClass.getClassLoader(); > - final Class[] interfaces = getRemoteInterfaces(implClass); > + final Class[] interfaces = getRemoteInterfaces(implClass); > final InvocationHandler handler = > new RemoteObjectInvocationHandler(clientRef); > -------------- next part -------------- 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 joel.franck at oracle.com Tue Nov 12 12:20:52 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Tue, 12 Nov 2013 13:20:52 +0100 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <5281F961.5000900@univ-mlv.fr> References: <5281F4B4.50602@oracle.com> <5281FA17.3030700@oracle.com> <5281F961.5000900@univ-mlv.fr> Message-ID: <20131112122052.GI17332@oracle.com> This also allows you to get rid of the raw type suppression I think, the attached code compiles. Thanks Remi, cheers /Joel diff --git a/src/share/classes/java/lang/reflect/Proxy.java b/src/share/classes/java/lang/reflect/Proxy.java --- a/src/share/classes/java/lang/reflect/Proxy.java +++ b/src/share/classes/java/lang/reflect/Proxy.java @@ -490,13 +490,14 @@ * a key used for proxy class with any number of implemented interfaces * (used here for 3 or more only) */ + @SuppressWarnings("unchecked") private static final class KeyX { private final int hash; private final WeakReference>[] refs; KeyX(Class[] interfaces) { hash = Arrays.hashCode(interfaces); - refs = new WeakReference[interfaces.length]; + refs = (WeakReference>[]) new WeakReference[interfaces.length]; for (int i = 0; i < interfaces.length; i++) { refs[i] = new WeakReference<>(interfaces[i]); } On 2013-11-12, Remi Forax wrote: > On 11/12/2013 10:51 AM, Chris Hegarty wrote: > >Looks ok to me Joe. > > > >-Chris. > > A small issue, > refs = (WeakReference>[])new WeakReference[interfaces.length]; > should be > refs = (WeakReference>[])new > WeakReference[interfaces.length]; > > otherwise, looks good. > > R?mi > > > > >On 12/11/13 09:28, Joe Darcy wrote: > >>Hello, > >> > >>Please review the patch below which would remove another batch of raw > >>type javac lint warnings from the core libraries. > >> > >>No signatures of public or protected methods in the Java SE > >>specification have been modified. Regression tests in affected > >>areas pass. > >> > >>Thanks, > >> > >>-Joe > >> > >>diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectOutputStream.java > >>--- a/src/share/classes/java/io/ObjectOutputStream.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/io/ObjectOutputStream.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -1248,7 +1248,7 @@ > >> handles.assign(unshared ? null : desc); > >> > >> Class cl = desc.forClass(); > >>- Class[] ifaces = cl.getInterfaces(); > >>+ Class[] ifaces = cl.getInterfaces(); > >> bout.writeInt(ifaces.length); > >> for (int i = 0; i < ifaces.length; i++) { > >> bout.writeUTF(ifaces[i].getName()); > >>diff -r 9fcb07df1c92 src/share/classes/java/io/ObjectStreamClass.java > >>--- a/src/share/classes/java/io/ObjectStreamClass.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/io/ObjectStreamClass.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -1,5 +1,5 @@ > >> /* > >>- * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights > >>reserved. > >>+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights > >>reserved. > >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >> * > >> * This code is free software; you can redistribute it and/or > >>modify it > >>@@ -1746,7 +1746,7 @@ > >> dout.writeUTF("()V"); > >> } > >> > >>- Constructor[] cons = cl.getDeclaredConstructors(); > >>+ Constructor[] cons = cl.getDeclaredConstructors(); > >> MemberSignature[] consSigs = new > >>MemberSignature[cons.length]; > >> for (int i = 0; i < cons.length; i++) { > >> consSigs[i] = new MemberSignature(cons[i]); > >>diff -r 9fcb07df1c92 src/share/classes/java/lang/reflect/Proxy.java > >>--- a/src/share/classes/java/lang/reflect/Proxy.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/lang/reflect/Proxy.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -494,9 +494,10 @@ > >> private final int hash; > >> private final WeakReference>[] refs; > >> > >>+ @SuppressWarnings({"rawtypes", "unchecked"}) > >> KeyX(Class[] interfaces) { > >> hash = Arrays.hashCode(interfaces); > >>- refs = new WeakReference[interfaces.length]; > >>+ refs = (WeakReference>[])new > >>WeakReference[interfaces.length]; > >> for (int i = 0; i < interfaces.length; i++) { > >> refs[i] = new WeakReference<>(interfaces[i]); > >> } > >>diff -r 9fcb07df1c92 src/share/classes/java/nio/file/TempFileHelper.java > >>--- a/src/share/classes/java/nio/file/TempFileHelper.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/nio/file/TempFileHelper.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -81,7 +81,7 @@ > >> String prefix, > >> String suffix, > >> boolean createDirectory, > >>- FileAttribute[] attrs) > >>+ FileAttribute[] attrs) > >> throws IOException > >> { > >> if (prefix == null) > >>@@ -155,7 +155,7 @@ > >> static Path createTempFile(Path dir, > >> String prefix, > >> String suffix, > >>- FileAttribute[] attrs) > >>+ FileAttribute[] attrs) > >> throws IOException > >> { > >> return create(dir, prefix, suffix, false, attrs); > >>@@ -167,7 +167,7 @@ > >> */ > >> static Path createTempDirectory(Path dir, > >> String prefix, > >>- FileAttribute[] attrs) > >>+ FileAttribute[] attrs) > >> throws IOException > >> { > >> return create(dir, prefix, null, true, attrs); > >>diff -r 9fcb07df1c92 src/share/classes/java/util/IdentityHashMap.java > >>--- a/src/share/classes/java/util/IdentityHashMap.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/util/IdentityHashMap.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -1243,7 +1243,7 @@ > >> if (ti >= size) { > >> throw new ConcurrentModificationException(); > >> } > >>- a[ti++] = (T) new > >>AbstractMap.SimpleEntry(unmaskNull(key), tab[si + 1]); > >>+ a[ti++] = (T) new > >>AbstractMap.SimpleEntry<>(unmaskNull(key), tab[si + 1]); > >> } > >> } > >> // fewer elements than expected or concurrent modification > >>from other thread detected > >>diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logger.java > >>--- a/src/share/classes/java/util/logging/Logger.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/util/logging/Logger.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -351,7 +351,7 @@ > >> ? caller.getClassLoader() > >> : null); > >> if (callersClassLoader != null) { > >>- this.callersClassLoaderRef = new > >>WeakReference(callersClassLoader); > >>+ this.callersClassLoaderRef = new > >>WeakReference<>(callersClassLoader); > >> } > >> } > >> > >>diff -r 9fcb07df1c92 src/share/classes/java/util/logging/Logging.java > >>--- a/src/share/classes/java/util/logging/Logging.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/java/util/logging/Logging.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -1,5 +1,5 @@ > >> /* > >>- * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights > >>reserved. > >>+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > >>reserved. > >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >> * > >> * This code is free software; you can redistribute it and/or > >>modify it > >>@@ -55,11 +55,11 @@ > >> } > >> > >> public List getLoggerNames() { > >>- Enumeration loggers = logManager.getLoggerNames(); > >>+ Enumeration loggers = logManager.getLoggerNames(); > >> ArrayList array = new ArrayList<>(); > >> > >> for (; loggers.hasMoreElements();) { > >>- array.add((String) loggers.nextElement()); > >>+ array.add(loggers.nextElement()); > >> } > >> return array; > >> } > >>diff -r 9fcb07df1c92 src/share/classes/sun/misc/Cleaner.java > >>--- a/src/share/classes/sun/misc/Cleaner.java Sat Nov 09 04:21:28 > >>2013 +0400 > >>+++ b/src/share/classes/sun/misc/Cleaner.java Tue Nov 12 00:51:15 > >>2013 -0800 > >>@@ -1,5 +1,5 @@ > >> /* > >>- * Copyright (c) 2003, 2008, Oracle and/or its affiliates. All rights > >>reserved. > >>+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights > >>reserved. > >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >> * > >> * This code is free software; you can redistribute it and/or > >>modify it > >>@@ -57,14 +57,14 @@ > >> */ > >> > >> public class Cleaner > >>- extends PhantomReference > >>+ extends PhantomReference > >> { > >> > >> // Dummy reference queue, needed because the PhantomReference > >>constructor > >> // insists that we pass a queue. Nothing will ever be placed on > >>this queue > >> // since the reference handler invokes cleaners explicitly. > >> // > >>- private static final ReferenceQueue dummyQueue = new > >>ReferenceQueue(); > >>+ private static final ReferenceQueue dummyQueue = new > >>ReferenceQueue<>(); > >> > >> // Doubly-linked list of live cleaners, which prevents the > >>cleaners > >> // themselves from being GC'd before their referents > >>@@ -119,6 +119,7 @@ > >> /** > >> * Creates a new cleaner. > >> * > >>+ * @param ob the referent object to be cleaned > >> * @param thunk > >> * The cleanup code to be run when the cleaner is > >>invoked. The > >> * cleanup code is run directly from the reference-handler > >>thread, > >>diff -r 9fcb07df1c92 src/share/classes/sun/misc/ProxyGenerator.java > >>--- a/src/share/classes/sun/misc/ProxyGenerator.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/sun/misc/ProxyGenerator.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -384,7 +384,7 @@ > >> private String className; > >> > >> /** proxy interfaces */ > >>- private Class[] interfaces; > >>+ private Class[] interfaces; > >> > >> /** proxy class access flags */ > >> private int accessFlags; > >>diff -r 9fcb07df1c92 src/share/classes/sun/rmi/rmic/Main.java > >>--- a/src/share/classes/sun/rmi/rmic/Main.java Sat Nov 09 04:21:28 > >>2013 +0400 > >>+++ b/src/share/classes/sun/rmi/rmic/Main.java Tue Nov 12 00:51:15 > >>2013 -0800 > >>@@ -494,7 +494,7 @@ > >> extDirsArg); > >> BatchEnvironment result = null; > >> try { > >>- Class[] ctorArgTypes = > >>{OutputStream.class,ClassPath.class,Main.class}; > >>+ Class[] ctorArgTypes = > >>{OutputStream.class,ClassPath.class,Main.class}; > >> Object[] ctorArgs = {out,classPath,this}; > >> Constructor constructor = > >> environmentClass.getConstructor(ctorArgTypes); > >>diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/LoaderHandler.java > >>--- a/src/share/classes/sun/rmi/server/LoaderHandler.java Sat Nov 09 > >>04:21:28 2013 +0400 > >>+++ b/src/share/classes/sun/rmi/server/LoaderHandler.java Tue Nov 12 > >>00:51:15 2013 -0800 > >>@@ -692,7 +692,7 @@ > >> * Define a proxy class in the given class loader. The proxy > >> * class will implement the given interfaces Classes. > >> */ > >>- private static Class loadProxyClass(ClassLoader loader, Class[] > >>interfaces) > >>+ private static Class loadProxyClass(ClassLoader loader, > >>Class[] interfaces) > >> throws ClassNotFoundException > >> { > >> try { > >>@@ -719,7 +719,7 @@ > >> */ > >> private static ClassLoader loadProxyInterfaces(String[] > >>interfaces, > >> ClassLoader loader, > >>- Class[] classObjs, > >>+ Class[] classObjs, > >> boolean[] > >>nonpublic) > >> throws ClassNotFoundException > >> { > >>diff -r 9fcb07df1c92 > >>src/share/classes/sun/rmi/server/UnicastServerRef.java > >>--- a/src/share/classes/sun/rmi/server/UnicastServerRef.java Sat Nov > >>09 04:21:28 2013 +0400 > >>+++ b/src/share/classes/sun/rmi/server/UnicastServerRef.java Tue Nov > >>12 00:51:15 2013 -0800 > >>@@ -299,7 +299,7 @@ > >> logCall(obj, method); > >> > >> // unmarshal parameters > >>- Class[] types = method.getParameterTypes(); > >>+ Class[] types = method.getParameterTypes(); > >> Object[] params = new Object[types.length]; > >> > >> try { > >>diff -r 9fcb07df1c92 src/share/classes/sun/rmi/server/Util.java > >>--- a/src/share/classes/sun/rmi/server/Util.java Sat Nov 09 04:21:28 > >>2013 +0400 > >>+++ b/src/share/classes/sun/rmi/server/Util.java Tue Nov 12 00:51:15 > >>2013 -0800 > >>@@ -87,7 +87,7 @@ > >> Collections.synchronizedMap(new WeakHashMap, > >>Void>(11)); > >> > >> /** parameter types for stub constructor */ > >>- private static final Class[] stubConsParamTypes = { > >>RemoteRef.class }; > >>+ private static final Class[] stubConsParamTypes = { > >>RemoteRef.class }; > >> > >> private Util() { > >> } > >>@@ -143,7 +143,7 @@ > >> } > >> > >> final ClassLoader loader = implClass.getClassLoader(); > >>- final Class[] interfaces = getRemoteInterfaces(implClass); > >>+ final Class[] interfaces = getRemoteInterfaces(implClass); > >> final InvocationHandler handler = > >> new RemoteObjectInvocationHandler(clientRef); > >> > From mcnepp02 at googlemail.com Tue Nov 12 13:51:11 2013 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Tue, 12 Nov 2013 14:51:11 +0100 Subject: AtomicReference.compareAndSet Oversight? Message-ID: While testing the methods added to the "Atomic" classes for Java 8, I was puzzled that I couldn't find the one method that I've been missing most in AtomicReference: boolean compareAndSet(V expect, Supplier supplier); Obviously, this would help implement a very efficient atomic "create-if-not-present" compound operation. Was it a deliberate decision to leave that one out? From erik.gahlin at oracle.com Tue Nov 12 13:51:03 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Tue, 12 Nov 2013 13:51:03 +0000 Subject: hg: jdk8/tl/jdk: 8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently Message-ID: <20131112135120.AA67362538@hg.openjdk.java.net> Changeset: 41dcb0c2e194 Author: egahlin Date: 2013-11-12 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41dcb0c2e194 8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently Reviewed-by: sla, jbachorik ! test/javax/management/monitor/ThreadPoolAccTest.java From vitalyd at gmail.com Tue Nov 12 14:12:16 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 12 Nov 2013 09:12:16 -0500 Subject: AtomicReference.compareAndSet Oversight? In-Reply-To: References: Message-ID: This would have to devolve into a TTAS implementation in order to avoid calling the supplier in cases where AR != expected. Otherwise, hardware needs the reference for the CAS. TTAS isn't that common, I think. Sent from my phone On Nov 12, 2013 8:51 AM, "Gernot Neppert" wrote: > While testing the methods added to the "Atomic" classes for Java 8, > I was puzzled that I couldn't find the one method that I've been missing > most in AtomicReference: > > boolean compareAndSet(V expect, Supplier supplier); > > Obviously, this would help implement a very efficient atomic > "create-if-not-present" compound operation. > Was it a deliberate decision to leave that one out? > From joel.franck at oracle.com Tue Nov 12 14:25:07 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Tue, 12 Nov 2013 15:25:07 +0100 Subject: declaring class of a default method Was: Bug 8027734 In-Reply-To: <52812E35.605@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> <52812E35.605@oracle.com> Message-ID: <20131112142507.GK17332@oracle.com> Hi Yumin, Basically this is due to a difference in declaring class for a Method representing a default method vs a normal Method. On 2013-11-11, Yumin Qi wrote: > Hi, Joel > > This bug is a SQE testing bug, see > https://bugs.openjdk.java.net/browse/JDK-8027734 > > > I have commented with the exception stacktrace. > This is easy to reproduce without VM sqe frameworks: p1/I.java: package p1; interface I { default void m() { System.out.println("Foo!"); } } p2/J.java: package p1; public interface J extends I {} p2/C.java: package p2; import p1.J; import java.lang.reflect.*; public class C { public static void main(String[] args) throws Exception { Method m = J.class.getMethod("m", (Class[])null); System.out.println(m + " declaring class: " + m.getDeclaringClass()); m.invoke(new J() {}); } } Compiling and running this will print: $ java p2.C public default void p1.I.m() declaring class: interface p1.I Exception in thread "main" java.lang.IllegalAccessException: Class p2.C can not access a member of class p1.I with modifiers "public" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) at java.lang.reflect.Method.invoke(Method.java:476) at p2.C.main(C.java:8) Note that the delcaring class of m is "interface p1.I". Changing this to classes instead: package p3; class A { public void m() { System.out.println("Foo!"); } } package p3; public class B extends A {} package p4; import p3.B; import java.lang.reflect.*; public class C2 { public static void main(String[] args) throws Exception { Method m = B.class.getMethod("m", (Class[])null); System.out.println(m + " declaring class: " + m.getDeclaringClass()); m.invoke(new B() {}); } } And running this gives: java p4.C2 public void p3.B.m() declaring class: class p3.B Foo! Note that even though m is lexically declared in class A m.getDeclaringClass() outputs _p3.B_ as it's declaring class. I'm not sure how we should fix this, but my first impression is that the VM is wrong here when creating the default method Method in the interface example. cheers /Joel From vitalyd at gmail.com Tue Nov 12 14:45:11 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 12 Nov 2013 09:45:11 -0500 Subject: Optimization of java.io.DataInputStream In-Reply-To: References: Message-ID: Interesting - was this file codegen'd or something? Why are these nop shifts there? Anyway, I'd expect JIT does the right thing here and doesn't actually issue this instruction. Are you optimizing for interpreter or meta data size then? Sent from my phone On Nov 12, 2013 3:45 AM, "Alex Yursha" wrote: > The following methods in java.io.DataInputStream perform right shift to > zero positions in their implementations: > - short readShort() > - int readUnsignedShort() > - char readChar() > - int readInt() > - long readLong() > - String readUTF(DataInput in) > > For example: > > public final short readShort() throws IOException { > int ch1 = in.read(); > int ch2 = in.read(); > if ((ch1 | ch2) < 0) > throw new EOFException(); > return (short)((ch1 << 8) + *(ch2 << 0)*); > } > > It can be optimizied as follows: > > public final short readShort() throws IOException { > int ch1 = in.read(); > int ch2 = in.read(); > if ((ch1 | ch2) < 0) > throw new EOFException(); > return (short)((ch1 << 8) + *ch2*); > } > > > This optimization saves 2 bytecode instructions in the class file code > arrays of each method mentioned above. > From alexyursha at gmail.com Tue Nov 12 14:51:38 2013 From: alexyursha at gmail.com (Alex Yursha) Date: Tue, 12 Nov 2013 17:51:38 +0300 Subject: Optimization of java.io.DataInputStream In-Reply-To: References: Message-ID: I have no idea whether JIT compiler will eliminate these nop shifts, but as I said each such shift brings two redundant bytecode instructions for the virtual machine. It think this tiny optimization can benefit both interpreter and class file size. On Tue, Nov 12, 2013 at 5:45 PM, Vitaly Davidovich wrote: > Interesting - was this file codegen'd or something? Why are these nop > shifts there? > > Anyway, I'd expect JIT does the right thing here and doesn't actually > issue this instruction. Are you optimizing for interpreter or meta data > size then? > > Sent from my phone > On Nov 12, 2013 3:45 AM, "Alex Yursha" wrote: > >> The following methods in java.io.DataInputStream perform right shift to >> zero positions in their implementations: >> - short readShort() >> - int readUnsignedShort() >> - char readChar() >> - int readInt() >> - long readLong() >> - String readUTF(DataInput in) >> >> For example: >> >> public final short readShort() throws IOException { >> int ch1 = in.read(); >> int ch2 = in.read(); >> if ((ch1 | ch2) < 0) >> throw new EOFException(); >> return (short)((ch1 << 8) + *(ch2 << 0)*); >> >> } >> >> It can be optimizied as follows: >> >> public final short readShort() throws IOException { >> int ch1 = in.read(); >> int ch2 = in.read(); >> if ((ch1 | ch2) < 0) >> throw new EOFException(); >> return (short)((ch1 << 8) + *ch2*); >> >> } >> >> >> This optimization saves 2 bytecode instructions in the class file code >> arrays of each method mentioned above. >> > From roger.riggs at oracle.com Tue Nov 12 14:57:33 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 12 Nov 2013 09:57:33 -0500 Subject: Optimization of java.io.DataInputStream In-Reply-To: References: Message-ID: <528241DD.8000607@oracle.com> Hi, At the source level the style makes it clear where the data is to be aligned. There many other places that use that style "<< 0" to indicate alignment of the data when assembling a whole from parts. It is assumed the compiler/runtime will omit unnecessary operations; the compiler does not. $.02, Roger On 11/12/2013 9:45 AM, Vitaly Davidovich wrote: > Interesting - was this file codegen'd or something? Why are these nop > shifts there? > > Anyway, I'd expect JIT does the right thing here and doesn't actually issue > this instruction. Are you optimizing for interpreter or meta data size > then? > > Sent from my phone > On Nov 12, 2013 3:45 AM, "Alex Yursha" wrote: > >> The following methods in java.io.DataInputStream perform right shift to >> zero positions in their implementations: >> - short readShort() >> - int readUnsignedShort() >> - char readChar() >> - int readInt() >> - long readLong() >> - String readUTF(DataInput in) >> >> For example: >> >> public final short readShort() throws IOException { >> int ch1 = in.read(); >> int ch2 = in.read(); >> if ((ch1 | ch2) < 0) >> throw new EOFException(); >> return (short)((ch1 << 8) + *(ch2 << 0)*); >> } >> >> It can be optimizied as follows: >> >> public final short readShort() throws IOException { >> int ch1 = in.read(); >> int ch2 = in.read(); >> if ((ch1 | ch2) < 0) >> throw new EOFException(); >> return (short)((ch1 << 8) + *ch2*); >> } >> >> >> This optimization saves 2 bytecode instructions in the class file code >> arrays of each method mentioned above. >> From vitalyd at gmail.com Tue Nov 12 15:00:10 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 12 Nov 2013 10:00:10 -0500 Subject: Optimization of java.io.DataInputStream In-Reply-To: <528241DD.8000607@oracle.com> References: <528241DD.8000607@oracle.com> Message-ID: Roger, I think a simple comment is better than leaving head scratching code behind, especially since it'll impact interpreter and byte code size. Sent from my phone On Nov 12, 2013 9:58 AM, "roger riggs" wrote: > Hi, > > At the source level the style makes it clear where the data is to be > aligned. > There many other places that use that style "<< 0" to indicate alignment > of the data > when assembling a whole from parts. > It is assumed the compiler/runtime will omit unnecessary operations; the > compiler does not. > > $.02, Roger > > On 11/12/2013 9:45 AM, Vitaly Davidovich wrote: > >> Interesting - was this file codegen'd or something? Why are these nop >> shifts there? >> >> Anyway, I'd expect JIT does the right thing here and doesn't actually >> issue >> this instruction. Are you optimizing for interpreter or meta data size >> then? >> >> Sent from my phone >> On Nov 12, 2013 3:45 AM, "Alex Yursha" wrote: >> >> The following methods in java.io.DataInputStream perform right shift to >>> zero positions in their implementations: >>> - short readShort() >>> - int readUnsignedShort() >>> - char readChar() >>> - int readInt() >>> - long readLong() >>> - String readUTF(DataInput in) >>> >>> For example: >>> >>> public final short readShort() throws IOException { >>> int ch1 = in.read(); >>> int ch2 = in.read(); >>> if ((ch1 | ch2) < 0) >>> throw new EOFException(); >>> return (short)((ch1 << 8) + *(ch2 << 0)*); >>> } >>> >>> It can be optimizied as follows: >>> >>> public final short readShort() throws IOException { >>> int ch1 = in.read(); >>> int ch2 = in.read(); >>> if ((ch1 | ch2) < 0) >>> throw new EOFException(); >>> return (short)((ch1 << 8) + *ch2*); >>> } >>> >>> >>> This optimization saves 2 bytecode instructions in the class file code >>> arrays of each method mentioned above. >>> >>> > From alexyursha at gmail.com Tue Nov 12 15:12:12 2013 From: alexyursha at gmail.com (Alex Yursha) Date: Tue, 12 Nov 2013 18:12:12 +0300 Subject: Optimization of java.io.DataInputStream In-Reply-To: References: <528241DD.8000607@oracle.com> Message-ID: Well, I agree that the code is more readable when we use shift consistently, if you think it is worth some redundant bytes in a class file. On Tue, Nov 12, 2013 at 6:00 PM, Vitaly Davidovich wrote: > Roger, > > I think a simple comment is better than leaving head scratching code > behind, especially since it'll impact interpreter and byte code size. > > Sent from my phone > On Nov 12, 2013 9:58 AM, "roger riggs" wrote: > > > Hi, > > > > At the source level the style makes it clear where the data is to be > > aligned. > > There many other places that use that style "<< 0" to indicate alignment > > of the data > > when assembling a whole from parts. > > It is assumed the compiler/runtime will omit unnecessary operations; the > > compiler does not. > > > > $.02, Roger > > > > On 11/12/2013 9:45 AM, Vitaly Davidovich wrote: > > > >> Interesting - was this file codegen'd or something? Why are these nop > >> shifts there? > >> > >> Anyway, I'd expect JIT does the right thing here and doesn't actually > >> issue > >> this instruction. Are you optimizing for interpreter or meta data size > >> then? > >> > >> Sent from my phone > >> On Nov 12, 2013 3:45 AM, "Alex Yursha" wrote: > >> > >> The following methods in java.io.DataInputStream perform right shift to > >>> zero positions in their implementations: > >>> - short readShort() > >>> - int readUnsignedShort() > >>> - char readChar() > >>> - int readInt() > >>> - long readLong() > >>> - String readUTF(DataInput in) > >>> > >>> For example: > >>> > >>> public final short readShort() throws IOException { > >>> int ch1 = in.read(); > >>> int ch2 = in.read(); > >>> if ((ch1 | ch2) < 0) > >>> throw new EOFException(); > >>> return (short)((ch1 << 8) + *(ch2 << 0)*); > >>> } > >>> > >>> It can be optimizied as follows: > >>> > >>> public final short readShort() throws IOException { > >>> int ch1 = in.read(); > >>> int ch2 = in.read(); > >>> if ((ch1 | ch2) < 0) > >>> throw new EOFException(); > >>> return (short)((ch1 << 8) + *ch2*); > >>> } > >>> > >>> > >>> This optimization saves 2 bytecode instructions in the class file code > >>> arrays of each method mentioned above. > >>> > >>> > > > From vitalyd at gmail.com Tue Nov 12 15:15:13 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 12 Nov 2013 10:15:13 -0500 Subject: Optimization of java.io.DataInputStream In-Reply-To: References: <528241DD.8000607@oracle.com> Message-ID: So the locals can be called hi and lo, and it's very readable. Adding nop shifts would only be ok, IMHO, if it had zero cost all around (other than source being slightly larger). Sent from my phone On Nov 12, 2013 10:12 AM, "Alex Yursha" wrote: > Well, I agree that the code is more readable when we use shift > consistently, if you think it is worth some redundant bytes in a class file. > > > On Tue, Nov 12, 2013 at 6:00 PM, Vitaly Davidovich wrote: > >> Roger, >> >> I think a simple comment is better than leaving head scratching code >> behind, especially since it'll impact interpreter and byte code size. >> >> Sent from my phone >> On Nov 12, 2013 9:58 AM, "roger riggs" wrote: >> >> > Hi, >> > >> > At the source level the style makes it clear where the data is to be >> > aligned. >> > There many other places that use that style "<< 0" to indicate alignment >> > of the data >> > when assembling a whole from parts. >> > It is assumed the compiler/runtime will omit unnecessary operations; the >> > compiler does not. >> > >> > $.02, Roger >> > >> > On 11/12/2013 9:45 AM, Vitaly Davidovich wrote: >> > >> >> Interesting - was this file codegen'd or something? Why are these nop >> >> shifts there? >> >> >> >> Anyway, I'd expect JIT does the right thing here and doesn't actually >> >> issue >> >> this instruction. Are you optimizing for interpreter or meta data size >> >> then? >> >> >> >> Sent from my phone >> >> On Nov 12, 2013 3:45 AM, "Alex Yursha" wrote: >> >> >> >> The following methods in java.io.DataInputStream perform right shift >> to >> >>> zero positions in their implementations: >> >>> - short readShort() >> >>> - int readUnsignedShort() >> >>> - char readChar() >> >>> - int readInt() >> >>> - long readLong() >> >>> - String readUTF(DataInput in) >> >>> >> >>> For example: >> >>> >> >>> public final short readShort() throws IOException { >> >>> int ch1 = in.read(); >> >>> int ch2 = in.read(); >> >>> if ((ch1 | ch2) < 0) >> >>> throw new EOFException(); >> >>> return (short)((ch1 << 8) + *(ch2 << 0)*); >> >>> } >> >>> >> >>> It can be optimizied as follows: >> >>> >> >>> public final short readShort() throws IOException { >> >>> int ch1 = in.read(); >> >>> int ch2 = in.read(); >> >>> if ((ch1 | ch2) < 0) >> >>> throw new EOFException(); >> >>> return (short)((ch1 << 8) + *ch2*); >> >>> } >> >>> >> >>> >> >>> This optimization saves 2 bytecode instructions in the class file code >> >>> arrays of each method mentioned above. >> >>> >> >>> >> > >> > > From stuart.marks at oracle.com Tue Nov 12 15:30:33 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Nov 2013 16:30:33 +0100 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <527EFB4B.1010502@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> Message-ID: <52824999.70501@oracle.com> Hi Tristan, (Sorry, for the delay; I'm traveling) I think the current package (bench.rmi and bench.serial) organization makes good sense, and I don't want to change it. The need to shuffle things around to different packages indicates a factoring error. In this case the culprit is TestLibrary, which is in the unnamed package. The constraints are: (1) bench.rmi.* benchmarks depend on Main (2) Main depends on TestLibrary From (1), Main wants to be in bench.rmi. But (2) wants Main to be in the unnamed package, since it can't get at TestLibrary otherwise. Eventually we want to move TestLibrary into a named package. (This is JDK-8003358). But this involves updating almost all of the RMI tests, so we probably don't want to do that as part of this test fix. The alternative is to put in a short-term fix (i.e., a hack :-)) to deal with one of the dependencies. Since TestLibrary is causing the problem, which will eventually be fixed, it makes sense to quick-fix the way Main depends on TestLibrary. This would be cleaned up when TestLibrary gets moved into a named package. A class in a named package cannot import classes from the unnamed package, but it can load them. So, one could leave the benchmarks and Main in bench.rmi, and use a few lines of reflection code to load TestLibrary and to call getUnusedRandomPort() on it. There's only one call to TestLibrary.getUnusedRandomPort() from Main, so a few lines of reflective code could be added right there. So, that's my recommendation. If you do this you can leave all of the benchmarks and the Main class in bench.rmi and avoid all the file moves. Thanks, s'marks On 11/10/13 4:19 AM, Tristan Yan wrote: > Hi Stuart > I tried your suggestion but unfortunately all the benchmarks have dependencies > to Main class because they need get stub from server. I suggest we move the > benchmark tests to unnamed package unless we do want to put TestLibrary into a > named package right now. > Please let me know if you have objection on this. > Thank you > Tristan > > On 11/09/2013 02:28 AM, Stuart Marks wrote: >> Hi Tristan, >> >> Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed >> package. Classes in a named package cannot import classes from the unnamed >> package. We've run into problems with this before. Eventually, we should move >> TestLibrary a named package. >> >> I think it's possible to work around this without too much difficulty. Note >> that classes in the unnamed package can import classes from named packages. >> So, perhaps you can put the RmiBench main class in the unnamed package so it >> has access to TestLibrary. Then have the benchmarks themselves in the >> bench.rmi package. The config file already references the benchmarks by fully >> qualified class name (e.g., "bench.rmi.NullCalls") so with a bit of tinkering >> you ought to be able to get this to work. >> >> s'marks >> >> On 11/8/13 3:00 AM, Tristan Yan wrote: >>> Thank you, Stuart >>> There is one review point I want to ask you opinion. Which is the reason that >>> I moved from test/java/rmi/reliability/benchmark/bench/rmi to >>> test/java/rmi/reliability/benchmark is Main.java need access class >>> TestLibrary for supporting random port. TestLibrary is a unpackage class, I >>> couldn't find a way to let a class which has Package to access the class >>> without package. Do you have suggestion on that? >>> Thank you so much. >>> Tristan >>> >>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>> >>>> >>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>> Hi Everyone >>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>> >>>>> Description: >>>>> 1. Convert shell script test to Java program test. >>>>> 2. Using random server port by reusing Darryl Mocek's work to replace fixed >>>>> server port. >>>>> 3. Using java Process class to start client process. >>>>> 4. Also convert other shell script test runSerialBench.sh to java program >>>>> test also >>>> >>>> Hi Tristan, >>>> >>>> Several comments on this webrev. >>>> >>>> >>>> ** The original arrangement within the test/java/rmi/reliability/benchmark >>>> directory had the main benchmark files (scripts) at the top, some benchmark >>>> framework files in the "bench" subdirectory, and the actual RMI and >>>> serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>> >>>> The webrev moves all the RMI benchmarks to the top benchmark directory but >>>> leaves the serial benchmarks in bench/serial. The RMI benchmarks are now all >>>> cluttering the top directory, but the main serial benchmark test is now >>>> buried in the bench/serial directory. The nice organization that was there >>>> before is now spoiled. Is this rearrangement necessary in order to convert >>>> the scripts to Java? I would prefer the original arrangement be left in place. >>>> >>>> >>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>> >>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main -c config >>>> >>>> There is a subtle but serious problem here: the -server option is passed to >>>> the >>JVM<< and not as an argument to the main() method. The main() method >>>> gets neither a -server nor a -client argument, so its default "run mode" as >>>> defined by the benchmark itself is SAMEVM. This runs the client and server >>>> in the same JVM, which is different from the shell script, which ran >>>> separate client and server JVMs. >>>> >>>> >>>> ** The logic to process the -server argument still expects to take a port, >>>> even though the port is assigned automatically. So the obvious fix to the >>>> above, >>>> >>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server -c config >>>> >>>> doesn't work, since a port is missing. The logic to increment the argument >>>> index to collect the port argument should be removed. Also, the -server line >>>> should be restored to the usage message, but without the port argument. >>>> >>>> >>>> ** After this is done, the client's command line is constructed improperly. >>>> The command line ends up looking something like this: >>>> >>>> java client -cp Main client localhost:58583 -c config >>>> >>>> The word "client" appears twice, but what's really required is "-client" to >>>> appear as an argument after Main. >>>> >>>> >>>> ** The client is run using ProcessBuilder, which by default sends stdout and >>>> stderr to pipes to be read by the parent. But the parent never reads them, >>>> thus any messages from the client are never seen. The client is the one that >>>> emits the benchmark report, so its output needs to be seen. It might be >>>> sufficient to have the client inherit the parent's stdout and stderr. This >>>> might intermix the client's and server's output, but it's better than nothing. >>>> >>>> >>>> ** The config file is checked with the following code: >>>> >>>> try { >>>> confFile = args[i]; >>>> confstr = new FileInputStream(System.getProperty("test.src") >>>> + System.getProperty("file.separator") + confFile); >>>> } catch (IOException e) { >>>> die("Error: unable to open \"" + args[i] + "\""); >>>> } >>>> >>>> This is potentially misleading, as the message doesn't print the actual >>>> filename that was attempted to be opened. >>>> >>>> This is important, as the test.src property doesn't exist in the client JVM. >>>> >>>> Note that the original shell script passed full pathnames for the config >>>> file to both the client and the server. The new @run tag merely says "-c >>>> config" which redefines the config filename to be relative to the test.src >>>> directory. You could pass -Dtest.src=... to the client, but it seems like >>>> there should be something better than can be done. >>>> >>>> >>>> ** The client needs to have its security policy set up. This is missing from >>>> the construction of the client's command line. >>>> >>>> >>>> ** ProcessBuilder takes a List for its command; there is no need to >>>> turn the list into an array. >>>> >>>> >>>> ** In the benchmark main methods, code of the form, >>>> >>>> while (true) { >>>> runBenchmarks(); >>>> if (exitRequested) { >>>> System.exit(); >>>> } >>>> } >>>> >>>> was replaced with >>>> >>>> while (!exitRequested) { >>>> runBenchmarks(); >>>> } >>>> >>>> This is a subtle logic change, in that the former code always executed the >>>> loop at least once. It seems unlikely, but it's possible that a timer could >>>> set exitRequested before loop entry, resulting in the benchmark running zero >>>> times. I guess, if you really want to clean this up (we do need to avoid >>>> System.exit in jtreg tests), use a do-while loop instead. >>>> >>>> >>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>> ProblemList.txt. >>>> >>>> >>>> ** Remove the references to RMISecurityManager and just use SecurityManager. >>>> This is just general cleanup. (I deprecated RMISecurityManager last week.) :-) >>>> >>>> >>>> It would be good if you could fix up these issues and post another webrev. >>>> >>>> Thanks. >>>> >>>> s'marks >>>> >>>> >>>> >>>> >>>>> Thank you >>>>> Tristan >>>>> >>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>> I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>> on my research, it looks like the issue of fixed port was already addressed >>>>>>> by Stuart Marks in other RMI tests which are Java based. I would like to >>>>>>> reuse his solution, however it does not work for shell based tests. >>>>>> >>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>> >>>>>> Was the patch attached to your message? If so, it didn't get through. Most >>>>>> OpenJDK mailing lists strip off attachments before forwarding the message to >>>>>> the recipients. >>>>>> >>>>>>> 2. My recommendation would be to convert this shell script test into Java >>>>>>> based test and re-use the dynamic port allocation solution by Stuart >>>>>>> Marks to >>>>>>> address the issue >>>>>>> >>>>>>> 3. Also this test was written with server/client mode in shell script. In >>>>>>> the >>>>>>> past there have been sync issues between server/client which caused the test >>>>>>> to fail. If we convert the shell script into Java based test, it would avoid >>>>>>> using "sleep 10" mechanism to allow for server and client to start up and >>>>>>> also give us better control in synchronizing server and client. >>>>>> >>>>>> (Background for interested readers.) In general, yes, it's quite difficult to >>>>>> make reliable shell tests, especially for multi-process tests like this one. >>>>>> There is the unique port issue, and there is also the issue of how long for >>>>>> the client to wait until the server is ready. Error handling is also a >>>>>> problem, for example, if one of the JVMs gets an unexpected exception, it's >>>>>> easy for shell tests to mishandle this case. They might hang or erroneously >>>>>> report success. >>>>>> >>>>>> -- >>>>>> >>>>>> If this is a rewrite, it's probably fairly large, so you need to upload it >>>>>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> s'marks >>>>> >>> >> > From stuart.marks at oracle.com Tue Nov 12 15:38:01 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Nov 2013 16:38:01 +0100 Subject: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port In-Reply-To: <5280DE1A.4040708@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> Message-ID: <52824B59.9020406@oracle.com> Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" port range that's used by some RMI tests that have to used fixed ports. s'marks On 11/11/13 2:39 PM, Tristan Yan wrote: > Hi Stuart > Also there is one more solution, which is there is one > jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same function as > TestLibrary.getUnusedRandomPort() and it has named package. Do you mind I use > this one? > Since these two functions provide same functionality. Maybe we should think > about to merge them at the same time. > Thank you > Tristan > > On 11/10/2013 11:19 AM, Tristan Yan wrote: >> Hi Stuart >> I tried your suggestion but unfortunately all the benchmarks have dependencies >> to Main class because they need get stub from server. I suggest we move the >> benchmark tests to unnamed package unless we do want to put TestLibrary into a >> named package right now. >> Please let me know if you have objection on this. >> Thank you >> Tristan >> >> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>> Hi Tristan, >>> >>> Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed >>> package. Classes in a named package cannot import classes from the unnamed >>> package. We've run into problems with this before. Eventually, we should move >>> TestLibrary a named package. >>> >>> I think it's possible to work around this without too much difficulty. Note >>> that classes in the unnamed package can import classes from named packages. >>> So, perhaps you can put the RmiBench main class in the unnamed package so it >>> has access to TestLibrary. Then have the benchmarks themselves in the >>> bench.rmi package. The config file already references the benchmarks by fully >>> qualified class name (e.g., "bench.rmi.NullCalls") so with a bit of tinkering >>> you ought to be able to get this to work. >>> >>> s'marks >>> >>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>> Thank you, Stuart >>>> There is one review point I want to ask you opinion. Which is the reason >>>> that I moved from test/java/rmi/reliability/benchmark/bench/rmi to >>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>> TestLibrary for supporting random port. TestLibrary is a unpackage class, I >>>> couldn't find a way to let a class which has Package to access the class >>>> without package. Do you have suggestion on that? >>>> Thank you so much. >>>> Tristan >>>> >>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>> >>>>> >>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>> Hi Everyone >>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>> >>>>>> Description: >>>>>> 1. Convert shell script test to Java program test. >>>>>> 2. Using random server port by reusing Darryl Mocek's work to replace fixed >>>>>> server port. >>>>>> 3. Using java Process class to start client process. >>>>>> 4. Also convert other shell script test runSerialBench.sh to java program >>>>>> test also >>>>> >>>>> Hi Tristan, >>>>> >>>>> Several comments on this webrev. >>>>> >>>>> >>>>> ** The original arrangement within the test/java/rmi/reliability/benchmark >>>>> directory had the main benchmark files (scripts) at the top, some benchmark >>>>> framework files in the "bench" subdirectory, and the actual RMI and >>>>> serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>> >>>>> The webrev moves all the RMI benchmarks to the top benchmark directory but >>>>> leaves the serial benchmarks in bench/serial. The RMI benchmarks are now >>>>> all cluttering the top directory, but the main serial benchmark test is now >>>>> buried in the bench/serial directory. The nice organization that was there >>>>> before is now spoiled. Is this rearrangement necessary in order to convert >>>>> the scripts to Java? I would prefer the original arrangement be left in place. >>>>> >>>>> >>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>> >>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main -c config >>>>> >>>>> There is a subtle but serious problem here: the -server option is passed to >>>>> the >>JVM<< and not as an argument to the main() method. The main() method >>>>> gets neither a -server nor a -client argument, so its default "run mode" as >>>>> defined by the benchmark itself is SAMEVM. This runs the client and server >>>>> in the same JVM, which is different from the shell script, which ran >>>>> separate client and server JVMs. >>>>> >>>>> >>>>> ** The logic to process the -server argument still expects to take a port, >>>>> even though the port is assigned automatically. So the obvious fix to the >>>>> above, >>>>> >>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server -c config >>>>> >>>>> doesn't work, since a port is missing. The logic to increment the argument >>>>> index to collect the port argument should be removed. Also, the -server >>>>> line should be restored to the usage message, but without the port argument. >>>>> >>>>> >>>>> ** After this is done, the client's command line is constructed improperly. >>>>> The command line ends up looking something like this: >>>>> >>>>> java client -cp Main client localhost:58583 -c config >>>>> >>>>> The word "client" appears twice, but what's really required is "-client" to >>>>> appear as an argument after Main. >>>>> >>>>> >>>>> ** The client is run using ProcessBuilder, which by default sends stdout >>>>> and stderr to pipes to be read by the parent. But the parent never reads >>>>> them, thus any messages from the client are never seen. The client is the >>>>> one that emits the benchmark report, so its output needs to be seen. It >>>>> might be sufficient to have the client inherit the parent's stdout and >>>>> stderr. This might intermix the client's and server's output, but it's >>>>> better than nothing. >>>>> >>>>> >>>>> ** The config file is checked with the following code: >>>>> >>>>> try { >>>>> confFile = args[i]; >>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>> + System.getProperty("file.separator") + confFile); >>>>> } catch (IOException e) { >>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>> } >>>>> >>>>> This is potentially misleading, as the message doesn't print the actual >>>>> filename that was attempted to be opened. >>>>> >>>>> This is important, as the test.src property doesn't exist in the client JVM. >>>>> >>>>> Note that the original shell script passed full pathnames for the config >>>>> file to both the client and the server. The new @run tag merely says "-c >>>>> config" which redefines the config filename to be relative to the test.src >>>>> directory. You could pass -Dtest.src=... to the client, but it seems like >>>>> there should be something better than can be done. >>>>> >>>>> >>>>> ** The client needs to have its security policy set up. This is missing >>>>> from the construction of the client's command line. >>>>> >>>>> >>>>> ** ProcessBuilder takes a List for its command; there is no need to >>>>> turn the list into an array. >>>>> >>>>> >>>>> ** In the benchmark main methods, code of the form, >>>>> >>>>> while (true) { >>>>> runBenchmarks(); >>>>> if (exitRequested) { >>>>> System.exit(); >>>>> } >>>>> } >>>>> >>>>> was replaced with >>>>> >>>>> while (!exitRequested) { >>>>> runBenchmarks(); >>>>> } >>>>> >>>>> This is a subtle logic change, in that the former code always executed the >>>>> loop at least once. It seems unlikely, but it's possible that a timer could >>>>> set exitRequested before loop entry, resulting in the benchmark running >>>>> zero times. I guess, if you really want to clean this up (we do need to >>>>> avoid System.exit in jtreg tests), use a do-while loop instead. >>>>> >>>>> >>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>> ProblemList.txt. >>>>> >>>>> >>>>> ** Remove the references to RMISecurityManager and just use >>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>> RMISecurityManager last week.) :-) >>>>> >>>>> >>>>> It would be good if you could fix up these issues and post another webrev. >>>>> >>>>> Thanks. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> >>>>> >>>>>> Thank you >>>>>> Tristan >>>>>> >>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>> I am working on bug https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>> on my research, it looks like the issue of fixed port was already addressed >>>>>>>> by Stuart Marks in other RMI tests which are Java based. I would like to >>>>>>>> reuse his solution, however it does not work for shell based tests. >>>>>>> >>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>> >>>>>>> Was the patch attached to your message? If so, it didn't get through. Most >>>>>>> OpenJDK mailing lists strip off attachments before forwarding >>>>>>> Hi Stuart >>>>>>> Also there is one more solution, which is there is one >>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same >>>>>>> function as TestLibrary.getUnusedRandomPort() and it has named package. >>>>>>> Do you mind I use this one? >>>>>>> Since these two function provide same functionality. Maybe we should >>>>>>> think about to merge them. >>>>>>> Thank you >>>>>>> Tristan >>>>>>> >>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>> Hi Stuart >>>>>>>> I tried your suggestion but unfortunately all the benchmarks have >>>>>>>> dependencies to Main class because they need get stub from server. I >>>>>>>> suggest we move the benchmark tests to unnamed package unless we do want >>>>>>>> to put TestLibrary into a named package right now. >>>>>>>> Please let me know if you have objection on this. >>>>>>>> Thank you >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>> Hi Tristan, >>>>>>>>> >>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed >>>>>>>>> package. Classes in a named package cannot import classes from the >>>>>>>>> unnamed package. We've run into problems with this before. Eventually, >>>>>>>>> we should move TestLibrary a named package. >>>>>>>>> >>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>> Note that classes in the unnamed package can import classes from named >>>>>>>>> packages. So, perhaps you can put the RmiBench main class in the >>>>>>>>> unnamed package so it has access to TestLibrary. Then have the >>>>>>>>> benchmarks themselves in the bench.rmi package. The config file already >>>>>>>>> references the benchmarks by fully qualified class name (e.g., >>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able >>>>>>>>> to get this to work. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>>> >>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>> Thank you, Stuart >>>>>>>>>> There is one review point I want to ask you opinion. Which is the >>>>>>>>>> reason that I moved from test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need access class >>>>>>>>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>>>>>>>> class, I couldn't find a way to let a class which has Package to >>>>>>>>>> access the class without package. Do you have suggestion on that? >>>>>>>>>> Thank you so much. >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>> Hi Everyone >>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Description: >>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>>>>>>>> replace fixed >>>>>>>>>>>> server port. >>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>>>>>>>> program test also >>>>>>>>>>> >>>>>>>>>>> Hi Tristan, >>>>>>>>>>> >>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main benchmark >>>>>>>>>>> files (scripts) at the top, some benchmark framework files in the >>>>>>>>>>> "bench" subdirectory, and the actual RMI and serialization benchmarks >>>>>>>>>>> in bench/rmi and bench/serial subdirectories. >>>>>>>>>>> >>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. The RMI >>>>>>>>>>> benchmarks are now all cluttering the top directory, but the main >>>>>>>>>>> serial benchmark test is now buried in the bench/serial directory. >>>>>>>>>>> The nice organization that was there before is now spoiled. Is this >>>>>>>>>>> rearrangement necessary in order to convert the scripts to Java? I >>>>>>>>>>> would prefer the original arrangement be left in place. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>>>>>>>> >>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main -c >>>>>>>>>>> config >>>>>>>>>>> >>>>>>>>>>> There is a subtle but serious problem here: the -server option is >>>>>>>>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>>>>> The main() method gets neither a -server nor a -client argument, so >>>>>>>>>>> its default "run mode" as defined by the benchmark itself is SAMEVM. >>>>>>>>>>> This runs the client and server in the same JVM, which is different >>>>>>>>>>> from the shell script, which ran separate client and server JVMs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The logic to process the -server argument still expects to take a >>>>>>>>>>> port, even though the port is assigned automatically. So the obvious >>>>>>>>>>> fix to the above, >>>>>>>>>>> >>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server -c >>>>>>>>>>> config >>>>>>>>>>> >>>>>>>>>>> doesn't work, since a port is missing. The logic to increment the >>>>>>>>>>> argument index to collect the port argument should be removed. Also, >>>>>>>>>>> the -server line should be restored to the usage message, but without >>>>>>>>>>> the port argument. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** After this is done, the client's command line is constructed >>>>>>>>>>> improperly. The command line ends up looking something like this: >>>>>>>>>>> >>>>>>>>>>> java client -cp Main client localhost:58583 -c config >>>>>>>>>>> >>>>>>>>>>> The word "client" appears twice, but what's really required is >>>>>>>>>>> "-client" to appear as an argument after Main. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The client is run using ProcessBuilder, which by default sends >>>>>>>>>>> stdout and stderr to pipes to be read by the parent. But the parent >>>>>>>>>>> never reads them, thus any messages from the client are never seen. >>>>>>>>>>> The client is the one that emits the benchmark report, so its output >>>>>>>>>>> needs to be seen. It might be sufficient to have the client inherit >>>>>>>>>>> the parent's stdout and stderr. This might intermix the client's and >>>>>>>>>>> server's output, but it's better than nothing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>> >>>>>>>>>>> try { >>>>>>>>>>> confFile = args[i]; >>>>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This is potentially misleading, as the message doesn't print the >>>>>>>>>>> actual filename that was attempted to be opened. >>>>>>>>>>> >>>>>>>>>>> This is important, as the test.src property doesn't exist in the >>>>>>>>>>> client JVM. >>>>>>>>>>> >>>>>>>>>>> Note that the original shell script passed full pathnames for the >>>>>>>>>>> config file to both the client and the server. The new @run tag >>>>>>>>>>> merely says "-c config" which redefines the config filename to be >>>>>>>>>>> relative to the test.src directory. You could pass -Dtest.src=... to >>>>>>>>>>> the client, but it seems like there should be something better than >>>>>>>>>>> can be done. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The client needs to have its security policy set up. This is >>>>>>>>>>> missing from the construction of the client's command line. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** ProcessBuilder takes a List for its command; there is no >>>>>>>>>>> need to turn the list into an array. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>> >>>>>>>>>>> while (true) { >>>>>>>>>>> runBenchmarks(); >>>>>>>>>>> if (exitRequested) { >>>>>>>>>>> System.exit(); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> was replaced with >>>>>>>>>>> >>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>> runBenchmarks(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This is a subtle logic change, in that the former code always >>>>>>>>>>> executed the loop at least once. It seems unlikely, but it's possible >>>>>>>>>>> that a timer could set exitRequested before loop entry, resulting in >>>>>>>>>>> the benchmark running zero times. I guess, if you really want to >>>>>>>>>>> clean this up (we do need to avoid System.exit in jtreg tests), use a >>>>>>>>>>> do-while loop instead. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>>>>>>>> ProblemList.txt. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It would be good if you could fix up these issues and post another >>>>>>>>>>> webrev. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> s'marks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thank you >>>>>>>>>>>> Tristan >>>>>>>>>>>> >>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was already >>>>>>>>>>>>>> addressed >>>>>>>>>>>>>> by Stuart Marks in other RMI tests which are Java based. I would >>>>>>>>>>>>>> like to >>>>>>>>>>>>>> reuse his solution, however it does not work for shell based tests. >>>>>>>>>>>>> >>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>> >>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>>>>>>>> through. Most >>>>>>>>>>>>> OpenJDK mailing lists strip off attachments before forwarding the >>>>>>>>>>>>> message to >>>>>>>>>>>>> the recipients. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>>>>>>>> into Java >>>>>>>>>>>>>> based test and re-use the dynamic port allocation solution by >>>>>>>>>>>>>> Stuart Marks to >>>>>>>>>>>>>> address the issue >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Also this test was written with server/client mode in shell >>>>>>>>>>>>>> script. In the >>>>>>>>>>>>>> past there have been sync issues between server/client which >>>>>>>>>>>>>> caused the test >>>>>>>>>>>>>> to fail. If we convert the shell script into Java based test, it >>>>>>>>>>>>>> would avoid >>>>>>>>>>>>>> using "sleep 10" mechanism to allow for server and client to start >>>>>>>>>>>>>> up and >>>>>>>>>>>>>> also give us better control in synchronizing server and client. >>>>>>>>>>>>> >>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>>>>>>>> difficult to >>>>>>>>>>>>> make reliable shell tests, especially for multi-process tests like >>>>>>>>>>>>> this one. >>>>>>>>>>>>> There is the unique port issue, and there is also the issue of how >>>>>>>>>>>>> long for >>>>>>>>>>>>> the client to wait until the server is ready. Error handling is also a >>>>>>>>>>>>> problem, for example, if one of the JVMs gets an unexpected >>>>>>>>>>>>> exception, it's >>>>>>>>>>>>> easy for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>> erroneously >>>>>>>>>>>>> report success. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>>>>>>>> upload it >>>>>>>>>>>>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> s'marks >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> the message to >>>>>>> the recipients. >>>>>>> >>>>>>>> 2. My recommendation would be to convert this shell script test into Java >>>>>>>> based test and re-use the dynamic port allocation solution by Stuart >>>>>>>> Marks to >>>>>>>> address the issue >>>>>>>> >>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>> In the >>>>>>>> past there have been sync issues between server/client which caused the >>>>>>>> test >>>>>>>> to fail. If we convert the shell script into Java based test, it would >>>>>>>> avoid >>>>>>>> using "sleep 10" mechanism to allow for server and client to start up and >>>>>>>> also give us better control in synchronizing server and client. >>>>>>> >>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>> difficult to >>>>>>> make reliable shell tests, especially for multi-process tests like this one. >>>>>>> There is the unique port issue, and there is also the issue of how long for >>>>>>> the client to wait until the server is ready. Error handling is also a >>>>>>> problem, for example, if one of the JVMs gets an unexpected exception, it's >>>>>>> easy for shell tests to mishandle this case. They might hang or erroneously >>>>>>> report success. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> If this is a rewrite, it's probably fairly large, so you need to upload it >>>>>>> somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> s'marks >>>>>> >>>> >>> >> > From stuart.marks at oracle.com Tue Nov 12 16:02:46 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Nov 2013 17:02:46 +0100 Subject: 8028027: serialver should emit declaration with the 'private' modifier In-Reply-To: References: <527D31DF.3030106@oracle.com> Message-ID: <52825126.6010506@oracle.com> Hi Yuri, I don't see any consistency issue, since serialver and javap are intended for different purposes. I checked with a couple reviewers from earlier in this thread and they're ok with the change as is, without the additional reflective code to pick up modifiers from an existing declaration, so I've pushed the original change. Thanks for the comments though. s'marks On 11/8/13 9:52 PM, Yuri Gaevsky wrote: > Stuart, > > Sorry, but such inconsistency between serialver/javap is a bug (IMHO, of course). > >> If there happens to be a declaration in the class that, probably mistakenly, goes against this advice, serialver shouldn't emit a line that perpetuates this mistake. > > I would argue that for any real-life API it's almost impossible to fix such explicitly-defined "bad" (i.e. public/protected) SVUID in any compatible way, so emitting 'private' will not help there, unfortunately. > > -Yuri > > -----Original Message----- > From: Stuart Marks [mailto:stuart.marks at oracle.com] > Sent: Friday, November 8, 2013 10:48 PM > To: Yuri Gaevsky > Cc: Alan Bateman; core-libs-dev > Subject: Re: 8028027: serialver should emit declaration with the 'private' modifier > > On 11/8/13 7:20 AM, Yuri Gaevsky wrote: >>> Well, it would be more consistent to check for existence of protected or public serialVersionUID with Reflection API and change the serialver output accordingly. >> >> Please see suggested fix and its output below. > > This change isn't consistent with the intent of the 'serialver' utility. Its intent is to produce a declaration that's "suitable for copying into an evolving class." [1] (Clearly, this means the source code of a class.) The spec [2] "strongly advises" that serialVersionUID be private. As such, serialver should follow the strong advice given in the spec. > > If there happens to be a declaration in the class that, probably mistakenly, goes against this advice, serialver shouldn't emit a line that perpetuates this mistake. > > One can use "javap -v" to determine the presence of serialVersionUID field, including its modifiers, if that's what's desired. > > s'marks > > [1] http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/serialver.html > > [2] http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html > >> > >> Thanks, >> -Yuri >> >> $ serialver java.security.PublicKey >> java.security.PublicKey: public static final long serialVersionUID = 7187392471159151072L; >> >> $ serialver java.lang.Exception >> java.lang.Exception: static final long serialVersionUID = -3387516993124229948L; >> >> $ serialver java.lang.AssertionError >> java.lang.AssertionError: private static final long serialVersionUID = -5013299493970297370L; >> >> $ serialver javax.xml.ws.soap.SOAPFaultException >> javax.xml.ws.soap.SOAPFaultException: private static final long serialVersionUID = -104968645459360720L; >> >> >> $ hg diff >> diff --git a/src/share/classes/sun/tools/serialver/SerialVer.java >> b/src/share/classes/sun/tools/serialver/SerialVer.java >> --- a/src/share/classes/sun/tools/serialver/SerialVer.java >> +++ b/src/share/classes/sun/tools/serialver/SerialVer.java >> @@ -38,6 +38,7 @@ >> import java.net.MalformedURLException; >> import java.util.StringTokenizer; >> import sun.net.www.ParseUtil; >> +import java.lang.reflect.Modifier; >> >> public class SerialVer extends Applet { >> GridBagLayout gb; >> @@ -211,7 +212,17 @@ >> Class cl = Class.forName(classname, false, loader); >> ObjectStreamClass desc = ObjectStreamClass.lookup(cl); >> if (desc != null) { >> - return " static final long serialVersionUID = " + >> + String ams = ""; >> + try { >> + final int mod = >> + cl.getDeclaredField("serialVersionUID").getModifiers(); >> + ams = Modifier.isPublic(mod) ? "public" >> + : Modifier.isProtected(mod) ? "protected" >> + : Modifier.isPrivate(mod) ? "private" : ""; >> + } catch (NoSuchFieldException nsfe) { >> + ams = "private"; >> + } >> + return " " + ams + " static final long serialVersionUID = " + >> desc.getSerialVersionUID() + "L;"; >> } else { >> return null; >> From stuart.marks at oracle.com Tue Nov 12 15:59:42 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 12 Nov 2013 15:59:42 +0000 Subject: hg: jdk8/tl/jdk: 8028027: serialver should emit declaration with the 'private' modifier Message-ID: <20131112155956.6B77A62540@hg.openjdk.java.net> Changeset: f6012ca3bdd3 Author: smarks Date: 2013-11-12 16:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6012ca3bdd3 8028027: serialver should emit declaration with the 'private' modifier Reviewed-by: darcy, mchung, alanb, chegar ! src/share/classes/sun/tools/serialver/SerialVer.java From stuart.marks at oracle.com Tue Nov 12 16:43:25 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 Nov 2013 17:43:25 +0100 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <527AED79.2010702@oracle.com> References: <527AED79.2010702@oracle.com> Message-ID: <52825AAD.7030006@oracle.com> Hi all, Here's an updated version of the String spec change. Changes from the previous version address comments made by Brent Christian and David Holmes. Specifically: - Specify copyValueOf() overloads as "equivalent to" corresponding valueOf() overloads. - Remove extranous changes to subSequence() method - Clarify wording of concat() method doc. Bug report: https://bugs.openjdk.java.net/browse/JDK-7174936 Webrev: http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html Thanks! s'marks On 11/7/13 2:31 AM, Stuart Marks wrote: > Hi all, > > Please review the following spec changes to java.lang.String. > > In several places the specs mention returning "new" strings. This is > overspecified; it's sufficient to return "a" string that satisfies the required > properties. In some cases the current implementation doesn't create a new string > -- for example, substring(0) returns 'this' -- which is strictly a violation of > the spec. The solution is to relax the spec requirement to create new strings. > > Also, this change cleans up the specs for the copyValueOf() overloads to make > them identical to the corresponding valueOf() overloads. Previously, they were > gratuitously different. I think that some time in the dim, distant past, > probably before JDK 1.0, they had different semantics, but now they're > identical. The specs should say they're identical. > > This change is spec only, no code changes. > > Bug report: > > https://bugs.openjdk.java.net/browse/jdk-7174936 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ > > Specdiff: > > > http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html > > Thanks! > > s'marks From erik.gahlin at oracle.com Tue Nov 12 16:43:21 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Tue, 12 Nov 2013 16:43:21 +0000 Subject: hg: jdk8/tl/jdk: 6543856: MonitorVmStartTerminate.sh fails intermittently Message-ID: <20131112164335.7ADD962548@hg.openjdk.java.net> Changeset: 4cff9f59644f Author: egahlin Date: 2013-11-12 17:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cff9f59644f 6543856: MonitorVmStartTerminate.sh fails intermittently Reviewed-by: sla, dholmes ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/jvmstat/testlibrary/JavaProcess.java From Lance.Andersen at oracle.com Tue Nov 12 17:14:15 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Nov 2013 12:14:15 -0500 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <52825AAD.7030006@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> Message-ID: <19D629C8-2D1D-433C-9487-698077A6BD2A@oracle.com> The wording changes seem fine to me. Thanks for the specdiff as it made it much easier to review On Nov 12, 2013, at 11:43 AM, Stuart Marks wrote: > Hi all, > > Here's an updated version of the String spec change. Changes from the previous version address comments made by Brent Christian and David Holmes. Specifically: > > - Specify copyValueOf() overloads as "equivalent to" corresponding valueOf() overloads. > - Remove extranous changes to subSequence() method > - Clarify wording of concat() method doc. > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-7174936 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/ > > Specdiff: > > http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html > > Thanks! > > s'marks > > On 11/7/13 2:31 AM, Stuart Marks wrote: >> Hi all, >> >> Please review the following spec changes to java.lang.String. >> >> In several places the specs mention returning "new" strings. This is >> overspecified; it's sufficient to return "a" string that satisfies the required >> properties. In some cases the current implementation doesn't create a new string >> -- for example, substring(0) returns 'this' -- which is strictly a violation of >> the spec. The solution is to relax the spec requirement to create new strings. >> >> Also, this change cleans up the specs for the copyValueOf() overloads to make >> them identical to the corresponding valueOf() overloads. Previously, they were >> gratuitously different. I think that some time in the dim, distant past, >> probably before JDK 1.0, they had different semantics, but now they're >> identical. The specs should say they're identical. >> >> This change is spec only, no code changes. >> >> Bug report: >> >> https://bugs.openjdk.java.net/browse/jdk-7174936 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html >> >> Thanks! >> >> s'marks -------------- next part -------------- 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 erik.gahlin at oracle.com Tue Nov 12 17:14:54 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Tue, 12 Nov 2013 17:14:54 +0000 Subject: hg: jdk8/tl/jdk: 6849945: VM Periodic Task Thread CPU time = -1ns in HotspotThreadMBean.getInternalThreadCpuTimes() Message-ID: <20131112171507.B29336254A@hg.openjdk.java.net> Changeset: d9f827e4d20c Author: egahlin Date: 2013-11-12 18:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9f827e4d20c 6849945: VM Periodic Task Thread CPU time = -1ns in HotspotThreadMBean.getInternalThreadCpuTimes() Reviewed-by: sla ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java From joe.darcy at oracle.com Tue Nov 12 17:30:39 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Nov 2013 09:30:39 -0800 Subject: JDK 8 RFR: more core libs raw warnings cleanup In-Reply-To: <20131112122052.GI17332@oracle.com> References: <5281F4B4.50602@oracle.com> <5281FA17.3030700@oracle.com> <5281F961.5000900@univ-mlv.fr> <20131112122052.GI17332@oracle.com> Message-ID: <528265BF.3010507@oracle.com> I'll push with this improvement; thanks, -Joe On 11/12/2013 04:20 AM, Joel Borggren-Franck wrote: > This also allows you to get rid of the raw type suppression I think, the > attached code compiles. > > Thanks Remi, > > cheers > /Joel > > diff --git a/src/share/classes/java/lang/reflect/Proxy.java b/src/share/classes/java/lang/reflect/Proxy.java > --- a/src/share/classes/java/lang/reflect/Proxy.java > +++ b/src/share/classes/java/lang/reflect/Proxy.java > @@ -490,13 +490,14 @@ > * a key used for proxy class with any number of implemented interfaces > * (used here for 3 or more only) > */ > + @SuppressWarnings("unchecked") > private static final class KeyX { > private final int hash; > private final WeakReference>[] refs; > > KeyX(Class[] interfaces) { > hash = Arrays.hashCode(interfaces); > - refs = new WeakReference[interfaces.length]; > + refs = (WeakReference>[]) new WeakReference[interfaces.length]; > for (int i = 0; i < interfaces.length; i++) { > refs[i] = new WeakReference<>(interfaces[i]); > } > > On 2013-11-12, Remi Forax wrote: >> On 11/12/2013 10:51 AM, Chris Hegarty wrote: >>> Looks ok to me Joe. >>> >>> -Chris. >> A small issue, >> refs = (WeakReference>[])new WeakReference[interfaces.length]; >> should be >> refs = (WeakReference>[])new >> WeakReference[interfaces.length]; >> >> otherwise, looks good. >> >> R?mi >> >> From joe.darcy at oracle.com Tue Nov 12 17:44:54 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 12 Nov 2013 17:44:54 +0000 Subject: hg: jdk8/tl/jdk: 8028229: Fix more raw types lint warning in core libraries Message-ID: <20131112174506.65E876254F@hg.openjdk.java.net> Changeset: 69432cb5bca2 Author: darcy Date: 2013-11-12 09:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69432cb5bca2 8028229: Fix more raw types lint warning in core libraries Reviewed-by: chegar, forax, lancea, alanb, jfranck ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/sun/misc/Cleaner.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java From alan.bateman at oracle.com Tue Nov 12 17:39:38 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 12 Nov 2013 17:39:38 +0000 Subject: hg: jdk8/tl/jdk: 8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win) Message-ID: <20131112173950.14FC86254D@hg.openjdk.java.net> Changeset: 0c414ac10700 Author: alanb Date: 2013-11-12 17:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c414ac10700 8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win) Reviewed-by: chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! test/ProblemList.txt From daniel.fuchs at oracle.com Tue Nov 12 18:42:28 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Nov 2013 19:42:28 +0100 Subject: RFR: 8026952 Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id Message-ID: <52827694.4030205@oracle.com> Hi, This is a trivial fix to replace a wrong @bug id in TestRootLoggerLevel.java: https://bugs.openjdk.java.net/browse/JDK-8026952 I mistakenly put 8023163 (which I was investigating) instead of 8026499 (which is what I was actually fixing). -- daniel $ hg diff diff -r 41dcb0c2e194 test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java --- a/test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java +++ b/test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java @@ -33,7 +33,7 @@ /** * @test - * @bug 8023163 + * @bug 8026499 * @summary checks that Logger.getLogger("").setLevel() is working correctly. * @build TestRootLoggerLevel * @run main/othervm -Dtest.security=on TestRootLoggerLevel From roger.riggs at oracle.com Tue Nov 12 19:04:28 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 12 Nov 2013 19:04:28 +0000 Subject: hg: jdk8/tl/jdk: 8028014: Doclint warning/error cleanup in javax.management Message-ID: <20131112190440.BADB762550@hg.openjdk.java.net> Changeset: ebe27e1a2e2d Author: rriggs Date: 2013-11-12 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ebe27e1a2e2d 8028014: Doclint warning/error cleanup in javax.management Summary: Improve generated html by fixing doclint warnings Reviewed-by: sla, jbachorik ! src/share/classes/javax/management/AttributeList.java ! src/share/classes/javax/management/BooleanValueExp.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/DescriptorKey.java ! src/share/classes/javax/management/ImmutableDescriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/NumericValueExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/PersistentMBean.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetParser.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/relation/Relation.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/remote/JMXConnectionNotification.java ! src/share/classes/javax/management/remote/JMXConnector.java ! src/share/classes/javax/management/remote/JMXConnectorProvider.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java From mandy.chung at oracle.com Tue Nov 12 19:19:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Nov 2013 11:19:16 -0800 Subject: RFR: 8026952 Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id In-Reply-To: <52827694.4030205@oracle.com> References: <52827694.4030205@oracle.com> Message-ID: <52827F34.1080204@oracle.com> thumbs up. Mandy On 11/12/13 10:42 AM, Daniel Fuchs wrote: > Hi, > > This is a trivial fix to replace a wrong @bug id > in TestRootLoggerLevel.java: > > https://bugs.openjdk.java.net/browse/JDK-8026952 > > I mistakenly put 8023163 (which I was investigating) instead of > 8026499 (which is what I was actually fixing). > > -- daniel > > $ hg diff > diff -r 41dcb0c2e194 > test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java > --- > a/test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java > +++ > b/test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java > @@ -33,7 +33,7 @@ > > /** > * @test > - * @bug 8023163 > + * @bug 8026499 > * @summary checks that Logger.getLogger("").setLevel() is working > correctly. > * @build TestRootLoggerLevel > * @run main/othervm -Dtest.security=on TestRootLoggerLevel > > > From Alan.Bateman at oracle.com Tue Nov 12 19:28:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Nov 2013 19:28:08 +0000 Subject: RFR: 8026952 Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id In-Reply-To: <52827694.4030205@oracle.com> References: <52827694.4030205@oracle.com> Message-ID: <52828148.3070509@oracle.com> On 12/11/2013 18:42, Daniel Fuchs wrote: > Hi, > > This is a trivial fix to replace a wrong @bug id > in TestRootLoggerLevel.java: Looks fine. -Alan. From mandy.chung at oracle.com Tue Nov 12 19:29:28 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Nov 2013 11:29:28 -0800 Subject: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess Message-ID: <52828198.4070801@oracle.com> This is a simple code deletion in sun.misc.JavaAWTAccess and its implementation class: Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ This patch removes the methods from sun.misc.JavaAWTAccess that are no longer used. The only dependency remaining from core-libs to AppContext is the ability to obtain an opaque unique object to represent an applet context ifit is running in an applet environment. thanks Mandy From Lance.Andersen at oracle.com Tue Nov 12 19:38:02 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Nov 2013 14:38:02 -0500 Subject: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess In-Reply-To: <52828198.4070801@oracle.com> References: <52828198.4070801@oracle.com> Message-ID: <0860C393-60E3-44D3-99AC-88E33D3EE01D@oracle.com> +1 On Nov 12, 2013, at 2:29 PM, Mandy Chung wrote: > This is a simple code deletion in sun.misc.JavaAWTAccess and its implementation class: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ > > This patch removes the methods from sun.misc.JavaAWTAccess that are no longer used. The only dependency remaining from core-libs to AppContext is the ability to obtain an opaque unique object to represent an applet context ifit is running in an applet environment. > > thanks > Mandy -------------- next part -------------- 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 Tue Nov 12 22:15:25 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Nov 2013 14:15:25 -0800 Subject: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess In-Reply-To: <52828198.4070801@oracle.com> References: <52828198.4070801@oracle.com> Message-ID: <5282A87D.40101@oracle.com> Adding awt-dev for the review. Mandy On 11/12/2013 11:29 AM, Mandy Chung wrote: > This is a simple code deletion in sun.misc.JavaAWTAccess and its > implementation class: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ > > This patch removes the methods from sun.misc.JavaAWTAccess that are no > longer used. The only dependency remaining from core-libs to > AppContext is the ability to obtain an opaque unique object to > represent an applet context ifit is running in an applet environment. > > thanks > Mandy From xueming.shen at oracle.com Tue Nov 12 22:39:19 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 12 Nov 2013 14:39:19 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <527D6717.6090702@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> Message-ID: <5282AE17.3000508@oracle.com> Hi Bill, I'm still not convinced that the Base64.Decoder should guess the missing bits (to fill with zero) for the last dangling single byte in the input stream, even in lenient mode. That said I understand it might be really desired to still be able to decode such malformed base64 byte stream in the real world use scenario. I am trying to find a solution that can addresses the real issue without compromising the integrity of the input data. There is an "advanced" decode method Base64.Decoder(ByteBuffer, ByteBuffer), it is currently specified and implemented as *

If the input buffer is not in valid Base64 encoding scheme * then some bytes may have been written to the output buffer * before IllegalArgumentException is thrown. The positions of * both input and output buffer will not be advanced in this case. * So, if the stream is malformed, the current implementation of decode() method throws IAE and reset the in and out buffer back to their original position (throw away the decoded resulting bytes) It might be reasonable to change it to *

The decoding operation will stop and return {@code -1} if * the input buffer is not in valid Base64 encoding scheme and * the malformed-input error has been detected. The malformed * bytes begin at the input buffer's current (possibly advanced) * position. The output buffer's position will be advanced to * reflect the bytes written so far. which means when there is malformed byte sequence, instead of throwing an IAE it now returns -1 "normally" (better flow control?) and leaves the positions of the input and output buffer at the place where it stops. So you can recover the decoded result from the output buffer, and find out where the malformed byte sequence starts (if desirable) ByteBuffer src = ByteBuffer.wrap(src_byte_array); ByteBuffer dst = ByteBuffer.wrap(dst_byte_array); int ret = dec.decode(src, dst); dst.flip(); // do something for the resulting bytes if (ret < 0) { // do something for the malformed bytes in src } Instead of -1, the return value can be a "negative value" of the length of the bytes written to the output buffer, if really needed. Though the "position" and "limit" of the ByteBuffer should provide enough info for the access. The error recovery mechanism appears to work perfectly for your use scenario:-) the "only" downside"/inconvenience is that you will need to wrap your byte array input/output with the java.nio ByteBuffer (which is out recommended replacement for byte[] + length + offset anyway). http://cr.openjdk.java.net/~sherman/base64_malformed/webrev/ Opinion? Thanks! -Sherman On 11/08/2013 02:35 PM, Bill Shannon wrote: > Have you had a chance to think about this? Can the MIME decoder be made > more lenient, or can I get an option to control this? > > Bill Shannon wrote on 10/25/13 15:24: >> Xueming Shen wrote on 10/25/13 15:19: >>> On 10/25/13 2:19 PM, Bill Shannon wrote: >>>> If I understand this correctly, this proposes to remove the "lenient" >>>> option we've been discussing and just make it always lenient. Is that >>>> correct? >>> Yes. Only for the mime type though. >> That's fine. >> >>>> Unfortunately, from what you say below, it's still not lenient enough. >>>> I'd really like a version that never, ever, for any reason, throws an >>>> exception. Yes, that means when you only get a final 6 bits of data >>>> you have to make an assumption about what was intended, probably padding >>>> it with zeros to 8 bits. >>> This is something I'm hesitated to do. I can be lenient for the padding end >>> because the >>> padding character itself is not the real "data", whether or not it's present, >>> it's missing or >>> it's incorrect/incomplete, it does not impact the integrity of the data. But to >>> feed the last >>> 6 bits with zero, is really kinda of guessing, NOT decoding. >> I understand. And if the people who write spamming software knew how to >> read a spec, we wouldn't have this problem! :-) >> >> Still, there's a lot of bad data out there on the internet, and people >> want the software to do the best job it can to interpret the data. It's >> better to guess at the missing 2 bits of data than to lose the last 6 bits >> of data. From john.r.rose at oracle.com Tue Nov 12 22:51:00 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Nov 2013 14:51:00 -0800 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5280D46F.1060908@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278139B.1090508@univ-mlv.fr> <52782DD1.3020902@univ-mlv.fr> <5280D46F.1060908@gmail.com> Message-ID: On Nov 11, 2013, at 4:58 AM, Peter Levart wrote: > Hi John, Remi, > > I tried to create a prototype to see how it compares to bytecode-generated method accessor. Here it is: > > https://bugs.openjdk.java.net/browse/JDK-6824466#comment-13426571 > > It seems that lambda forms do their job quite well. Do experts have any suggestion how to improve it? > > Regards, Peter Cool! I put another comment on that bug. ? John From joe.darcy at oracle.com Tue Nov 12 22:52:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Nov 2013 14:52:03 -0800 Subject: RFR raw types lint warnings fixes for java.util.concurrent Message-ID: <5282B113.80403@oracle.com> Hello concurrency maestros, I submit for your consideration a simple patch to silence the three remaining javac lint warnings in the java.util.concurrent package: diff -r 69432cb5bca2 src/share/classes/java/util/concurrent/ForkJoinPool.java --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov 12 09:44:39 2013 -0800 +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov 12 14:40:40 2013 -0800 @@ -1820,7 +1820,7 @@ } } for (;;) { // help stealer or descend to its stealer - ForkJoinTask[] a; int b; + ForkJoinTask[] a; int b; if (subtask.status < 0) // surround probes with continue restart; // consistency checks if ((b = v.base) - v.top < 0 && (a = v.array) != null) { diff -r 69432cb5bca2 src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java --- a/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java Tue Nov 12 09:44:39 2013 -0800 +++ b/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java Tue Nov 12 14:40:40 2013 -0800 @@ -1253,11 +1253,11 @@ * Snapshot iterator that works off copy of underlying q array. */ private class Itr implements Iterator { - final RunnableScheduledFuture[] array; + final RunnableScheduledFuture[] array; int cursor = 0; // index of next element to return int lastRet = -1; // index of last element, or -1 if no such - Itr(RunnableScheduledFuture[] array) { + Itr(RunnableScheduledFuture[] array) { this.array = array; } I am content to relinquish ownership in seeing this patch through the 166 -> JDK 8 integration process :-) Thanks, -Joe From martinrb at google.com Tue Nov 12 23:06:44 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 12 Nov 2013 15:06:44 -0800 Subject: RFR raw types lint warnings fixes for java.util.concurrent In-Reply-To: <5282B113.80403@oracle.com> References: <5282B113.80403@oracle.com> Message-ID: Thanks, Joe. I see these warnings are due to very recent changes to javac. jsr166 CVS is now updated with these fixes. On Tue, Nov 12, 2013 at 2:52 PM, Joe Darcy wrote: > Hello concurrency maestros, > > I submit for your consideration a simple patch to silence the three > remaining javac lint warnings in the java.util.concurrent package: > > diff -r 69432cb5bca2 src/share/classes/java/util/ > concurrent/ForkJoinPool.java > --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov 12 > 09:44:39 2013 -0800 > +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov 12 > 14:40:40 2013 -0800 > @@ -1820,7 +1820,7 @@ > } > } > for (;;) { // help stealer or descend to its stealer > - ForkJoinTask[] a; int b; > + ForkJoinTask[] a; int b; > if (subtask.status < 0) // surround probes > with > continue restart; // consistency checks > if ((b = v.base) - v.top < 0 && (a = v.array) != > null) { > diff -r 69432cb5bca2 src/share/classes/java/util/concurrent/ > ScheduledThreadPoolExecutor.java > --- a/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java > Tue Nov 12 09:44:39 2013 -0800 > +++ b/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java > Tue Nov 12 14:40:40 2013 -0800 > @@ -1253,11 +1253,11 @@ > * Snapshot iterator that works off copy of underlying q array. > */ > private class Itr implements Iterator { > - final RunnableScheduledFuture[] array; > + final RunnableScheduledFuture[] array; > int cursor = 0; // index of next element to return > int lastRet = -1; // index of last element, or -1 if no such > > - Itr(RunnableScheduledFuture[] array) { > + Itr(RunnableScheduledFuture[] array) { > this.array = array; > } > > I am content to relinquish ownership in seeing this patch through the 166 > -> JDK 8 integration process :-) > > Thanks, > > -Joe > From bill.shannon at oracle.com Tue Nov 12 23:32:49 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Tue, 12 Nov 2013 15:32:49 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5282AE17.3000508@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> Message-ID: <5282BAA1.9090004@oracle.com> This still seems like an inconsistent, and inconvenient, approach to me. You've decided that some encoding errors (i.e., missing pad characters) can be ignored. You're willing to assume that the missing characters aren't missing data but just missing padding. But if you find a padding character where you don't expect it you won't assume that the missing data is zero. These errors, and others, could represent actual missing data that the user of the library should be notified about. As it is, you're not implementing "strict" and you're not implementing "lenient", you're implementing "half-lenient". You might as well implement strict and require the user of the library to always wrap it in a way that all errors are ignored in order to provide "lenient". That might be ok if it were easier to wrap the library to ignore errors. Perhaps a FilterInputStream could be written that would ignore the errors? Perhaps you could even provide such a stream? But that won't help with the non-stream methods. The ByteBuffer approach is pretty klunky. If you think it's reasonable, it would help a lot to include it as an example in the javadocs. The fundamental problem here is that there's really nothing reasonable to do if the data is not properly encoded. You either reflect the error to the user and tell them they can't have the data because it was corrupted, or you make a best effort to give them as much data as you can and let the user decide if it was corrupted. It's not as if someone is going to write a program that looks at the corrupt data and "corrects" it based on how it was corrupted. Xueming Shen wrote on 11/12/13 14:39: > Hi Bill, > > I'm still not convinced that the Base64.Decoder should guess the missing bits > (to fill with zero) for the last dangling single byte in the input stream, even in > lenient mode. That said I understand it might be really desired to still be able > to decode such malformed base64 byte stream in the real world use scenario. > I am trying to find a solution that can addresses the real issue without > compromising the integrity of the input data. There is an "advanced" decode > method Base64.Decoder(ByteBuffer, ByteBuffer), it is currently specified and > implemented as > > > *

If the input buffer is not in valid Base64 encoding scheme > * then some bytes may have been written to the output buffer > * before IllegalArgumentException is thrown. The positions of > * both input and output buffer will not be advanced in this case. > * > > So, if the stream is malformed, the current implementation of decode() > method throws IAE and reset the in and out buffer back to their original > position (throw away the decoded resulting bytes) > > It might be reasonable to change it to > > *

The decoding operation will stop and return {@code -1} if > * the input buffer is not in valid Base64 encoding scheme and > * the malformed-input error has been detected. The malformed > * bytes begin at the input buffer's current (possibly advanced) > * position. The output buffer's position will be advanced to > * reflect the bytes written so far. > > which means when there is malformed byte sequence, instead of throwing > an IAE it now returns -1 "normally" (better flow control?) and leaves the > positions of the input and output buffer at the place where it stops. So you > can recover the decoded result from the output buffer, and find out where > the malformed byte sequence starts (if desirable) > > ByteBuffer src = ByteBuffer.wrap(src_byte_array); > ByteBuffer dst = ByteBuffer.wrap(dst_byte_array); > int ret = dec.decode(src, dst); > dst.flip(); > // do something for the resulting bytes > > if (ret < 0) { > // do something for the malformed bytes in src > } > > Instead of -1, the return value can be a "negative value" of the length > of the bytes written to the output buffer, if really needed. Though the > "position" and "limit" of the ByteBuffer should provide enough info for > the access. > > The error recovery mechanism appears to work perfectly for your use > scenario:-) the "only" downside"/inconvenience is that you will need to > wrap your byte array input/output with the java.nio ByteBuffer (which is > out recommended replacement for byte[] + length + offset anyway). > > http://cr.openjdk.java.net/~sherman/base64_malformed/webrev/ > > Opinion? > > Thanks! > -Sherman > > > On 11/08/2013 02:35 PM, Bill Shannon wrote: >> Have you had a chance to think about this? Can the MIME decoder be made >> more lenient, or can I get an option to control this? >> >> Bill Shannon wrote on 10/25/13 15:24: >>> Xueming Shen wrote on 10/25/13 15:19: >>>> On 10/25/13 2:19 PM, Bill Shannon wrote: >>>>> If I understand this correctly, this proposes to remove the "lenient" >>>>> option we've been discussing and just make it always lenient. Is that >>>>> correct? >>>> Yes. Only for the mime type though. >>> That's fine. >>> >>>>> Unfortunately, from what you say below, it's still not lenient enough. >>>>> I'd really like a version that never, ever, for any reason, throws an >>>>> exception. Yes, that means when you only get a final 6 bits of data >>>>> you have to make an assumption about what was intended, probably padding >>>>> it with zeros to 8 bits. >>>> This is something I'm hesitated to do. I can be lenient for the padding end >>>> because the >>>> padding character itself is not the real "data", whether or not it's present, >>>> it's missing or >>>> it's incorrect/incomplete, it does not impact the integrity of the data. But to >>>> feed the last >>>> 6 bits with zero, is really kinda of guessing, NOT decoding. >>> I understand. And if the people who write spamming software knew how to >>> read a spec, we wouldn't have this problem! :-) >>> >>> Still, there's a lot of bad data out there on the internet, and people >>> want the software to do the best job it can to interpret the data. It's >>> better to guess at the missing 2 bits of data than to lose the last 6 bits >>> of data. > From xueming.shen at oracle.com Wed Nov 13 00:25:03 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 12 Nov 2013 16:25:03 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5282BAA1.9090004@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> Message-ID: <5282C6DF.9040201@oracle.com> On 11/12/2013 03:32 PM, Bill Shannon wrote: > This still seems like an inconsistent, and inconvenient, approach to me. > > You've decided that some encoding errors (i.e., missing pad characters) > can be ignored. You're willing to assume that the missing characters aren't > missing data but just missing padding. But if you find a padding character > where you don't expect it you won't assume that the missing data is zero. "missing pad characters" in theory is not an encoding errors. As the RFC suggested, the use of padding in base64 data is not required or used. They mainly serve the purpose of providing the indication of "end of the data". This is why the padding character(s) is not required (optional) by our decoder at first place. However, if the padding character(s) is present, they need to be correctly encoded, otherwise, it's a malformed base64 stream. To address your strong request fore more "lenient" MIME decoder, we have updated the spec and implementation to be a reasonable liberal for the incorrect padding at the end of the mime base64 data as showed below xxxx = unnecessary padding character at the end of encoded stream xxxx xx= missing the last padding character xxxx xx=y missing the last padding character, instead having a non-padding char With the assumption that it still follows the "spirit" of the purpose of padding character (as suggested by the RFC), to indicate the end of the data stream, no more decoding is needed beyond the padding character. Yes, it makes the MIME decoder somewhat "inconsistent" with our original design and the rest of other type of decoders, but we thought it might provide the "convenience" requested. But a single tangling byte at the end of the encoded data stream is obvious an encoding error or transportation error. As I said, I don't think the decoder should try to rescue with guess. The proposed change is to try to provide a simple mechanism that the application can do some lifecircle/error management to recovery from the malformed data stream, if desired. This is actually is NOT what j.u.Base64 is desired for. The primary goal is to provide a set of easy/simple utility methods for base64 encoding/decoding, not such complicated error recovery management, as the java.nio.charset.De/Encoder provides. The JavaDoc definitely can be improved to provide a detailed use case, sample, if it helps. But if it's definitely a no-go, maybe we can leave this for jdk9 for bigger surgery. -Sherman. > These errors, and others, could represent actual missing data that the > user of the library should be notified about. As it is, you're not > implementing "strict" and you're not implementing "lenient", you're > implementing "half-lenient". You might as well implement strict and > require the user of the library to always wrap it in a way that all > errors are ignored in order to provide "lenient". > > That might be ok if it were easier to wrap the library to ignore errors. > Perhaps a FilterInputStream could be written that would ignore the errors? > Perhaps you could even provide such a stream? > > But that won't help with the non-stream methods. The ByteBuffer approach > is pretty klunky. If you think it's reasonable, it would help a lot to > include it as an example in the javadocs. > > The fundamental problem here is that there's really nothing reasonable to > do if the data is not properly encoded. You either reflect the error to > the user and tell them they can't have the data because it was corrupted, > or you make a best effort to give them as much data as you can and let the > user decide if it was corrupted. It's not as if someone is going to write > a program that looks at the corrupt data and "corrects" it based on how > it was corrupted. > > Xueming Shen wrote on 11/12/13 14:39: >> Hi Bill, >> >> I'm still not convinced that the Base64.Decoder should guess the missing bits >> (to fill with zero) for the last dangling single byte in the input stream, even in >> lenient mode. That said I understand it might be really desired to still be able >> to decode such malformed base64 byte stream in the real world use scenario. >> I am trying to find a solution that can addresses the real issue without >> compromising the integrity of the input data. There is an "advanced" decode >> method Base64.Decoder(ByteBuffer, ByteBuffer), it is currently specified and >> implemented as >> >> >> *

If the input buffer is not in valid Base64 encoding scheme >> * then some bytes may have been written to the output buffer >> * before IllegalArgumentException is thrown. The positions of >> * both input and output buffer will not be advanced in this case. >> * >> >> So, if the stream is malformed, the current implementation of decode() >> method throws IAE and reset the in and out buffer back to their original >> position (throw away the decoded resulting bytes) >> >> It might be reasonable to change it to >> >> *

The decoding operation will stop and return {@code -1} if >> * the input buffer is not in valid Base64 encoding scheme and >> * the malformed-input error has been detected. The malformed >> * bytes begin at the input buffer's current (possibly advanced) >> * position. The output buffer's position will be advanced to >> * reflect the bytes written so far. >> >> which means when there is malformed byte sequence, instead of throwing >> an IAE it now returns -1 "normally" (better flow control?) and leaves the >> positions of the input and output buffer at the place where it stops. So you >> can recover the decoded result from the output buffer, and find out where >> the malformed byte sequence starts (if desirable) >> >> ByteBuffer src = ByteBuffer.wrap(src_byte_array); >> ByteBuffer dst = ByteBuffer.wrap(dst_byte_array); >> int ret = dec.decode(src, dst); >> dst.flip(); >> // do something for the resulting bytes >> >> if (ret< 0) { >> // do something for the malformed bytes in src >> } >> >> Instead of -1, the return value can be a "negative value" of the length >> of the bytes written to the output buffer, if really needed. Though the >> "position" and "limit" of the ByteBuffer should provide enough info for >> the access. >> >> The error recovery mechanism appears to work perfectly for your use >> scenario:-) the "only" downside"/inconvenience is that you will need to >> wrap your byte array input/output with the java.nio ByteBuffer (which is >> out recommended replacement for byte[] + length + offset anyway). >> >> http://cr.openjdk.java.net/~sherman/base64_malformed/webrev/ >> >> Opinion? >> >> Thanks! >> -Sherman >> >> >> On 11/08/2013 02:35 PM, Bill Shannon wrote: >>> Have you had a chance to think about this? Can the MIME decoder be made >>> more lenient, or can I get an option to control this? >>> >>> Bill Shannon wrote on 10/25/13 15:24: >>>> Xueming Shen wrote on 10/25/13 15:19: >>>>> On 10/25/13 2:19 PM, Bill Shannon wrote: >>>>>> If I understand this correctly, this proposes to remove the "lenient" >>>>>> option we've been discussing and just make it always lenient. Is that >>>>>> correct? >>>>> Yes. Only for the mime type though. >>>> That's fine. >>>> >>>>>> Unfortunately, from what you say below, it's still not lenient enough. >>>>>> I'd really like a version that never, ever, for any reason, throws an >>>>>> exception. Yes, that means when you only get a final 6 bits of data >>>>>> you have to make an assumption about what was intended, probably padding >>>>>> it with zeros to 8 bits. >>>>> This is something I'm hesitated to do. I can be lenient for the padding end >>>>> because the >>>>> padding character itself is not the real "data", whether or not it's present, >>>>> it's missing or >>>>> it's incorrect/incomplete, it does not impact the integrity of the data. But to >>>>> feed the last >>>>> 6 bits with zero, is really kinda of guessing, NOT decoding. >>>> I understand. And if the people who write spamming software knew how to >>>> read a spec, we wouldn't have this problem! :-) >>>> >>>> Still, there's a lot of bad data out there on the internet, and people >>>> want the software to do the best job it can to interpret the data. It's >>>> better to guess at the missing 2 bits of data than to lose the last 6 bits >>>> of data. From bill.shannon at oracle.com Wed Nov 13 04:21:28 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Tue, 12 Nov 2013 20:21:28 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5282C6DF.9040201@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> Message-ID: <5282FE48.8010204@oracle.com> Xueming Shen wrote on 11/12/2013 04:25 PM: > On 11/12/2013 03:32 PM, Bill Shannon wrote: >> This still seems like an inconsistent, and inconvenient, approach to me. >> >> You've decided that some encoding errors (i.e., missing pad characters) >> can be ignored. You're willing to assume that the missing characters aren't >> missing data but just missing padding. But if you find a padding character >> where you don't expect it you won't assume that the missing data is zero. > > "missing pad characters" in theory is not an encoding errors. As the RFC > suggested, the > use of padding in base64 data is not required or used. They mainly serve the > purpose of > providing the indication of "end of the data". This is why the padding > character(s) is not > required (optional) by our decoder at first place. However, if the padding > character(s) is > present, they need to be correctly encoded, otherwise, it's a malformed base64 > stream. I think we're interpreting the spec differently. If the padding characters are not needed, why define them at all? What advantage would there be in defining characters that convey no information? Why not let the data just end wherever it ends, throwing away unused bits? The padding characters are required. If they're missing, you have no idea if the encoder just left them out, or if the data was truncated or corrupted. I understand the desire to check that the data is encoded exactly the way the spec says it should be encoded, and to consider it an error otherwise. This is the "strict" approach. But that's not what you're doing. You're deciding that you care about some kinds of errors but not all kinds of errors. That's a judgment call that, as far as I can tell, is not based on real experience with encoded data. > To address your strong request fore more "lenient" MIME decoder, we have updated > the > spec and implementation to be a reasonable liberal for the incorrect padding at > the end > of the mime base64 data as showed below > > xxxx = unnecessary padding character at the end of encoded stream > xxxx xx= missing the last padding character > xxxx xx=y missing the last padding character, instead having a > non-padding char > > With the assumption that it still follows the "spirit" of the purpose of padding > character (as suggested by the RFC), to indicate the end of the data stream, no > more > decoding is needed beyond the padding character. Yes, it makes the MIME decoder > somewhat > "inconsistent" with our original design and the rest of other type of decoders, > but we > thought it might provide the "convenience" requested. > > But a single tangling byte at the end of the encoded data stream is obvious an > encoding > error or transportation error. As I said, I don't think the decoder should try > to rescue with > guess. The proposed change is to try to provide a simple mechanism that the > application > can do some lifecircle/error management to recovery from the malformed data > stream, if > desired. This is actually is NOT what j.u.Base64 is desired for. The primary > goal is to provide > a set of easy/simple utility methods for base64 encoding/decoding, not such > complicated > error recovery management, as the java.nio.charset.De/Encoder provides. There's really no error recovery possible, and certainly no program is going to attempt error recovery. As I said, there's only two reasonable things to do: 1) throw up your hands, claim the data is corrupt, and tell the user there's nothing you can do, or 2) do your best job to give the user as much data as possible, and let the user decide if the data is in fact corrupt. I'd be happy for you to provide options to do both. Doing something that's half way between the two just isn't useful. > The JavaDoc definitely can be improved to provide a detailed use case, sample, > if it > helps. But if it's definitely a no-go, maybe we can leave this for jdk9 for > bigger surgery. Without support for error-free decoding, there's little motivation for me to ever convert JavaMail to use this new capability. From xueming.shen at oracle.com Wed Nov 13 05:24:08 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 12 Nov 2013 21:24:08 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5282FE48.8010204@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> Message-ID: <52830CF8.4090606@oracle.com> On 11/12/13 8:21 PM, Bill Shannon wrote: > Xueming Shen wrote on 11/12/2013 04:25 PM: >> On 11/12/2013 03:32 PM, Bill Shannon wrote: >>> This still seems like an inconsistent, and inconvenient, approach to me. >>> >>> You've decided that some encoding errors (i.e., missing pad characters) >>> can be ignored. You're willing to assume that the missing characters aren't >>> missing data but just missing padding. But if you find a padding character >>> where you don't expect it you won't assume that the missing data is zero. >> "missing pad characters" in theory is not an encoding errors. As the RFC >> suggested, the >> use of padding in base64 data is not required or used. They mainly serve the >> purpose of >> providing the indication of "end of the data". This is why the padding >> character(s) is not >> required (optional) by our decoder at first place. However, if the padding >> character(s) is >> present, they need to be correctly encoded, otherwise, it's a malformed base64 >> stream. > I think we're interpreting the spec differently. I meant to say "The RFC says the use of padding in base64 data is not required nor used, in some circumstances". I interpret it as the padding is optional in some circumstances. -Sherman > > If the padding characters are not needed, why define them at all? > What advantage would there be in defining characters that convey no > information? Why not let the data just end wherever it ends, throwing > away unused bits? > > The padding characters are required. If they're missing, you have no > idea if the encoder just left them out, or if the data was truncated > or corrupted. > > I understand the desire to check that the data is encoded exactly the > way the spec says it should be encoded, and to consider it an error > otherwise. This is the "strict" approach. But that's not what you're > doing. You're deciding that you care about some kinds of errors but > not all kinds of errors. That's a judgment call that, as far as I can > tell, is not based on real experience with encoded data. > >> To address your strong request fore more "lenient" MIME decoder, we have updated >> the >> spec and implementation to be a reasonable liberal for the incorrect padding at >> the end >> of the mime base64 data as showed below >> >> xxxx = unnecessary padding character at the end of encoded stream >> xxxx xx= missing the last padding character >> xxxx xx=y missing the last padding character, instead having a >> non-padding char >> >> With the assumption that it still follows the "spirit" of the purpose of padding >> character (as suggested by the RFC), to indicate the end of the data stream, no >> more >> decoding is needed beyond the padding character. Yes, it makes the MIME decoder >> somewhat >> "inconsistent" with our original design and the rest of other type of decoders, >> but we >> thought it might provide the "convenience" requested. >> >> But a single tangling byte at the end of the encoded data stream is obvious an >> encoding >> error or transportation error. As I said, I don't think the decoder should try >> to rescue with >> guess. The proposed change is to try to provide a simple mechanism that the >> application >> can do some lifecircle/error management to recovery from the malformed data >> stream, if >> desired. This is actually is NOT what j.u.Base64 is desired for. The primary >> goal is to provide >> a set of easy/simple utility methods for base64 encoding/decoding, not such >> complicated >> error recovery management, as the java.nio.charset.De/Encoder provides. > There's really no error recovery possible, and certainly no program is > going to attempt error recovery. As I said, there's only two reasonable > things to do: 1) throw up your hands, claim the data is corrupt, and tell > the user there's nothing you can do, or 2) do your best job to give the user > as much data as possible, and let the user decide if the data is in fact corrupt. > I'd be happy for you to provide options to do both. Doing something that's > half way between the two just isn't useful. > >> The JavaDoc definitely can be improved to provide a detailed use case, sample, >> if it >> helps. But if it's definitely a no-go, maybe we can leave this for jdk9 for >> bigger surgery. > Without support for error-free decoding, there's little motivation for me > to ever convert JavaMail to use this new capability. From bill.shannon at oracle.com Wed Nov 13 07:44:53 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Tue, 12 Nov 2013 23:44:53 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <52830CF8.4090606@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <52830CF8.4090606@oracle.com> Message-ID: <52832DF5.8060605@oracle.com> Xueming Shen wrote on 11/12/2013 09:24 PM: > On 11/12/13 8:21 PM, Bill Shannon wrote: >> Xueming Shen wrote on 11/12/2013 04:25 PM: >>> On 11/12/2013 03:32 PM, Bill Shannon wrote: >>>> This still seems like an inconsistent, and inconvenient, approach to me. >>>> >>>> You've decided that some encoding errors (i.e., missing pad characters) >>>> can be ignored. You're willing to assume that the missing characters aren't >>>> missing data but just missing padding. But if you find a padding character >>>> where you don't expect it you won't assume that the missing data is zero. >>> "missing pad characters" in theory is not an encoding errors. As the RFC >>> suggested, the >>> use of padding in base64 data is not required or used. They mainly serve the >>> purpose of >>> providing the indication of "end of the data". This is why the padding >>> character(s) is not >>> required (optional) by our decoder at first place. However, if the padding >>> character(s) is >>> present, they need to be correctly encoded, otherwise, it's a malformed base64 >>> stream. >> I think we're interpreting the spec differently. > I meant to say "The RFC says the use of padding in base64 data is not required > nor used, in some circumstances". > I interpret it as the padding is optional in some circumstances. It's never optional. There's two specific cases in which it's required and one specific case in which it is not present. From alan.bateman at oracle.com Wed Nov 13 07:44:59 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 13 Nov 2013 07:44:59 +0000 Subject: hg: jdk8/tl/jdk: 8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError Message-ID: <20131113074515.A6FB762564@hg.openjdk.java.net> Changeset: c4c84b5a3dfa Author: alanb Date: 2013-11-13 07:43 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c84b5a3dfa 8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError Reviewed-by: mchung, egahlin ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh From chris.hegarty at oracle.com Wed Nov 13 09:42:24 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Nov 2013 09:42:24 +0000 Subject: RFR raw types lint warnings fixes for java.util.concurrent In-Reply-To: <5282B113.80403@oracle.com> References: <5282B113.80403@oracle.com> Message-ID: <52834980.7080905@oracle.com> The changes look fine to me. Since Martin has already brought the changes into the JSR166 CVS, Joe you can go ahead and push these changes to jdk8. Thanks, -Chris. On 11/12/2013 10:52 PM, Joe Darcy wrote: > Hello concurrency maestros, > > I submit for your consideration a simple patch to silence the three > remaining javac lint warnings in the java.util.concurrent package: > > diff -r 69432cb5bca2 > src/share/classes/java/util/concurrent/ForkJoinPool.java > --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov > 12 09:44:39 2013 -0800 > +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov > 12 14:40:40 2013 -0800 > @@ -1820,7 +1820,7 @@ > } > } > for (;;) { // help stealer or descend to its stealer > - ForkJoinTask[] a; int b; > + ForkJoinTask[] a; int b; > if (subtask.status < 0) // surround probes > with > continue restart; // consistency checks > if ((b = v.base) - v.top < 0 && (a = v.array) > != null) { > diff -r 69432cb5bca2 > src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java > --- > a/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java Tue > Nov 12 09:44:39 2013 -0800 > +++ > b/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java Tue > Nov 12 14:40:40 2013 -0800 > @@ -1253,11 +1253,11 @@ > * Snapshot iterator that works off copy of underlying q array. > */ > private class Itr implements Iterator { > - final RunnableScheduledFuture[] array; > + final RunnableScheduledFuture[] array; > int cursor = 0; // index of next element to return > int lastRet = -1; // index of last element, or -1 if no > such > > - Itr(RunnableScheduledFuture[] array) { > + Itr(RunnableScheduledFuture[] array) { > this.array = array; > } > > I am content to relinquish ownership in seeing this patch through the > 166 -> JDK 8 integration process :-) > > Thanks, > > -Joe From xuelei.fan at oracle.com Wed Nov 13 09:16:44 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 13 Nov 2013 09:16:44 +0000 Subject: hg: jdk8/tl/jdk: 8023147: Test DisabledShortRSAKeys.java intermittent failed Message-ID: <20131113091702.709E062568@hg.openjdk.java.net> Changeset: 1158d504e39e Author: xuelei Date: 2013-11-13 01:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1158d504e39e 8023147: Test DisabledShortRSAKeys.java intermittent failed Reviewed-by: mullan ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java From daniel.fuchs at oracle.com Wed Nov 13 09:51:29 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 13 Nov 2013 09:51:29 +0000 Subject: hg: jdk8/tl/jdk: 8026952: Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id Message-ID: <20131113095143.6488E6256C@hg.openjdk.java.net> Changeset: 30a3aefc4084 Author: dfuchs Date: 2013-11-13 10:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30a3aefc4084 8026952: Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id Summary: Trivial: change @bug 8023163 into @bug 8026499 Reviewed-by: mchung, alanb ! test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java From artem.ananiev at oracle.com Wed Nov 13 10:59:45 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 13 Nov 2013 14:59:45 +0400 Subject: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess In-Reply-To: <5282A87D.40101@oracle.com> References: <52828198.4070801@oracle.com> <5282A87D.40101@oracle.com> Message-ID: <52835BA1.5020304@oracle.com> Hi, Mandy, the fix looks fine to me. Other people might want to ask why these methods are no longer used and can be safely removed, so be prepared to the questions :) Thanks, Artem On 11/13/2013 2:15 AM, Mandy Chung wrote: > Adding awt-dev for the review. > > Mandy > > On 11/12/2013 11:29 AM, Mandy Chung wrote: >> This is a simple code deletion in sun.misc.JavaAWTAccess and its >> implementation class: >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ >> >> This patch removes the methods from sun.misc.JavaAWTAccess that are no >> longer used. The only dependency remaining from core-libs to >> AppContext is the ability to obtain an opaque unique object to >> represent an applet context ifit is running in an applet environment. >> >> thanks >> Mandy > From jaroslav.bachorik at oracle.com Wed Nov 13 12:13:53 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Wed, 13 Nov 2013 12:13:53 +0000 Subject: hg: jdk8/tl/jdk: 8004126: TEST_BUG: com/sun/jdi/BadHandshakeTest.java fails intermittently Message-ID: <20131113121406.976CA6256E@hg.openjdk.java.net> Changeset: 680ef14a2cc0 Author: jbachorik Date: 2013-11-13 13:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/680ef14a2cc0 8004126: TEST_BUG: com/sun/jdi/BadHandshakeTest.java fails intermittently Reviewed-by: dholmes, ykantser ! test/com/sun/jdi/BadHandshakeTest.java From erik.gahlin at oracle.com Wed Nov 13 14:27:41 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Wed, 13 Nov 2013 14:27:41 +0000 Subject: hg: jdk8/tl/jdk: 6959636: testcase failing on windows javax/management/loading/LibraryLoader/LibraryLoaderTest.java Message-ID: <20131113142753.A0AA96256F@hg.openjdk.java.net> Changeset: ddaa9a8acaed Author: egahlin Date: 2013-11-13 15:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddaa9a8acaed 6959636: testcase failing on windows javax/management/loading/LibraryLoader/LibraryLoaderTest.java Reviewed-by: sla, jbachorik ! test/ProblemList.txt ! test/javax/management/loading/LibraryLoader/LibraryLoaderTest.java From harold.seigel at oracle.com Wed Nov 13 14:55:00 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 13 Nov 2013 09:55:00 -0500 Subject: RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8 Message-ID: <528392C4.7080207@oracle.com> Hi, Please review this fix, submitted by Ekaterina Pavlova, to update the CDS classlist files for JDK 8. The classlist files were generated using the process described in jdk/make/tools/sharing/README.txt. In addition, a checksum was included. The open webrev is at: http://cr.openjdk.java.net/~hseigel/bug_8023041/ The bug is at: https://bugs.openjdk.java.net/browse/JDK-8023041 Additional information about this change, including testing information, is in the bug. Thanks! Harold From Alan.Bateman at oracle.com Wed Nov 13 15:04:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Nov 2013 15:04:53 +0000 Subject: RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8 In-Reply-To: <528392C4.7080207@oracle.com> References: <528392C4.7080207@oracle.com> Message-ID: <52839515.6010509@oracle.com> On 13/11/2013 14:55, harold seigel wrote: > Hi, > > Please review this fix, submitted by Ekaterina Pavlova, to update the > CDS classlist files for JDK 8. > > The classlist files were generated using the process described in > jdk/make/tools/sharing/README.txt. In addition, a checksum was included. > > The open webrev is at: > http://cr.openjdk.java.net/~hseigel/bug_8023041/ > > > The bug is at: https://bugs.openjdk.java.net/browse/JDK-8023041 > > Additional information about this change, including testing > information, is in the bug. Good to see these sync'ed up. I assume this will remove a lot of warnings from the build too. Assuming that the process to generate these was indeed followed then I'd suggest going ahead and just push it (as there isn't much we can actually review except to spot classes removed from the list that no longer exist). -Alan. From daniel.fuchs at oracle.com Wed Nov 13 15:05:06 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Nov 2013 16:05:06 +0100 Subject: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess In-Reply-To: <52828198.4070801@oracle.com> References: <52828198.4070801@oracle.com> Message-ID: <52839522.9070902@oracle.com> Hi Mandy, looks good! -- daniel On 11/12/13 8:29 PM, Mandy Chung wrote: > This is a simple code deletion in sun.misc.JavaAWTAccess and its > implementation class: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ > > This patch removes the methods from sun.misc.JavaAWTAccess that are no > longer used. The only dependency remaining from core-libs to AppContext > is the ability to obtain an opaque unique object to represent an applet > context ifit is running in an applet environment. > > thanks > Mandy From staffan.larsen at oracle.com Wed Nov 13 14:34:56 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 13 Nov 2013 14:34:56 +0000 Subject: hg: jdk8/tl/jdk: 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary Message-ID: <20131113143508.BBA8062570@hg.openjdk.java.net> Changeset: a42a416351b8 Author: ykantser Date: 2013-11-13 11:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a42a416351b8 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary Reviewed-by: sla + test/lib/testlibrary/AssertsTest.java + test/lib/testlibrary/OutputAnalyzerReportingTest.java + test/lib/testlibrary/jdk/testlibrary/InputArguments.java ! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java - test/lib/testlibrary/jdk/testlibrary/JdkFinder.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java From mandy.chung at oracle.com Wed Nov 13 15:55:40 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 13 Nov 2013 15:55:40 +0000 Subject: hg: jdk8/tl/jdk: 8028234: Remove unused methods in sun.misc.JavaAWTAccess Message-ID: <20131113155557.74F7162577@hg.openjdk.java.net> Changeset: 7c55fecfae65 Author: mchung Date: 2013-11-13 07:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c55fecfae65 8028234: Remove unused methods in sun.misc.JavaAWTAccess Reviewed-by: art, dfuchs, lancea ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! test/java/util/logging/TestAppletLoggerContext.java From xueming.shen at oracle.com Wed Nov 13 16:28:20 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Nov 2013 08:28:20 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <52832DF5.8060605@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <52830CF8.4090606@oracle.com> <52832DF5.8060605@oracle.com> Message-ID: <5283A8A4.1010807@oracle.com> On 11/12/13 11:44 PM, Bill Shannon wrote: > Xueming Shen wrote on 11/12/2013 09:24 PM: >> On 11/12/13 8:21 PM, Bill Shannon wrote: >>> Xueming Shen wrote on 11/12/2013 04:25 PM: >>>> On 11/12/2013 03:32 PM, Bill Shannon wrote: >>>>> This still seems like an inconsistent, and inconvenient, approach to me. >>>>> >>>>> You've decided that some encoding errors (i.e., missing pad characters) >>>>> can be ignored. You're willing to assume that the missing characters aren't >>>>> missing data but just missing padding. But if you find a padding character >>>>> where you don't expect it you won't assume that the missing data is zero. >>>> "missing pad characters" in theory is not an encoding errors. As the RFC >>>> suggested, the >>>> use of padding in base64 data is not required or used. They mainly serve the >>>> purpose of >>>> providing the indication of "end of the data". This is why the padding >>>> character(s) is not >>>> required (optional) by our decoder at first place. However, if the padding >>>> character(s) is >>>> present, they need to be correctly encoded, otherwise, it's a malformed base64 >>>> stream. >>> I think we're interpreting the spec differently. >> I meant to say "The RFC says the use of padding in base64 data is not required >> nor used, in some circumstances". >> I interpret it as the padding is optional in some circumstances. > It's never optional. There's two specific cases in which it's required > and one specific case in which it is not present. My apology, It appears we are not talking about the same thing. What I'm trying to say is that whether or not to USE the padding characters "=" is optional for base encoding "FOR SOME CIRCUMSTANCES". Maybe it's more clear to just cite the original wording here In some circumstances, the use of padding ("=") in base encoded data is not required nor used. In the general case, when assumptions on size of transported data cannot be made, padding is required to yield correct decoded data. Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise. My interpretation is that it is possible for some types/styles of Base64 implementation it is optional to not generate the "padding" character at the end of the encoding operation. Though the RFC requires if it does omitting the padding character, it need to explicitly specify this in its spec. When encoding the existing implementation, by default, always add the padding characters at the end of the encoded stream, if needed (for xx==, xxx=). Decoder is try to be "liberal"/ lenient in what your accept (with the assumption is that the encoded may come from some encoder that not generate the padding characters), so it accept data with padding and dta without padding. However, it requires that if padding characters are used, it need to be CORRECTLY encoded. That was the original specification and implementation. Upon your original request, I made the compromise to give MIME type a more liberal spec/implementation for "incorrect" padding character combination as showed below Patterns of possible incorrectly encoded padding final base64 unit are: xxxx = unnecessary padding character at the end of encoded stream xxxx xx= missing the last padding character xxxx xx=y missing the last padding character, instead having a non-padding char Now it appears this compromise became part of your complain. Our difference is that I believe the "padding character" is not part of the original data, we can be "liberal"/lenient for that. But "x===" (or simply a dangling "x") is missing part of the original data for decoding, I'm concerned about to be liberal on guessing what is missed. -Sherman From Alan.Bateman at oracle.com Wed Nov 13 16:51:02 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Nov 2013 16:51:02 +0000 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5282FE48.8010204@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> Message-ID: <5283ADF6.8060104@oracle.com> On 13/11/2013 04:21, Bill Shannon wrote: > : > There's really no error recovery possible, and certainly no program is > going to attempt error recovery. As I said, there's only two reasonable > things to do: 1) throw up your hands, claim the data is corrupt, and tell > the user there's nothing you can do, or 2) do your best job to give the user > as much data as possible, and let the user decide if the data is in fact corrupt. > I'd be happy for you to provide options to do both. Doing something that's > half way between the two just isn't useful. > A variation of the second might be for the decoder to stop when it encounters an error (illegal character, missing pad characters, insufficient bits in the last unit). That is, give the user the bytes that have been successfully decoded plus an indication that the remaining bytes have not been processed due to an error. This wouldn't be too hard to add with changes or variations of the decode methods that decode buffers (as the source buffer can report if it has remaining/unprocessed bytes). It's just a bit more work for users of the API that want to be able to handle corrupt or truncated input. From a quick look then it actually isn't too far from where Sherman was going, at least it wouldn't be if missing pad characters were treated as an error (as they were previously). The other thought is the charset API where a charset decoder can be configured to ignore, replace or report then malformed or unmappable input. Having support for all these actions is important for charset encoding/decoding but seems way too much for Base64 where I think the API should be simple for the majority of usages. In any case, it's not clear what we can do this late in the schedule. It might be prudent to just fix the MIME decoder to throw IAE consistently and re-visit the API support for a lenient decoder in JDK 9. -Alan. From chris.hegarty at oracle.com Wed Nov 13 16:50:22 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 13 Nov 2013 16:50:22 +0000 Subject: hg: jdk8/tl/jdk: 8022213: Intermittent test failures in java/net/URLClassLoader Message-ID: <20131113165036.69A376257A@hg.openjdk.java.net> Changeset: 70f1bed5e7fd Author: chegar Date: 2013-11-13 16:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f1bed5e7fd 8022213: Intermittent test failures in java/net/URLClassLoader Reviewed-by: dxu, alanb ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/closetest/Common.java ! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/lib/testlibrary/jdk/testlibrary/FileUtils.java From alan.bateman at oracle.com Wed Nov 13 17:08:02 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 13 Nov 2013 17:08:02 +0000 Subject: hg: jdk8/tl/jdk: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission Message-ID: <20131113170815.347746257C@hg.openjdk.java.net> Changeset: a493871959c2 Author: alanb Date: 2013-11-13 16:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a493871959c2 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission Reviewed-by: mchung, martin, chegar ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! test/java/nio/file/Files/CheckPermissions.java From erik.gahlin at oracle.com Wed Nov 13 17:39:05 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Wed, 13 Nov 2013 17:39:05 +0000 Subject: hg: jdk8/tl/jdk: 6954510: TEST_BUG: Testcase failure com/sun/jdi/BreakpointWithFullGC.sh Message-ID: <20131113173917.E60F76257F@hg.openjdk.java.net> Changeset: 256b3395346b Author: egahlin Date: 2013-11-13 18:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/256b3395346b 6954510: TEST_BUG: Testcase failure com/sun/jdi/BreakpointWithFullGC.sh Reviewed-by: sla, sspitsyn ! test/com/sun/jdi/BreakpointWithFullGC.sh From martinrb at google.com Wed Nov 13 17:47:57 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 Nov 2013 09:47:57 -0800 Subject: Redundant downcast in openjdk-7u40/jdk/src/share/classes/java/util/Arrays.java In-Reply-To: References: Message-ID: While your suggestion looks like a code improvement, no one wants to fix jdk7u40 sources. No one seems to have problems building jdk7u40 itself. Which compiler is it that is complaining? There is a current effort to remove warnings from openjdk8 build. On Mon, Nov 11, 2013 at 7:13 AM, Alex Yursha wrote: > I found a minor issue on openjdk-7u40 sources. Is this the right place to > discuss such things and if not could you please give me a hint on where > this right place is? I am really lost trying to find the right place to > open the issue. The issue itself is laid below. > > Redundant downcast to java.lang.Object is made in method copyOf(U[] > original, int newLength, Class newType) (line 2245): > > 2244 public static T[] copyOf(U[] original, int newLength, Class extends T[]> newType) { > 2245 T[] copy = ((Object)newType == (Object)Object[].class) > 2246 ? (T[]) new Object[newLength] > 2247 : (T[]) Array.newInstance(newType.getComponentType(), > newLength); > 2248 System.arraycopy(original, 0, copy, 0, > 2249 Math.min(original.length, newLength)); > 2250 return copy; > 2251 } > > Actually, we need only to downcast one of the operands in order to avoid > compiler complaints about incomparable types. The patch can look like this: > > - 2245 T[] copy = ((Object)newType == (Object)Object[].class) > +2245 T[] copy = ((Object)newType == Object[].class) > > Regards, > Alex Yursha > From joe.darcy at oracle.com Wed Nov 13 18:16:41 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Nov 2013 10:16:41 -0800 Subject: RFR raw types lint warnings fixes for java.util.concurrent In-Reply-To: <52834980.7080905@oracle.com> References: <5282B113.80403@oracle.com> <52834980.7080905@oracle.com> Message-ID: <5283C209.4040600@oracle.com> On 11/13/2013 1:42 AM, Chris Hegarty wrote: > The changes look fine to me. > > Since Martin has already brought the changes into the JSR166 CVS, Joe > you can go ahead and push these changes to jdk8. Will do; I'll shortly push the fix under JDK-8028300 Fix raw type lint warnings in java.util.concurrent. Thanks, -Joe > > Thanks, > -Chris. > > On 11/12/2013 10:52 PM, Joe Darcy wrote: >> Hello concurrency maestros, >> >> I submit for your consideration a simple patch to silence the three >> remaining javac lint warnings in the java.util.concurrent package: >> >> diff -r 69432cb5bca2 >> src/share/classes/java/util/concurrent/ForkJoinPool.java >> --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov >> 12 09:44:39 2013 -0800 >> +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java Tue Nov >> 12 14:40:40 2013 -0800 >> @@ -1820,7 +1820,7 @@ >> } >> } >> for (;;) { // help stealer or descend to its >> stealer >> - ForkJoinTask[] a; int b; >> + ForkJoinTask[] a; int b; >> if (subtask.status < 0) // surround probes >> with >> continue restart; // consistency >> checks >> if ((b = v.base) - v.top < 0 && (a = v.array) >> != null) { >> diff -r 69432cb5bca2 >> src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java >> --- >> a/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java >> Tue >> Nov 12 09:44:39 2013 -0800 >> +++ >> b/src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java >> Tue >> Nov 12 14:40:40 2013 -0800 >> @@ -1253,11 +1253,11 @@ >> * Snapshot iterator that works off copy of underlying q >> array. >> */ >> private class Itr implements Iterator { >> - final RunnableScheduledFuture[] array; >> + final RunnableScheduledFuture[] array; >> int cursor = 0; // index of next element to return >> int lastRet = -1; // index of last element, or -1 if no >> such >> >> - Itr(RunnableScheduledFuture[] array) { >> + Itr(RunnableScheduledFuture[] array) { >> this.array = array; >> } >> >> I am content to relinquish ownership in seeing this patch through the >> 166 -> JDK 8 integration process :-) >> >> Thanks, >> >> -Joe From bill.shannon at oracle.com Wed Nov 13 18:35:06 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 13 Nov 2013 10:35:06 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283A8A4.1010807@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <52830CF8.4090606@oracle.com> <52832DF5.8060605@oracle.com> <5283A8A4.1010807@oracle.com> Message-ID: <5283C65A.3070706@oracle.com> Xueming Shen wrote on 11/13/13 08:28: > On 11/12/13 11:44 PM, Bill Shannon wrote: >> Xueming Shen wrote on 11/12/2013 09:24 PM: >>> On 11/12/13 8:21 PM, Bill Shannon wrote: >>>> Xueming Shen wrote on 11/12/2013 04:25 PM: >>>>> On 11/12/2013 03:32 PM, Bill Shannon wrote: >>>>>> This still seems like an inconsistent, and inconvenient, approach to me. >>>>>> >>>>>> You've decided that some encoding errors (i.e., missing pad characters) >>>>>> can be ignored. You're willing to assume that the missing characters aren't >>>>>> missing data but just missing padding. But if you find a padding character >>>>>> where you don't expect it you won't assume that the missing data is zero. >>>>> "missing pad characters" in theory is not an encoding errors. As the RFC >>>>> suggested, the >>>>> use of padding in base64 data is not required or used. They mainly serve the >>>>> purpose of >>>>> providing the indication of "end of the data". This is why the padding >>>>> character(s) is not >>>>> required (optional) by our decoder at first place. However, if the padding >>>>> character(s) is >>>>> present, they need to be correctly encoded, otherwise, it's a malformed base64 >>>>> stream. >>>> I think we're interpreting the spec differently. >>> I meant to say "The RFC says the use of padding in base64 data is not required >>> nor used, in some circumstances". >>> I interpret it as the padding is optional in some circumstances. >> It's never optional. There's two specific cases in which it's required >> and one specific case in which it is not present. > > My apology, It appears we are not talking about the same thing. What I'm > trying to say is > that whether or not to USE the padding characters "=" is optional for base > encoding "FOR > SOME CIRCUMSTANCES". Maybe it's more clear to just cite the original wording here > > In some circumstances, the use of padding ("=") in base encoded data > is not required nor used. In the general case, when assumptions on > size of transported data cannot be made, padding is required to yield > correct decoded data. > Implementations MUST include appropriate pad characters at the end of > encoded data unless the specification referring to this document > explicitly states otherwise. I don't know what you're quoting from, but that's not in RFC 2045 where base64 is defined for MIME. RFC 2045 is pretty clear about when the padding character must or must not be present. > My interpretation is that it is possible for some types/styles of Base64 > implementation > it is optional to not generate the "padding" character at the end of the > encoding operation. I think those would be non-MIME uses. > Though the RFC requires if it does omitting the padding character, it need to > explicitly > specify this in its spec. > > When encoding the existing implementation, by default, always add the padding > characters > at the end of the encoded stream, if needed (for xx==, xxx=). Decoder is try > to be "liberal"/ > lenient in what your accept (with the assumption is that the encoded may come > from some > encoder that not generate the padding characters), so it accept data with > padding and > dta without padding. However, it requires that if padding characters are used, > it need > to be CORRECTLY encoded. That was the original specification and implementation. > Upon your original request, I made the compromise to give MIME type a more liberal > spec/implementation for "incorrect" padding character combination as showed below > > Patterns of possible incorrectly encoded padding final base64 unit are: > > xxxx = unnecessary padding character at the end of encoded stream > xxxx xx= missing the last padding character > xxxx xx=y missing the last padding character, instead having a non-padding char > Now it appears this compromise became part of your complain. No, my complaint is that you missed one case "xxxx x". > Our difference is that I believe the "padding character" is not part of the > original > data, we can be "liberal"/lenient for that. But "x===" (or simply a dangling "x") > is missing part of the original data for decoding, I'm concerned about to be > liberal on guessing what is missed. Again, I can understand a "strict" decoding that detects all encoding errors and a "lenient" decoding that ignores encoding errors, but you've got a "half-lenient/half-strict" decoding that I don't think is useful. From bill.shannon at oracle.com Wed Nov 13 18:41:25 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 13 Nov 2013 10:41:25 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283ADF6.8060104@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> Message-ID: <5283C7D5.2000401@oracle.com> Alan Bateman wrote on 11/13/13 08:51: > On 13/11/2013 04:21, Bill Shannon wrote: >> : >> There's really no error recovery possible, and certainly no program is >> going to attempt error recovery. As I said, there's only two reasonable >> things to do: 1) throw up your hands, claim the data is corrupt, and tell >> the user there's nothing you can do, or 2) do your best job to give the user >> as much data as possible, and let the user decide if the data is in fact corrupt. >> I'd be happy for you to provide options to do both. Doing something that's >> half way between the two just isn't useful. >> > A variation of the second might be for the decoder to stop when it encounters an > error (illegal character, missing pad characters, insufficient bits in the last > unit). That is, give the user the bytes that have been successfully decoded plus > an indication that the remaining bytes have not been processed due to an error. > This wouldn't be too hard to add with changes or variations of the decode > methods that decode buffers (as the source buffer can report if it has > remaining/unprocessed bytes). It's just a bit more work for users of the API > that want to be able to handle corrupt or truncated input. From a quick look > then it actually isn't too far from where Sherman was going, at least it > wouldn't be if missing pad characters were treated as an error (as they were > previously). I think always taking a strict approach is fine as long as it's straightforward for a user of the API to turn that into a lenient decoding. But if that's the approach you prefer, you should detect more errors than currently proposed. > The other thought is the charset API where a charset decoder can be configured > to ignore, replace or report then malformed or unmappable input. Having support > for all these actions is important for charset encoding/decoding but seems way > too much for Base64 where I think the API should be simple for the majority of > usages. We started this with a request for a strict/lenient option. That may still be simpler than figuring out how to do strict decoding and report the error in a way that users of the API can ignore the error and provide as much data as possible. > In any case, it's not clear what we can do this late in the schedule. It might > be prudent to just fix the MIME decoder to throw IAE consistently and re-visit > the API support for a lenient decoder in JDK 9. When we started this conversation there was plenty of time to fix this. :-( From joe.darcy at oracle.com Wed Nov 13 19:07:25 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 13 Nov 2013 19:07:25 +0000 Subject: hg: jdk8/tl/jdk: 8028300: Fix raw type lint warnings in java.util.concurrent Message-ID: <20131113190739.7517462583@hg.openjdk.java.net> Changeset: e6333788b117 Author: darcy Date: 2013-11-13 11:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6333788b117 8028300: Fix raw type lint warnings in java.util.concurrent Reviewed-by: chegar, martin ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java From xueming.shen at oracle.com Wed Nov 13 19:11:48 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Nov 2013 11:11:48 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283C7D5.2000401@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> Message-ID: <5283CEF4.6060406@oracle.com> On 11/13/2013 10:41 AM, Bill Shannon wrote: > > >> The other thought is the charset API where a charset decoder can be configured >> to ignore, replace or report then malformed or unmappable input. Having support >> for all these actions is important for charset encoding/decoding but seems way >> too much for Base64 where I think the API should be simple for the majority of >> usages. > We started this with a request for a strict/lenient option. That may still be > simpler than figuring out how to do strict decoding and report the error in a > way that users of the API can ignore the error and provide as much data as > possible. > >> In any case, it's not clear what we can do this late in the schedule. It might >> be prudent to just fix the MIME decoder to throw IAE consistently and re-visit >> the API support for a lenient decoder in JDK 9. > When we started this conversation there was plenty of time to fix this. :-( The issue here is we disagree on the specification of what lenient should be and how the API should look like. Here is the proposed change to undo the "lenient padding handling for mime" change we did earlier to leave the option open for a complete "lenient base64" in future release, when we have a consensus http://cr.openjdk.java.net/~sherman/base64_malformed2/webrev/ Alan, I still keep the decode(buf, buf) change on the table, as I feel it might be better than the existing one. But I'm fine if you prefer to keep the existing IAE throwing behavior. -Sherman From xueming.shen at oracle.com Wed Nov 13 19:32:02 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 13 Nov 2013 19:32:02 +0000 Subject: hg: jdk8/tl/jdk: 8027645: Pattern.split() with positive lookahead; ... Message-ID: <20131113193214.D483262584@hg.openjdk.java.net> Changeset: 9e37caf07ce0 Author: sherman Date: 2013-11-13 11:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e37caf07ce0 8027645: Pattern.split() with positive lookahead 6559590: Pattern.compile(".*").split("") returns incorrect result Summary: updated spec/impl for these two corner cases Reviewed-by: alanb, psandoz ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/regex/Pattern.java ! test/java/lang/String/Split.java ! test/java/util/regex/RegExTest.java From bill.shannon at oracle.com Wed Nov 13 19:37:46 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 13 Nov 2013 11:37:46 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283CEF4.6060406@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> Message-ID: <5283D50A.6080407@oracle.com> Xueming Shen wrote on 11/13/13 11:11: > On 11/13/2013 10:41 AM, Bill Shannon wrote: >> >> >>> The other thought is the charset API where a charset decoder can be configured >>> to ignore, replace or report then malformed or unmappable input. Having support >>> for all these actions is important for charset encoding/decoding but seems way >>> too much for Base64 where I think the API should be simple for the majority of >>> usages. >> We started this with a request for a strict/lenient option. That may still be >> simpler than figuring out how to do strict decoding and report the error in a >> way that users of the API can ignore the error and provide as much data as >> possible. >> >>> In any case, it's not clear what we can do this late in the schedule. It might >>> be prudent to just fix the MIME decoder to throw IAE consistently and re-visit >>> the API support for a lenient decoder in JDK 9. >> When we started this conversation there was plenty of time to fix this. :-( > > The issue here is we disagree on the specification of what lenient should be and > how the > API should look like. > > Here is the proposed change to undo the "lenient padding handling for mime" > change we > did earlier to leave the option open for a complete "lenient base64" in future > release, > when we have a consensus What other implementors of base64 MIME decoding software have you consulted, or do you intend to consult in the future? What experiments have you done with other base64 MIME decoding software or applications to determine how they handle these cases? I'm trying to determine how we're going to reach consensus in the future. My base64 MIME decoding software has evolved over time based on customer requirements. I'm trying to give you the benefit of that experience so that you don't need to waste years getting to the same point I got to. I started in a similar place as you, believing that applications would want to know about improperly encoded data. I learned that many do not, and that most end-user applications simply want to be as lenient as possible to provide the best data possible to the user. From huizhe.wang at oracle.com Wed Nov 13 20:02:00 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 13 Nov 2013 12:02:00 -0800 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter Message-ID: <5283DAB8.5010707@oracle.com> Hi, The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Thanks, Joe From lana.steuck at oracle.com Wed Nov 13 19:49:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 13 Nov 2013 19:49:57 +0000 Subject: hg: jdk8/tl/hotspot: 18 new changesets Message-ID: <20131113195035.6D74A62586@hg.openjdk.java.net> Changeset: 5b84039ca739 Author: amurillo Date: 2013-11-01 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b84039ca739 8027580: new hotspot build - hs25-b58 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ea79ab313e98 Author: mgerdin Date: 2013-10-30 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea79ab313e98 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Summary: Use 2-byte loads to load indexes from the byte code stream to avoid out of bounds reads. Reviewed-by: coleenp, sspitsyn ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: fdd464c8d62e Author: acorn Date: 2013-10-30 09:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fdd464c8d62e 8027304: Lambda: inheriting abstract + 1 default -> default, not ICCE Reviewed-by: hseigel, zgu ! src/share/vm/classfile/defaultMethods.cpp Changeset: 4fe7815b04f5 Author: acorn Date: 2013-10-30 09:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fe7815b04f5 Merge Changeset: c8fc12209830 Author: coleenp Date: 2013-10-31 14:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8fc12209830 8027616: Off by one error in putback for compressed oops nashorn performance improvement Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other. Reviewed-by: stefank, hseigel, zgu ! src/share/vm/memory/metaspace.cpp Changeset: 910026b800b8 Author: coleenp Date: 2013-11-01 10:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/910026b800b8 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodHandle 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. Reviewed-by: sspitsyn, ehelin, sla ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 42790b7e4d48 Author: mgronlun Date: 2013-11-01 15:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42790b7e4d48 Merge ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: f8b56489e455 Author: mgronlun Date: 2013-11-01 17:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8b56489e455 Merge Changeset: 04df110c8655 Author: mgronlun Date: 2013-11-02 20:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04df110c8655 Merge Changeset: 208ebea980f8 Author: roland Date: 2013-11-04 21:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/208ebea980f8 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I Summary: String.equals() intrinsic shouldn't use integer length input in pointer arithmetic without an i2l. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/intrinsics/stringequals/TestStringEqualsBadLength.java Changeset: e428d5e768e3 Author: rbackman Date: 2013-11-04 10:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e428d5e768e3 8027622: java.time.Instant.create failing since hs25-b56 Reviewed-by: kvn, iveresov ! src/share/vm/opto/compile.cpp + test/compiler/intrinsics/mathexact/CompareTest.java Changeset: a905d33ce13a Author: iveresov Date: 2013-11-05 00:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a905d33ce13a 8027751: C1 crashes in Weblogic with G1 enabled Summary: Keep T_OBJECT operands in registers for logical operations on x64 Reviewed-by: kvn, roland ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 94a83e0f9ce1 Author: iveresov Date: 2013-11-05 01:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94a83e0f9ce1 8017065: C2 allows safepoint checks to leak into G1 pre-barriers Summary: Make all raw loads strictly respect control dependencies, make sure RCE doesn't move raw loads, add verification of G1 pre-barriers. Reviewed-by: kvn, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.hpp Changeset: 613e6a6fc328 Author: iveresov Date: 2013-11-05 02:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/613e6a6fc328 Merge ! src/share/vm/opto/compile.cpp Changeset: be525e91f65b Author: mikael Date: 2013-11-06 06:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be525e91f65b 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION Summary: Uncommon trap blob did not bang all the stack shadow pages Reviewed-by: kvn, twisti, iveresov, jrose ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp + test/compiler/uncommontrap/UncommonTrapStackBang.java Changeset: 53662b2f1d68 Author: drchase Date: 2013-11-07 10:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53662b2f1d68 Merge Changeset: e510dfdec6dd Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e510dfdec6dd Merge Changeset: 52b076e6ffae Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52b076e6ffae Added tag hs25-b58 for changeset e510dfdec6dd ! .hgtags From xueming.shen at oracle.com Wed Nov 13 20:28:30 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Nov 2013 12:28:30 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283D50A.6080407@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> Message-ID: <5283E0EE.1000405@oracle.com> On 11/13/2013 11:37 AM, Bill Shannon wrote: > Xueming Shen wrote on 11/13/13 11:11: >> On 11/13/2013 10:41 AM, Bill Shannon wrote: >>> >>>> The other thought is the charset API where a charset decoder can be configured >>>> to ignore, replace or report then malformed or unmappable input. Having support >>>> for all these actions is important for charset encoding/decoding but seems way >>>> too much for Base64 where I think the API should be simple for the majority of >>>> usages. >>> We started this with a request for a strict/lenient option. That may still be >>> simpler than figuring out how to do strict decoding and report the error in a >>> way that users of the API can ignore the error and provide as much data as >>> possible. >>> >>>> In any case, it's not clear what we can do this late in the schedule. It might >>>> be prudent to just fix the MIME decoder to throw IAE consistently and re-visit >>>> the API support for a lenient decoder in JDK 9. >>> When we started this conversation there was plenty of time to fix this. :-( >> The issue here is we disagree on the specification of what lenient should be and >> how the >> API should look like. >> >> Here is the proposed change to undo the "lenient padding handling for mime" >> change we >> did earlier to leave the option open for a complete "lenient base64" in future >> release, >> when we have a consensus > What other implementors of base64 MIME decoding software have you consulted, > or do you intend to consult in the future? Yes, the plan is to see what other implementations do. So far (1) google's guava [1] just throws the exception com.google.common.io.BaseEncoding.base64().decode("QUJDA"); ==> java.lang.IllegalArgumentException: com.google.common.io.BaseEncoding$DecodingException: Invalid input length 5 I don't think any of the configuration options provide can make this exception go away. (2) apache's commons-codec [2] silently drops the dangling 6-bits new String(org.apache.commons.codec.binary.Base64.decodeBase64("QUJDA")) ==> ABC Its source code [3] at ln#465 suggests it's "TODO" ... case 1: // 6 bits - ignore entirely // TODO not currently tested; perhaps it is impossible? break; ... -Sherman [1] http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/BaseEncoding.html [2] http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html [3] http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Base64.java?revision=1447577&view=markup > What experiments have you done with other base64 MIME decoding software or > applications to determine how they handle these cases? > > I'm trying to determine how we're going to reach consensus in the future. > > My base64 MIME decoding software has evolved over time based on customer > requirements. I'm trying to give you the benefit of that experience so > that you don't need to waste years getting to the same point I got to. > I started in a similar place as you, believing that applications would > want to know about improperly encoded data. I learned that many do not, > and that most end-user applications simply want to be as lenient as possible > to provide the best data possible to the user. From eric.mccorkle at oracle.com Wed Nov 13 20:34:41 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 13 Nov 2013 15:34:41 -0500 Subject: Review request for JDK-8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs Message-ID: <5283E261.4010607@oracle.com> Hello, Please review this trivial fix that adds @since documentation tags to changes added in support of parameter reflection. Webrev here: http://cr.openjdk.java.net/~emc/8028021/ Thanks, Eric From joe.darcy at oracle.com Wed Nov 13 20:43:41 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 13 Nov 2013 12:43:41 -0800 Subject: Review request for JDK-8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs In-Reply-To: <5283E261.4010607@oracle.com> References: <5283E261.4010607@oracle.com> Message-ID: <5283E47D.3030309@oracle.com> Looks good; approved, Thanks, -Joe On 11/13/2013 12:34 PM, Eric McCorkle wrote: > Hello, > > Please review this trivial fix that adds @since documentation tags to > changes added in support of parameter reflection. > > Webrev here: > http://cr.openjdk.java.net/~emc/8028021/ > > Thanks, > Eric From eric.mccorkle at oracle.com Wed Nov 13 20:50:23 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 13 Nov 2013 20:50:23 +0000 Subject: hg: jdk8/tl/jdk: 8026884: test for fix of JDK-8021398 does not have @bug tag; ... Message-ID: <20131113205036.438CA6258F@hg.openjdk.java.net> Changeset: ea91826bc2e9 Author: emc Date: 2013-11-13 15:48 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea91826bc2e9 8026884: test for fix of JDK-8021398 does not have @bug tag 8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs Summary: two documentation fixes Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java From Alan.Bateman at oracle.com Wed Nov 13 21:33:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Nov 2013 21:33:57 +0000 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter In-Reply-To: <5283DAB8.5010707@oracle.com> References: <5283DAB8.5010707@oracle.com> Message-ID: <5283F045.6020609@oracle.com> On 13/11/2013 20:02, huizhe wang wrote: > Hi, > > The issue is that the limits applied to each processing process rather > than each file processing. This applies to not only StAX as reported, > but also other parsers and validators. The fix is to add reset to > XMLSecurityManager and call it upon each file processing. XSLT > Transform is verified fixed as the underlying parsers are fixed. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ This looks okay as a band-aid but won't this be replaced if fixed to have limits per document? -Alan. From Lance.Andersen at oracle.com Wed Nov 13 21:38:04 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 13 Nov 2013 16:38:04 -0500 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter In-Reply-To: <5283DAB8.5010707@oracle.com> References: <5283DAB8.5010707@oracle.com> Message-ID: looks fine joe On Nov 13, 2013, at 3:02 PM, huizhe wang wrote: > Hi, > > The issue is that the limits applied to each processing process rather than each file processing. This applies to not only StAX as reported, but also other parsers and validators. The fix is to add reset to XMLSecurityManager and call it upon each file processing. XSLT Transform is verified fixed as the underlying parsers are fixed. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ > > Thanks, > Joe > -------------- next part -------------- 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 huizhe.wang at oracle.com Wed Nov 13 22:08:29 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 13 Nov 2013 14:08:29 -0800 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter In-Reply-To: <5283F045.6020609@oracle.com> References: <5283DAB8.5010707@oracle.com> <5283F045.6020609@oracle.com> Message-ID: <5283F85D.4010704@oracle.com> On 11/13/2013 1:33 PM, Alan Bateman wrote: > On 13/11/2013 20:02, huizhe wang wrote: >> Hi, >> >> The issue is that the limits applied to each processing process >> rather than each file processing. This applies to not only StAX as >> reported, but also other parsers and validators. The fix is to add >> reset to XMLSecurityManager and call it upon each file processing. >> XSLT Transform is verified fixed as the underlying parsers are fixed. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ > This looks okay as a band-aid but won't this be replaced if fixed to > have limits per document? Each parser has its own copy of XMLSecurityManager that maintains the values of the limits. The parser is reset before it starts to parse a document. Resetting the values managed by XMLSecurityManager therefore makes sure that the limits are per document. Daniel sent me a private email to question if the reset in PropertyManager is safe. He was right. I traced that back to the previous patch in that the StAX parsers actually were sharing the same XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed the code so that they are cloned. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Thanks, Joe > > -Alan. From bill.shannon at oracle.com Wed Nov 13 22:19:20 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 13 Nov 2013 14:19:20 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283E0EE.1000405@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> Message-ID: <5283FAE8.1000202@oracle.com> Xueming Shen wrote on 11/13/13 12:28: > On 11/13/2013 11:37 AM, Bill Shannon wrote: >> Xueming Shen wrote on 11/13/13 11:11: >>> On 11/13/2013 10:41 AM, Bill Shannon wrote: >>>> >>>>> The other thought is the charset API where a charset decoder can be configured >>>>> to ignore, replace or report then malformed or unmappable input. Having >>>>> support >>>>> for all these actions is important for charset encoding/decoding but seems way >>>>> too much for Base64 where I think the API should be simple for the majority of >>>>> usages. >>>> We started this with a request for a strict/lenient option. That may still be >>>> simpler than figuring out how to do strict decoding and report the error in a >>>> way that users of the API can ignore the error and provide as much data as >>>> possible. >>>> >>>>> In any case, it's not clear what we can do this late in the schedule. It might >>>>> be prudent to just fix the MIME decoder to throw IAE consistently and re-visit >>>>> the API support for a lenient decoder in JDK 9. >>>> When we started this conversation there was plenty of time to fix this. :-( >>> The issue here is we disagree on the specification of what lenient should be and >>> how the >>> API should look like. >>> >>> Here is the proposed change to undo the "lenient padding handling for mime" >>> change we >>> did earlier to leave the option open for a complete "lenient base64" in future >>> release, >>> when we have a consensus >> What other implementors of base64 MIME decoding software have you consulted, >> or do you intend to consult in the future? > > Yes, the plan is to see what other implementations do. > > So far > > (1) google's guava [1] just throws the exception > > com.google.common.io.BaseEncoding.base64().decode("QUJDA"); > > ==> java.lang.IllegalArgumentException: > com.google.common.io.BaseEncoding$DecodingException: Invalid input length 5 > > I don't think any of the configuration options provide can make this exception > go away. > > (2) apache's commons-codec [2] silently drops the dangling 6-bits > new String(org.apache.commons.codec.binary.Base64.decodeBase64("QUJDA")) > > ==> ABC > > Its source code [3] at ln#465 suggests it's "TODO" > ... > case 1: // 6 bits - ignore entirely > // TODO not currently tested; perhaps it is impossible? > break; > ... > > -Sherman > > [1] > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/BaseEncoding.html > > [2] > http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html > > [3] > http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/Base64.java?revision=1447577&view=markup base64 decoders that deal with simple, short strings aren't really a challenge. Such strings are almost always encoded correctly. The challenge is decoding base64 encoded content in a MIME part, e.g., in an email message. There's lots of really bad email software out there, often spamming software, that doesn't always follow the rules of the spec. Look at what other libraries that parse email messages do. Look at what email applications do. If you send incorrectly encoded data to Gmail, what does the Gmail web UI do? What does Thunderbird or Outlook do? From fbrunnerlist at gmx.ch Wed Nov 13 23:52:26 2013 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Thu, 14 Nov 2013 00:52:26 +0100 Subject: Reported but unconfirmed JDK issue (Bug Id: 9002739) Message-ID: <2919030.IBgLASYbax@shire> Hi, My name is Florian Brunner. This is my first E-Mail to this list. (So far I was only involved with the swing-dev and openjfx-dev mailing lists of OpenJDK.) So I hope, I'm sending my question to the right list. Back in May I filed a JDK issue regarding the ZipFileSystemProvider (see the message below). But so far I cannot find the issue with the Bug Id: 9002739 on the Java Bug Database at http://bugs.sun.com. Since a bug has been reported for Drombler FX (an Open Source project providing a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first)), which probably is caused by this issue, I would like to work on this issue. http://issues.drombler.org/14 Could someone from Oracle confirm this issue and make sure it appears in the Bug Database? Thanks. -Florian -----Original Message----- From: Bug-Report-Daemon_WW at ORACLE.COM [mailto:Bug-Report-Daemon_WW at ORACLE.COM] Sent: Friday, May 17, 2013 7:09 PM To: Brunner Florian (IT-SWE-CD2-T25) Subject: Your Report (Bug ID: 9002739 ) - ZipFileSystemProvider: newFileSystem URI format issue Dear Java Developer, Thank you for reporting this issue. We have determined that this report is a new bug and have entered the bug into our bug tracking system under Bug Id: 9002739. You can look for related issues on the Java Bug Database at http://bugs.sun.com. We will try to process all newly posted bugs in a timely manner, but we make no promises about the amount of time in which a bug will be fixed. If you just reported a bug that could have a major impact on your project, consider using one of the technical support offerings available at Oracle Support. Thanks again for your submission! Regards, Java Developer Support From sonali.goel at oracle.com Thu Nov 14 00:36:45 2013 From: sonali.goel at oracle.com (sonali.goel at oracle.com) Date: Thu, 14 Nov 2013 00:36:45 +0000 Subject: hg: jdk8/tl/langtools: 8025113: Convert 7 tools TryWithResources tests to jtreg format Message-ID: <20131114003648.C95BA62593@hg.openjdk.java.net> Changeset: f90d88913c5f Author: sogoel Date: 2013-11-13 16:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f90d88913c5f 8025113: Convert 7 tools TryWithResources tests to jtreg format Reviewed-by: darcy, jjg + test/tools/javac/TryWithResources/ResDeclOutsideTry.java + test/tools/javac/TryWithResources/ResDeclOutsideTry.out + test/tools/javac/TryWithResources/ResInNestedExpr.java + test/tools/javac/TryWithResources/ResourceNameConflict.java + test/tools/javac/TryWithResources/ResourceNameConflict.out + test/tools/javac/TryWithResources/ResourceRedecl.java + test/tools/javac/TryWithResources/ResourceRedecl.out + test/tools/javac/TryWithResources/ResourceShadow.java + test/tools/javac/TryWithResources/TestTwr09.java From david.holmes at oracle.com Thu Nov 14 01:04:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Nov 2013 17:04:04 -0800 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <52825AAD.7030006@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> Message-ID: <52842184.4030606@oracle.com> Hi Stuart, Sorry for the delay (been enroute). Only issue I have remains the subSequence change - you can't weaken the post-condition of CharSequence.subSequence without breaking subtype substitutability. Thanks, David On 12/11/2013 8:43 AM, Stuart Marks wrote: > Hi all, > > Here's an updated version of the String spec change. Changes from the > previous version address comments made by Brent Christian and David > Holmes. Specifically: > > - Specify copyValueOf() overloads as "equivalent to" corresponding > valueOf() overloads. > - Remove extranous changes to subSequence() method > - Clarify wording of concat() method doc. > > Bug report: > > https://bugs.openjdk.java.net/browse/JDK-7174936 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/ > > Specdiff: > > http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html > > Thanks! > > s'marks > > On 11/7/13 2:31 AM, Stuart Marks wrote: >> Hi all, >> >> Please review the following spec changes to java.lang.String. >> >> In several places the specs mention returning "new" strings. This is >> overspecified; it's sufficient to return "a" string that satisfies the >> required >> properties. In some cases the current implementation doesn't create a >> new string >> -- for example, substring(0) returns 'this' -- which is strictly a >> violation of >> the spec. The solution is to relax the spec requirement to create new >> strings. >> >> Also, this change cleans up the specs for the copyValueOf() overloads >> to make >> them identical to the corresponding valueOf() overloads. Previously, >> they were >> gratuitously different. I think that some time in the dim, distant past, >> probably before JDK 1.0, they had different semantics, but now they're >> identical. The specs should say they're identical. >> >> This change is spec only, no code changes. >> >> Bug report: >> >> https://bugs.openjdk.java.net/browse/jdk-7174936 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html >> >> >> Thanks! >> >> s'marks From xueming.shen at oracle.com Thu Nov 14 01:13:44 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Nov 2013 17:13:44 -0800 Subject: RFR JDK-8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression. Message-ID: <528423C8.3030205@oracle.com> Hi, The change set for JDK-6559590 [1] triggers couple regression test failures in various areas. It appears jdk8 source code itself has dependency on the "old" behavior of split() method when the input sequence is an empty string (split-ing a zero-length input sequence always returns the resulting array has just one element, the empty string itself). Given we are at a very late stage of the release, seems like the best way to solve this issue for now is to undo the change for 6559590. I will re-open 6559590 for future releases. Here is the webrev for the undo. We still keep the change for 8027645 http://cr.openjdk.java.net/~sherman/8028321/webrev/ Thanks! -Sherman [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e37caf07ce0 From joe.darcy at oracle.com Thu Nov 14 03:01:02 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 13 Nov 2013 19:01:02 -0800 Subject: Reported but unconfirmed JDK issue (Bug Id: 9002739) In-Reply-To: <2919030.IBgLASYbax@shire> References: <2919030.IBgLASYbax@shire> Message-ID: <52843CEE.4070905@oracle.com> Hello, The incident 9002739 became bug JDK-8014852 "(zipfs) ZipFileSystemProvider: newFileSystem URI format issue," which in turn was marked as a duplicate of JDK-7156873 "(zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets.": https://bugs.openjdk.java.net/browse/JDK-7156873 JDK-7156873 is fixed in JDK 8, 7u40, and 7u45. HTH, -Joe On 11/13/2013 3:52 PM, Florian Brunner wrote: > Hi, > > My name is Florian Brunner. This is my first E-Mail to this list. (So far I was only involved with the swing-dev and openjfx-dev mailing lists of OpenJDK.) So I hope, I'm sending my question to the right list. > > Back in May I filed a JDK issue regarding the ZipFileSystemProvider (see the message below). But so far I cannot find the issue with the Bug Id: 9002739 on the Java Bug Database at http://bugs.sun.com. > > Since a bug has been reported for Drombler FX (an Open Source project providing a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first)), which probably is caused by this issue, I would like to work on this issue. > > http://issues.drombler.org/14 > > Could someone from Oracle confirm this issue and make sure it appears in the Bug Database? > > Thanks. > > -Florian > > -----Original Message----- > From: Bug-Report-Daemon_WW at ORACLE.COM [mailto:Bug-Report-Daemon_WW at ORACLE.COM] > Sent: Friday, May 17, 2013 7:09 PM > To: Brunner Florian (IT-SWE-CD2-T25) > Subject: Your Report (Bug ID: 9002739 ) - ZipFileSystemProvider: newFileSystem URI format issue > > Dear Java Developer, > > Thank you for reporting this issue. > > We have determined that this report is a new bug and have entered the bug into our bug tracking system under Bug Id: 9002739. You can look for related issues on the Java Bug Database at http://bugs.sun.com. > > We will try to process all newly posted bugs in a timely manner, but we make no promises about the amount of time in which a bug will be fixed. If you just reported a bug that could have a major impact on your project, consider using one of the technical support offerings available at Oracle Support. > > Thanks again for your submission! > > Regards, > Java Developer Support From yiming.wang at oracle.com Thu Nov 14 03:17:19 2013 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 14 Nov 2013 11:17:19 +0800 Subject: RFR for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently Message-ID: <528440BF.2070909@oracle.com> Hi Everyone, I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-7067973. It is a test bug as the test doesn't guarantee memory allocated from the Old Gen, if the used memory is zero and doesn't cross the threshold, no notification is sent, so both the main thread and Checker thread are blocked to wait for the GC notification. so the suggested fix is similar as the fix ResetPeakMemoryUsage.java to create big object to make sure the old gen usage crosses the threshold and run test with different GC vmoptions. Please let me know if you have any comments or suggestions. If you are OK with the solution, I'll send a webrev in the next mail. Thanks, Eric From xueming.shen at oracle.com Thu Nov 14 06:29:09 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 14 Nov 2013 06:29:09 +0000 Subject: hg: jdk8/tl/jdk: 8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression Message-ID: <20131114062922.B87BA6259B@hg.openjdk.java.net> Changeset: 1d790a56de4e Author: sherman Date: 2013-11-13 22:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d790a56de4e 8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression Summary: to undo the change for 6559590 Reviewed-by: darcy ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/regex/Pattern.java ! test/java/lang/String/Split.java ! test/java/util/regex/RegExTest.java From staffan.larsen at oracle.com Thu Nov 14 07:29:36 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Nov 2013 08:29:36 +0100 Subject: Review request for 8028234: Remove unused methods in sun.misc.JavaAWTAccess In-Reply-To: <52828198.4070801@oracle.com> References: <52828198.4070801@oracle.com> Message-ID: <417CC054-FDA3-4F0B-B0EC-93BDC52C71DC@oracle.com> Looks good! Thanks, /Staffan On 12 Nov 2013, at 20:29, Mandy Chung wrote: > This is a simple code deletion in sun.misc.JavaAWTAccess and its implementation class: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8028234/webrev.00/ > > This patch removes the methods from sun.misc.JavaAWTAccess that are no longer used. The only dependency remaining from core-libs to AppContext is the ability to obtain an opaque unique object to represent an applet context ifit is running in an applet environment. > > thanks > Mandy From Alan.Bateman at oracle.com Thu Nov 14 07:57:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Nov 2013 07:57:25 +0000 Subject: RFR for JDK-7067973: test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java hanging intermittently In-Reply-To: <528440BF.2070909@oracle.com> References: <528440BF.2070909@oracle.com> Message-ID: <52848265.2070200@oracle.com> If you have a preliminary patch then I would suggest bringing it to serviceability-dev to discuss it. -Alan On 14/11/2013 03:17, Eric Wang wrote: > Hi Everyone, > > I'm working on the bug https://bugs.openjdk.java.net/browse/JDK-7067973. > > It is a test bug as the test doesn't guarantee memory allocated from > the Old Gen, if the used memory is zero and doesn't cross the > threshold, no notification is sent, so both the main thread and > Checker thread are blocked to wait for the GC notification. > > so the suggested fix is similar as the fix ResetPeakMemoryUsage.java > to create > big object to make sure the old gen usage crosses the threshold and > run test with different GC vmoptions. > > Please let me know if you have any comments or suggestions. If you are > OK with the solution, I'll send a webrev in the next mail. > > Thanks, > Eric From joe.darcy at oracle.com Thu Nov 14 08:08:19 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 14 Nov 2013 00:08:19 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors Message-ID: <528484F3.5030706@oracle.com> Hello, Please take an initial look over a fix for JDK-8006572 DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors http://cr.openjdk.java.net/~darcy/8006572.0/ The basic approach is to use compensated summation http://en.wikipedia.org/wiki/Kahan_summation_algorithm to computed streams-related sum and average statistics in the various locations that this can be done. All existing streams tests pass and new newly-written test passes too. I believe the DoubleSummaryStatistics.java portion, including the test, is fully review-worthy. In the test, for the sample computation in question, the naive summation implementation had a error of 500,000 ulps compared to 2 ups with the new implementation. Two other locations I've found where this summation technique should be used are in java.util.stream.Collectors.{summingDouble, averagingDouble} and java.util.stream.DoublePipeline.{sum, average} DoublePipeline is the primary implementation class of DoubleStream. For Collectors, the proposed code is a fairly clear adaptation of how the current code passes state around; there is not currently a dedicated test for the new summation technique in this location. I'm new to the streams API so for DoublePipeline I don't know the idiomatic way to phrase the collect I want to perform over the code. (Based on my current understanding, I believe I want to perform a collect rather than a reduce since for the compensated summation I need to maintain some additional state.) Guidance here welcome. Thanks, -Joe From Alan.Bateman at oracle.com Thu Nov 14 10:24:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Nov 2013 10:24:24 +0000 Subject: 8028343: More ProblemList.txt updates (11/2013) Message-ID: <5284A4D8.2070407@oracle.com> Lana pulled hs25-b58 into jdk8/tl yesterday and that has the fix to the math exact intrinsics that required us to temporarily exclude a bunch of tests (JSR-310 mostly) recently. These tests can be liberated again. In addition there are a few other tests that need to be excluded, pending other fixes. The webrev with the update is here: http://cr.openjdk.java.net/~alanb/8028343/webrev/ Thanks, Alan. From chris.hegarty at oracle.com Thu Nov 14 10:41:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Nov 2013 10:41:35 +0000 Subject: 8028343: More ProblemList.txt updates (11/2013) In-Reply-To: <5284A4D8.2070407@oracle.com> References: <5284A4D8.2070407@oracle.com> Message-ID: <5284A8DF.1070801@oracle.com> Thanks for doing this Alan, the changes look fine to me. -Chris. On 14/11/13 10:24, Alan Bateman wrote: > > Lana pulled hs25-b58 into jdk8/tl yesterday and that has the fix to the > math exact intrinsics that required us to temporarily exclude a bunch of > tests (JSR-310 mostly) recently. These tests can be liberated again. In > addition there are a few other tests that need to be excluded, pending > other fixes. The webrev with the update is here: > > http://cr.openjdk.java.net/~alanb/8028343/webrev/ > > Thanks, > > Alan. From alan.bateman at oracle.com Thu Nov 14 10:43:36 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 14 Nov 2013 10:43:36 +0000 Subject: hg: jdk8/tl/jdk: 8028343: More ProblemList.txt updates (11/2013) Message-ID: <20131114104348.19AE1625A2@hg.openjdk.java.net> Changeset: ecf85f4aecf0 Author: alanb Date: 2013-11-14 10:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecf85f4aecf0 8028343: More ProblemList.txt updates (11/2013) Reviewed-by: chegar ! test/ProblemList.txt From Alan.Bateman at oracle.com Thu Nov 14 10:51:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Nov 2013 10:51:07 +0000 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter In-Reply-To: <5283F85D.4010704@oracle.com> References: <5283DAB8.5010707@oracle.com> <5283F045.6020609@oracle.com> <5283F85D.4010704@oracle.com> Message-ID: <5284AB1B.2020008@oracle.com> On 13/11/2013 22:08, huizhe wang wrote: > : > > Each parser has its own copy of XMLSecurityManager that maintains the > values of the limits. The parser is reset before it starts to parse a > document. Resetting the values managed by XMLSecurityManager therefore > makes sure that the limits are per document. > > Daniel sent me a private email to question if the reset in > PropertyManager is safe. He was right. I traced that back to the > previous patch in that the StAX parsers actually were sharing the same > XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed > the code so that they are cloned. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ Sorry about that, having it called XMLSecurityManager when it's not a SecurityManager is always confusing. In that case, it looks okay to me. -Alan. From joel.franck at oracle.com Thu Nov 14 11:42:36 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 14 Nov 2013 11:42:36 +0000 Subject: hg: jdk8/tl/jdk: 8028055: (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true Message-ID: <20131114114248.958AD625A8@hg.openjdk.java.net> Changeset: 83c768d6cb93 Author: jfranck Date: 2013-11-14 12:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83c768d6cb93 8028055: (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true Reviewed-by: briangoetz ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java ! test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java From Alan.Bateman at oracle.com Thu Nov 14 14:18:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Nov 2013 14:18:15 +0000 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5283E0EE.1000405@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> Message-ID: <5284DBA7.2050803@oracle.com> On 13/11/2013 20:28, Xueming Shen wrote: > > Yes, the plan is to see what other implementations do. I think we've run out road on this for JDK 8. Even if we had agreement on dealing with corrupt input then there is little/no time to get feedback and do any further adjustments. Technically only showstopper API changes have been allowed since October so we have been on borrowed time anyway. Also we're coming up on RDP2 so we'd have to justify any changes as showstoppers. So what you would think about just leaving it strict for JDK 8 and then continue the work to see how lenient support should be exposed in the API so that it can go into JDK 9 early. That would allow you to consider whether it to have a means to get a Decoder that will consume all sewage or just decode up to the point where invalid chars or undeflow is detected. Also it probably is a bit inconsistent to have only decode buffer method stop (as proposed) so that could be looked at too. If you agree then there is a bit of clean-up to do with the changes for 8025003 that were pushed but I think that can be justified. -Alan. From harold.seigel at oracle.com Thu Nov 14 15:03:57 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 14 Nov 2013 10:03:57 -0500 Subject: RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8 In-Reply-To: <52839515.6010509@oracle.com> References: <528392C4.7080207@oracle.com> <52839515.6010509@oracle.com> Message-ID: <5284E65D.4080803@oracle.com> Hi Alan, Thank you for the review. Harold On 11/13/2013 10:04 AM, Alan Bateman wrote: > On 13/11/2013 14:55, harold seigel wrote: >> Hi, >> >> Please review this fix, submitted by Ekaterina Pavlova, to update the >> CDS classlist files for JDK 8. >> >> The classlist files were generated using the process described in >> jdk/make/tools/sharing/README.txt. In addition, a checksum was >> included. >> >> The open webrev is at: >> http://cr.openjdk.java.net/~hseigel/bug_8023041/ >> >> >> The bug is at: https://bugs.openjdk.java.net/browse/JDK-8023041 >> >> Additional information about this change, including testing >> information, is in the bug. > Good to see these sync'ed up. I assume this will remove a lot of > warnings from the build too. > > Assuming that the process to generate these was indeed followed then > I'd suggest going ahead and just push it (as there isn't much we can > actually review except to spot classes removed from the list that no > longer exist). > > -Alan. > From tristan.yan at oracle.com Thu Nov 14 15:09:19 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 14 Nov 2013 07:09:19 -0800 (PST) Subject: =?gb2312?B?tPC4tDogUkZSIGZvciBKREstNzE5MDEwNiBSTUkgYmVuY2htYXJrIGZhaWxz?= =?gb2312?B?IGludGVybWl0dGVudGx5IGJlY2F1c2Ugb2YgdXNlIG9mIGZpeGVkIHBvcnQ=?= In-Reply-To: <52824B59.9020406@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> Message-ID: <09ed5de7-e061-45b3-9f09-936a624dce1b@default> Thank you Stuart It took me a little time to correct the code. sorry be late. This is new webrev for the code change. Please help to review it again. Description: 1. Convert shell script test to Java program test. 2. Using random server port by reusing Darryl Mocek's work(TestLibrary.getUnusedRandomPort) to replace fixed server port. 3. Because TestLibrary doesn't have package. Here is using reflection to call TestLibrary.getUnusedRandomPort. This is going to change when TestLibrary moves to named package. 4. Using java Process class to start client process. Client and server are sharing IO. 5. Also convert other shell script test runSerialBench.sh to java program test also. 6. ProblemList has been changed to get back java/rmi/reliability/benchmark/runRmiBench.sh test. http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ Thank you so much Tristan -----????----- ???: Stuart Marks ????: Tuesday, November 12, 2013 11:38 PM ???: Tristan Yan ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" port range that's used by some RMI tests that have to used fixed ports. s'marks On 11/11/13 2:39 PM, Tristan Yan wrote: > Hi Stuart > Also there is one more solution, which is there is one > jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same > function as > TestLibrary.getUnusedRandomPort() and it has named package. Do you > mind I use this one? > Since these two functions provide same functionality. Maybe we should > think about to merge them at the same time. > Thank you > Tristan > > On 11/10/2013 11:19 AM, Tristan Yan wrote: >> Hi Stuart >> I tried your suggestion but unfortunately all the benchmarks have >> dependencies to Main class because they need get stub from server. I >> suggest we move the benchmark tests to unnamed package unless we do >> want to put TestLibrary into a named package right now. >> Please let me know if you have objection on this. >> Thank you >> Tristan >> >> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>> Hi Tristan, >>> >>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>> unnamed package. Classes in a named package cannot import classes >>> from the unnamed package. We've run into problems with this before. >>> Eventually, we should move TestLibrary a named package. >>> >>> I think it's possible to work around this without too much >>> difficulty. Note that classes in the unnamed package can import classes from named packages. >>> So, perhaps you can put the RmiBench main class in the unnamed >>> package so it has access to TestLibrary. Then have the benchmarks >>> themselves in the bench.rmi package. The config file already >>> references the benchmarks by fully qualified class name (e.g., >>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able to get this to work. >>> >>> s'marks >>> >>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>> Thank you, Stuart >>>> There is one review point I want to ask you opinion. Which is the >>>> reason that I moved from >>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>> class, I couldn't find a way to let a class which has Package to access the class without package. Do you have suggestion on that? >>>> Thank you so much. >>>> Tristan >>>> >>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>> >>>>> >>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>> Hi Everyone >>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>> >>>>>> Description: >>>>>> 1. Convert shell script test to Java program test. >>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>> replace fixed server port. >>>>>> 3. Using java Process class to start client process. >>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>> program test also >>>>> >>>>> Hi Tristan, >>>>> >>>>> Several comments on this webrev. >>>>> >>>>> >>>>> ** The original arrangement within the >>>>> test/java/rmi/reliability/benchmark >>>>> directory had the main benchmark files (scripts) at the top, some >>>>> benchmark framework files in the "bench" subdirectory, and the >>>>> actual RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>> >>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>> directory but leaves the serial benchmarks in bench/serial. The >>>>> RMI benchmarks are now all cluttering the top directory, but the >>>>> main serial benchmark test is now buried in the bench/serial >>>>> directory. The nice organization that was there before is now >>>>> spoiled. Is this rearrangement necessary in order to convert the scripts to Java? I would prefer the original arrangement be left in place. >>>>> >>>>> >>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>> >>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>>> -c config >>>>> >>>>> There is a subtle but serious problem here: the -server option is >>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>> The main() method gets neither a -server nor a -client argument, >>>>> so its default "run mode" as defined by the benchmark itself is >>>>> SAMEVM. This runs the client and server in the same JVM, which is >>>>> different from the shell script, which ran separate client and server JVMs. >>>>> >>>>> >>>>> ** The logic to process the -server argument still expects to take >>>>> a port, even though the port is assigned automatically. So the >>>>> obvious fix to the above, >>>>> >>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>>> -c config >>>>> >>>>> doesn't work, since a port is missing. The logic to increment the >>>>> argument index to collect the port argument should be removed. >>>>> Also, the -server line should be restored to the usage message, but without the port argument. >>>>> >>>>> >>>>> ** After this is done, the client's command line is constructed improperly. >>>>> The command line ends up looking something like this: >>>>> >>>>> java client -cp Main client localhost:58583 -c >>>>> config >>>>> >>>>> The word "client" appears twice, but what's really required is >>>>> "-client" to appear as an argument after Main. >>>>> >>>>> >>>>> ** The client is run using ProcessBuilder, which by default sends >>>>> stdout and stderr to pipes to be read by the parent. But the >>>>> parent never reads them, thus any messages from the client are >>>>> never seen. The client is the one that emits the benchmark report, >>>>> so its output needs to be seen. It might be sufficient to have the >>>>> client inherit the parent's stdout and stderr. This might intermix >>>>> the client's and server's output, but it's better than nothing. >>>>> >>>>> >>>>> ** The config file is checked with the following code: >>>>> >>>>> try { >>>>> confFile = args[i]; >>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>> + System.getProperty("file.separator") + confFile); >>>>> } catch (IOException e) { >>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>> } >>>>> >>>>> This is potentially misleading, as the message doesn't print the >>>>> actual filename that was attempted to be opened. >>>>> >>>>> This is important, as the test.src property doesn't exist in the client JVM. >>>>> >>>>> Note that the original shell script passed full pathnames for the >>>>> config file to both the client and the server. The new @run tag >>>>> merely says "-c config" which redefines the config filename to be >>>>> relative to the test.src directory. You could pass -Dtest.src=... >>>>> to the client, but it seems like there should be something better than can be done. >>>>> >>>>> >>>>> ** The client needs to have its security policy set up. This is >>>>> missing from the construction of the client's command line. >>>>> >>>>> >>>>> ** ProcessBuilder takes a List for its command; there is >>>>> no need to turn the list into an array. >>>>> >>>>> >>>>> ** In the benchmark main methods, code of the form, >>>>> >>>>> while (true) { >>>>> runBenchmarks(); >>>>> if (exitRequested) { >>>>> System.exit(); >>>>> } >>>>> } >>>>> >>>>> was replaced with >>>>> >>>>> while (!exitRequested) { >>>>> runBenchmarks(); >>>>> } >>>>> >>>>> This is a subtle logic change, in that the former code always >>>>> executed the loop at least once. It seems unlikely, but it's >>>>> possible that a timer could set exitRequested before loop entry, >>>>> resulting in the benchmark running zero times. I guess, if you >>>>> really want to clean this up (we do need to avoid System.exit in jtreg tests), use a do-while loop instead. >>>>> >>>>> >>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>> ProblemList.txt. >>>>> >>>>> >>>>> ** Remove the references to RMISecurityManager and just use >>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>> RMISecurityManager last week.) :-) >>>>> >>>>> >>>>> It would be good if you could fix up these issues and post another webrev. >>>>> >>>>> Thanks. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> >>>>> >>>>>> Thank you >>>>>> Tristan >>>>>> >>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>> I am working on bug >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my >>>>>>>> research, it looks like the issue of fixed port was already >>>>>>>> addressed by Stuart Marks in other RMI tests which are Java based. I would like to reuse his solution, however it does not work for shell based tests. >>>>>>> >>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>> >>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>> through. Most OpenJDK mailing lists strip off attachments before >>>>>>> forwarding Hi Stuart Also there is one more solution, which is >>>>>>> there is one >>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>>> same function as TestLibrary.getUnusedRandomPort() and it has named package. >>>>>>> Do you mind I use this one? >>>>>>> Since these two function provide same functionality. Maybe we >>>>>>> should think about to merge them. >>>>>>> Thank you >>>>>>> Tristan >>>>>>> >>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>> Hi Stuart >>>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>>> have dependencies to Main class because they need get stub from >>>>>>>> server. I suggest we move the benchmark tests to unnamed >>>>>>>> package unless we do want to put TestLibrary into a named package right now. >>>>>>>> Please let me know if you have objection on this. >>>>>>>> Thank you >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>> Hi Tristan, >>>>>>>>> >>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>>> this before. Eventually, we should move TestLibrary a named package. >>>>>>>>> >>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>> Note that classes in the unnamed package can import classes >>>>>>>>> from named packages. So, perhaps you can put the RmiBench main >>>>>>>>> class in the unnamed package so it has access to TestLibrary. >>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>> qualified class name (e.g., >>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>>> be able to get this to work. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>>> >>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>> Thank you, Stuart >>>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>>> the reason that I moved from >>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way to >>>>>>>>>> let a class which has Package to access the class without package. Do you have suggestion on that? >>>>>>>>>> Thank you so much. >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>> Hi Everyone >>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Description: >>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>>> to replace fixed server port. >>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh >>>>>>>>>>>> to java program test also >>>>>>>>>>> >>>>>>>>>>> Hi Tristan, >>>>>>>>>>> >>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>>> RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>>>>>>>> >>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>>> but the main serial benchmark test is now buried in the bench/serial directory. >>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>> scripts to Java? I would prefer the original arrangement be left in place. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>>>> form, >>>>>>>>>>> >>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>>>> Main -c config >>>>>>>>>>> >>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>> option is passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>> argument, so its default "run mode" as defined by the benchmark itself is SAMEVM. >>>>>>>>>>> This runs the client and server in the same JVM, which is >>>>>>>>>>> different from the shell script, which ran separate client and server JVMs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The logic to process the -server argument still expects >>>>>>>>>>> to take a port, even though the port is assigned >>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>> >>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>>> -server -c config >>>>>>>>>>> >>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>> increment the argument index to collect the port argument >>>>>>>>>>> should be removed. Also, the -server line should be restored >>>>>>>>>>> to the usage message, but without the port argument. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>> constructed improperly. The command line ends up looking something like this: >>>>>>>>>>> >>>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>>> -c config >>>>>>>>>>> >>>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>> But the parent never reads them, thus any messages from the client are never seen. >>>>>>>>>>> The client is the one that emits the benchmark report, so >>>>>>>>>>> its output needs to be seen. It might be sufficient to have >>>>>>>>>>> the client inherit the parent's stdout and stderr. This >>>>>>>>>>> might intermix the client's and server's output, but it's better than nothing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>> >>>>>>>>>>> try { >>>>>>>>>>> confFile = args[i]; >>>>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>>> >>>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>>> the client JVM. >>>>>>>>>>> >>>>>>>>>>> Note that the original shell script passed full pathnames >>>>>>>>>>> for the config file to both the client and the server. The >>>>>>>>>>> new @run tag merely says "-c config" which redefines the >>>>>>>>>>> config filename to be relative to the test.src directory. >>>>>>>>>>> You could pass -Dtest.src=... to the client, but it seems >>>>>>>>>>> like there should be something better than can be done. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>> >>>>>>>>>>> while (true) { >>>>>>>>>>> runBenchmarks(); >>>>>>>>>>> if (exitRequested) { >>>>>>>>>>> System.exit(); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> was replaced with >>>>>>>>>>> >>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>> runBenchmarks(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>> always executed the loop at least once. It seems unlikely, >>>>>>>>>>> but it's possible that a timer could set exitRequested >>>>>>>>>>> before loop entry, resulting in the benchmark running zero >>>>>>>>>>> times. I guess, if you really want to clean this up (we do >>>>>>>>>>> need to avoid System.exit in jtreg tests), use a do-while loop instead. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>>> from ProblemList.txt. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>>> another webrev. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> s'marks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thank you >>>>>>>>>>>> Tristan >>>>>>>>>>>> >>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests >>>>>>>>>>>>>> which are Java based. I would like to reuse his solution, >>>>>>>>>>>>>> however it does not work for shell based tests. >>>>>>>>>>>>> >>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>> >>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>>> get through. Most OpenJDK mailing lists strip off >>>>>>>>>>>>> attachments before forwarding the message to the >>>>>>>>>>>>> recipients. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>> script test into Java based test and re-use the dynamic >>>>>>>>>>>>>> port allocation solution by Stuart Marks to address the >>>>>>>>>>>>>> issue >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>>> shell script. In the past there have been sync issues >>>>>>>>>>>>>> between server/client which caused the test to fail. If >>>>>>>>>>>>>> we convert the shell script into Java based test, it >>>>>>>>>>>>>> would avoid using "sleep 10" mechanism to allow for >>>>>>>>>>>>>> server and client to start up and also give us better >>>>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>>>> >>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>>> quite difficult to make reliable shell tests, especially >>>>>>>>>>>>> for multi-process tests like this one. >>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>> issue of how long for the client to wait until the server >>>>>>>>>>>>> is ready. Error handling is also a problem, for example, >>>>>>>>>>>>> if one of the JVMs gets an unexpected exception, it's easy >>>>>>>>>>>>> for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>> erroneously report success. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) >>>>>>>>>>>>> and then post a link to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> s'marks >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> the message to >>>>>>> the recipients. >>>>>>> >>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>> into Java based test and re-use the dynamic port allocation >>>>>>>> solution by Stuart Marks to address the issue >>>>>>>> >>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>> In the >>>>>>>> past there have been sync issues between server/client which >>>>>>>> caused the test to fail. If we convert the shell script into >>>>>>>> Java based test, it would avoid using "sleep 10" mechanism to >>>>>>>> allow for server and client to start up and also give us better >>>>>>>> control in synchronizing server and client. >>>>>>> >>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>> difficult to make reliable shell tests, especially for >>>>>>> multi-process tests like this one. >>>>>>> There is the unique port issue, and there is also the issue of >>>>>>> how long for the client to wait until the server is ready. Error >>>>>>> handling is also a problem, for example, if one of the JVMs gets >>>>>>> an unexpected exception, it's easy for shell tests to mishandle >>>>>>> this case. They might hang or erroneously report success. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>> upload it somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> s'marks >>>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Nov 14 15:22:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 14 Nov 2013 10:22:29 -0500 Subject: RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8 In-Reply-To: <5284E65D.4080803@oracle.com> References: <528392C4.7080207@oracle.com> <52839515.6010509@oracle.com> <5284E65D.4080803@oracle.com> Message-ID: <5284EAB5.5050504@oracle.com> Thanks, Alan. I've looked at this and reviewed it too, so I'll push it. Thanks Harold for sending it out. Coleen On 11/14/2013 10:03 AM, harold seigel wrote: > Hi Alan, > > Thank you for the review. > > Harold > > On 11/13/2013 10:04 AM, Alan Bateman wrote: >> On 13/11/2013 14:55, harold seigel wrote: >>> Hi, >>> >>> Please review this fix, submitted by Ekaterina Pavlova, to update >>> the CDS classlist files for JDK 8. >>> >>> The classlist files were generated using the process described in >>> jdk/make/tools/sharing/README.txt. In addition, a checksum was >>> included. >>> >>> The open webrev is at: >>> http://cr.openjdk.java.net/~hseigel/bug_8023041/ >>> >>> >>> The bug is at: https://bugs.openjdk.java.net/browse/JDK-8023041 >>> >>> Additional information about this change, including testing >>> information, is in the bug. >> Good to see these sync'ed up. I assume this will remove a lot of >> warnings from the build too. >> >> Assuming that the process to generate these was indeed followed then >> I'd suggest going ahead and just push it (as there isn't much we can >> actually review except to spot classes removed from the list that no >> longer exist). >> >> -Alan. >> > From huizhe.wang at oracle.com Thu Nov 14 16:09:51 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 14 Nov 2013 08:09:51 -0800 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter In-Reply-To: <5284AB1B.2020008@oracle.com> References: <5283DAB8.5010707@oracle.com> <5283F045.6020609@oracle.com> <5283F85D.4010704@oracle.com> <5284AB1B.2020008@oracle.com> Message-ID: <5284F5CF.2080004@oracle.com> On 11/14/2013 2:51 AM, Alan Bateman wrote: > On 13/11/2013 22:08, huizhe wang wrote: >> : >> >> Each parser has its own copy of XMLSecurityManager that maintains the >> values of the limits. The parser is reset before it starts to parse a >> document. Resetting the values managed by XMLSecurityManager >> therefore makes sure that the limits are per document. >> >> Daniel sent me a private email to question if the reset in >> PropertyManager is safe. He was right. I traced that back to the >> previous patch in that the StAX parsers actually were sharing the >> same XMLSecurityManager, and also XMLSecurityPropertyManager. I've >> changed the code so that they are cloned. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ > Sorry about that, having it called XMLSecurityManager when it's not a > SecurityManager is always confusing. In that case, it looks okay to me. It was worse if you remember we changed it to XMLSecurityManager from SecurityManager in the 7u45 release, so at least it's XML security manager, not security manager SecurityManager :-) We can refactor it easily if it's annoying to read. But probably next time when we have a bit more time. -Joe > > -Alan. From brian.goetz at oracle.com Thu Nov 14 16:24:09 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 14 Nov 2013 17:24:09 +0100 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <528484F3.5030706@oracle.com> References: <528484F3.5030706@oracle.com> Message-ID: You are right that collect() would be a good start, but sadly there is no DoubleCollector which trucks in doubles. So the concept is right but it doesn't quite get you all the way there. Looking one level down, you'll find a nicer answer. I would look at ReduceOps.makeDouble(), which ultimatley implements the double reduce. It should be obvious how to clone that to use Kahan summing in both the accept and combine methods. Then make sum() perform return evaluate(ReduceOps.makeDoubleKahanSummer()); On Nov 14, 2013, at 9:08 AM, Joe Darcy wrote: > Hello, > > Please take an initial look over a fix for > > JDK-8006572 DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors > http://cr.openjdk.java.net/~darcy/8006572.0/ > > The basic approach is to use compensated summation > > http://en.wikipedia.org/wiki/Kahan_summation_algorithm > > to computed streams-related sum and average statistics in the various locations that this can be done. > > All existing streams tests pass and new newly-written test passes too. > > I believe the DoubleSummaryStatistics.java portion, including the test, is fully review-worthy. In the test, for the sample computation in question, the naive summation implementation had a error of 500,000 ulps compared to 2 ups with the new implementation. > > Two other locations I've found where this summation technique should be used are in > > java.util.stream.Collectors.{summingDouble, averagingDouble} > > and > > java.util.stream.DoublePipeline.{sum, average} > > DoublePipeline is the primary implementation class of DoubleStream. > > For Collectors, the proposed code is a fairly clear adaptation of how the current code passes state around; there is not currently a dedicated test for the new summation technique in this location. > > I'm new to the streams API so for DoublePipeline I don't know the idiomatic way to phrase the collect I want to perform over the code. (Based on my current understanding, I believe I want to perform a collect rather than a reduce since for the compensated summation I need to maintain some additional state.) Guidance here welcome. > > Thanks, > > -Joe From volker.simonis at gmail.com Thu Nov 14 16:35:16 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Nov 2013 17:35:16 +0100 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' Message-ID: Hi, I wanted to solve "8026964: Building with an IBM J9 boot jdk requires special settings for BOOT_RTJAR" (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the question what the real semantics of BOOT_RTJAR is? Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not found). For an IBM J9 boot JDK however this is not so easy because some essential classes (like Object or String) are not contained in "rt.jar" (see the before mentioned bug for more details). So for IBM J9 we need to add additional jar-files to BOOT_RTJAR. Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are the required classes it should contain? Naively I would assume these are the classes contained in the "sun.boot.class.path" system property. But for an OpenJDK/Oracle based JDK, this property contains much more classes than just rt.jar: sun.boot.class.path= \ /jre/lib/resources.jar \ /jre/lib/rt.jar \ /jre/lib/sunrsasign.jar \ /jre/lib/jsse.jar \ /jre/lib/jce.jar \ /jre/lib/charsets.jar \ /jre/lib/jfr.jar \ /jre/classes The Oracle documentation I could find ("How Classes are Found" at http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html) states: "...Bootstrap classes are the classes that implement the Java 2 Platform. Bootstrap classes are in the rt.jar and several other jar files in the jre/lib directory. These archives are specified by the value of the bootstrap class path which is stored in the sun.boot.class.path system property..." So for me it seems that the current solution of using just "rt.jar" works only accidentally until now and it would be more logical to set BOOT_RTJAR to the value of "sun.boot.class.path". This value could be queried during the configure process (e.g. by using the -XshowSettings option). As far as I can see '-XshowSettings' and the "sun.boot.class.path" property is supported on all the JDKs I know (OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM). So my question is, if there are any objectives if I'd change the current BOOT_RTJAR detection to the following lines: # Parse the settings of the 'sun.boot.class.path' property # The tricky thing is that we must quote AWK field references (i.e. $1, $2, ..) # and the name 'index' which is a M4-buildin function by placing brackets # (i.e. '[]') into the corresponding names. BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \ /path.separator/ { path_separator = $[]3} \ /sun.boot.class.path/ { sun_boot_class_path = $[]3; \ while (getline && !in[]dex($[]0,"=")) { \ sun_boot_class_path = sun_boot_class_path "\n" $[]1 \ } \ } \ END { gsub("\n", path_separator, sun_boot_class_path); print sun_boot_class_path }'` which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path' (separated by the valid platform path separator which is also queried from the output of '-XshowSettings'). I've tested this and it works on Linux and Solaris with an OppenJDK based boot JDK and on AIX with the IBM J9 boot JDK. I think it would be more robust for other JDKs as well. And of course it fixes my bug:) So if there are no general objections I'll be happy to prepare a formal webrev for this issue. Regards, Volker From daniel.fuchs at oracle.com Thu Nov 14 17:12:22 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 Nov 2013 18:12:22 +0100 Subject: RFR (JAXP): 8028111 : XML readers share the same entity expansion counter In-Reply-To: <5283F85D.4010704@oracle.com> References: <5283DAB8.5010707@oracle.com> <5283F045.6020609@oracle.com> <5283F85D.4010704@oracle.com> Message-ID: <52850476.20700@oracle.com> Hi Joe, The new webrev looks good... -- daniel On 11/13/13 11:08 PM, huizhe wang wrote: > > On 11/13/2013 1:33 PM, Alan Bateman wrote: >> On 13/11/2013 20:02, huizhe wang wrote: >>> Hi, >>> >>> The issue is that the limits applied to each processing process >>> rather than each file processing. This applies to not only StAX as >>> reported, but also other parsers and validators. The fix is to add >>> reset to XMLSecurityManager and call it upon each file processing. >>> XSLT Transform is verified fixed as the underlying parsers are fixed. >>> >>> webrev: >>> http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ >> This looks okay as a band-aid but won't this be replaced if fixed to >> have limits per document? > > Each parser has its own copy of XMLSecurityManager that maintains the > values of the limits. The parser is reset before it starts to parse a > document. Resetting the values managed by XMLSecurityManager therefore > makes sure that the limits are per document. > > Daniel sent me a private email to question if the reset in > PropertyManager is safe. He was right. I traced that back to the > previous patch in that the StAX parsers actually were sharing the same > XMLSecurityManager, and also XMLSecurityPropertyManager. I've changed > the code so that they are cloned. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8028111/webrev/ > > Thanks, > Joe > >> >> -Alan. > From eric.mccorkle at oracle.com Thu Nov 14 17:33:25 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 14 Nov 2013 17:33:25 +0000 Subject: hg: jdk8/tl/langtools: 8028282: Remove @ignore from test langtools/test/tools/javac/T7042623.java Message-ID: <20131114173330.0D859625BF@hg.openjdk.java.net> Changeset: 24eaf41a3974 Author: emc Date: 2013-11-14 12:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/24eaf41a3974 8028282: Remove @ignore from test langtools/test/tools/javac/T7042623.java Summary: Remove @ignore from test Reviewed-by: jjg ! test/tools/javac/T7042623.java From staffan.larsen at oracle.com Thu Nov 14 18:34:23 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 14 Nov 2013 18:34:23 +0000 Subject: hg: jdk8/tl/jdk: 8027765: Make exit codes and stdout/stderr printing from jmap/jinfo/jstack/jps consistent Message-ID: <20131114183436.E0B7A625CE@hg.openjdk.java.net> Changeset: 65f7b83ab477 Author: sla Date: 2013-11-14 19:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65f7b83ab477 8027765: Make exit codes and stdout/stderr printing from jmap/jinfo/jstack/jps consistent Reviewed-by: alanb, allwin, sspitsyn, mgronlun ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java From bill.shannon at oracle.com Thu Nov 14 19:12:08 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Thu, 14 Nov 2013 11:12:08 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5284DBA7.2050803@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> <5284DBA7.2050803@oracle.com> Message-ID: <52852088.9080100@oracle.com> Alan Bateman wrote on 11/14/2013 06:18 AM: > On 13/11/2013 20:28, Xueming Shen wrote: >> >> Yes, the plan is to see what other implementations do. > I think we've run out road on this for JDK 8. Even if we had agreement on > dealing with corrupt input then there is little/no time to get feedback and do > any further adjustments. Technically only showstopper API changes have been > allowed since October so we have been on borrowed time anyway. Also we're coming > up on RDP2 so we'd have to justify any changes as showstoppers. > > So what you would think about just leaving it strict for JDK 8 and then continue > the work to see how lenient support should be exposed in the API so that it can > go into JDK 9 early. That would allow you to consider whether it to have a means > to get a Decoder that will consume all sewage or just decode up to the point > where invalid chars or undeflow is detected. Also it probably is a bit > inconsistent to have only decode buffer method stop (as proposed) so that could > be looked at too. > > If you agree then there is a bit of clean-up to do with the changes for 8025003 > that were pushed but I think that can be justified. Making it strict is fine, but right now it's half-lenient, and you need a way to use/wrap the APIs to ignore the errors and provide as much data as possible. From xueming.shen at oracle.com Thu Nov 14 19:20:15 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 14 Nov 2013 11:20:15 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <52852088.9080100@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> <5284DBA7.2050803@oracle.com> <52852088.9080100@oracle.com> Message-ID: <5285226F.8080707@oracle.com> On 11/14/2013 11:12 AM, Bill Shannon wrote: > Alan Bateman wrote on 11/14/2013 06:18 AM: >> On 13/11/2013 20:28, Xueming Shen wrote: >>> Yes, the plan is to see what other implementations do. >> I think we've run out road on this for JDK 8. Even if we had agreement on >> dealing with corrupt input then there is little/no time to get feedback and do >> any further adjustments. Technically only showstopper API changes have been >> allowed since October so we have been on borrowed time anyway. Also we're coming >> up on RDP2 so we'd have to justify any changes as showstoppers. >> >> So what you would think about just leaving it strict for JDK 8 and then continue >> the work to see how lenient support should be exposed in the API so that it can >> go into JDK 9 early. That would allow you to consider whether it to have a means >> to get a Decoder that will consume all sewage or just decode up to the point >> where invalid chars or undeflow is detected. Also it probably is a bit >> inconsistent to have only decode buffer method stop (as proposed) so that could >> be looked at too. >> >> If you agree then there is a bit of clean-up to do with the changes for 8025003 >> that were pushed but I think that can be justified. > Making it strict is fine, but right now it's half-lenient, and you need a way > to use/wrap the APIs to ignore the errors and provide as much data as possible. The webrev I posted yesterday is to put the mime decoder back to "strict". However it keeps the change in decode(buffer, buffer), which leaves the position of src and dst at the place that the malformed occurred (-1 is being returned now. an alternative is to return the negative value of the the bytes written...). With the assumption that the "decoded bytes" might still be valuable for some use scenario, given decode(buffer, buffer) is supposed to be an "advanced" api with some degree of "recovery" functionality, such as the output buffer is not big enough... But if the consensus is this is kinda of inconsistent compared to other decode variants (which throws away any decided bytes, if error occurs), I'm happy to back out this change and back to the original spec/implementation (1) throw IAE if malformed detected (2) reset the pos of src and dst buffer to their original position when the method is invoked. http://cr.openjdk.java.net/~sherman/base64_malformed2/webrev/ -Sherman From vicente.romero at oracle.com Thu Nov 14 19:28:57 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 14 Nov 2013 19:28:57 +0000 Subject: hg: jdk8/tl/langtools: 8026963: type annotations code crashes for code with erroneous trees Message-ID: <20131114192901.60365625F2@hg.openjdk.java.net> Changeset: e79d6425f1c4 Author: vromero Date: 2013-11-14 19:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e79d6425f1c4 8026963: type annotations code crashes for code with erroneous trees Reviewed-by: jjg, jlahoda ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.java + test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.out From coleen.phillimore at oracle.com Thu Nov 14 19:18:26 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 14 Nov 2013 19:18:26 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131114191851.C3BDD625F0@hg.openjdk.java.net> Changeset: 59f46f135584 Author: hseigel Date: 2013-11-14 10:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59f46f135584 8023041: The CDS classlist needs to be updated for JDK 8 Summary: Generate new classlists from JDK 8 classes Reviewed-by: alanb, coleenp, hseigel Contributed-by: ekaterina.pavlova at oracle.com ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.macosx ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows Changeset: f893901ba29c Author: coleenp Date: 2013-11-14 14:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f893901ba29c Merge From xueming.shen at oracle.com Thu Nov 14 20:59:59 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 14 Nov 2013 12:59:59 -0800 Subject: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8 Message-ID: <528539CF.1010200@oracle.com> Hi, The consensus/conclusion from the discussion [1] regarding the changes we made earlier for JDK-8025003 [2] is to back out the existing "half-lenient" change to leave the door open for a clean "lenient" support for future releases. Here is the webrev for the undo (keep the mime encoder(...) rename change) http://cr.openjdk.java.net/~sherman/8028397/webrev Thanks! -Sherman [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023048.html [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/e7bdb2fcc7bc From mark.sheppard at oracle.com Thu Nov 14 21:37:42 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 14 Nov 2013 21:37:42 +0000 Subject: RFR: JDK-8028215 - ORB.init fails with SecurityException if properties select the JDK default ORB Message-ID: <528542A6.8020806@oracle.com> Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8028215/webrev/ which addresses the issue detailed in https://bugs.openjdk.java.net/browse/JDK-8028215 This addresses an ORB initialization problem, which has arisen when the com.sun.corba.se.** packages were added to the restricted package list. regards Mark From bhavesh.x.patel at oracle.com Thu Nov 14 21:48:47 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 14 Nov 2013 21:48:47 +0000 Subject: hg: jdk8/tl/langtools: 8025524: javadoc does not correctly locate constructors for nested classes Message-ID: <20131114214851.77B44625FA@hg.openjdk.java.net> Changeset: 5ae66d372d57 Author: bpatel Date: 2013-11-14 13:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5ae66d372d57 8025524: javadoc does not correctly locate constructors for nested classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java + test/com/sun/javadoc/testConstructors/TestConstructors.java + test/com/sun/javadoc/testConstructors/pkg1/Outer.java ! test/tools/javadoc/generics/genericInnerAndOuter/expected.out From kumar.x.srinivasan at oracle.com Thu Nov 14 22:57:56 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 14 Nov 2013 14:57:56 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm Message-ID: <52855574.80703@oracle.com> Hello, Please review fixes to the launcher tests, which allows for missing server vm variant. All SE platforms have server vm, however Embedded SE systems do not contain server, most of them have client, thus these tests needed to be compensated for that. http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ Thanks Kumar From bill.shannon at oracle.com Thu Nov 14 23:27:08 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Thu, 14 Nov 2013 15:27:08 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <5285226F.8080707@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> <5284DBA7.2050803@oracle.com> <52852088.9080100@oracle.com> <5285226F.8080707@oracle.com> Message-ID: <52855C4C.8050504@oracle.com> Xueming Shen wrote on 11/14/2013 11:20 AM: > On 11/14/2013 11:12 AM, Bill Shannon wrote: >> Alan Bateman wrote on 11/14/2013 06:18 AM: >>> On 13/11/2013 20:28, Xueming Shen wrote: >>>> Yes, the plan is to see what other implementations do. >>> I think we've run out road on this for JDK 8. Even if we had agreement on >>> dealing with corrupt input then there is little/no time to get feedback and do >>> any further adjustments. Technically only showstopper API changes have been >>> allowed since October so we have been on borrowed time anyway. Also we're coming >>> up on RDP2 so we'd have to justify any changes as showstoppers. >>> >>> So what you would think about just leaving it strict for JDK 8 and then continue >>> the work to see how lenient support should be exposed in the API so that it can >>> go into JDK 9 early. That would allow you to consider whether it to have a means >>> to get a Decoder that will consume all sewage or just decode up to the point >>> where invalid chars or undeflow is detected. Also it probably is a bit >>> inconsistent to have only decode buffer method stop (as proposed) so that could >>> be looked at too. >>> >>> If you agree then there is a bit of clean-up to do with the changes for 8025003 >>> that were pushed but I think that can be justified. >> Making it strict is fine, but right now it's half-lenient, and you need a way >> to use/wrap the APIs to ignore the errors and provide as much data as possible. > > The webrev I posted yesterday is to put the mime decoder back to "strict". > However it keeps > the change in decode(buffer, buffer), which leaves the position of src and dst > at the place that > the malformed occurred (-1 is being returned now. an alternative is to return > the negative value > of the the bytes written...). With the assumption that the "decoded bytes" might > still be valuable > for some use scenario, given decode(buffer, buffer) is supposed to be an > "advanced" api with > some degree of "recovery" functionality, such as the output buffer is not big > enough... > > But if the consensus is this is kinda of inconsistent compared to other decode > variants (which > throws away any decided bytes, if error occurs), I'm happy to back out this > change and back > to the original spec/implementation (1) throw IAE if malformed detected (2) > reset the pos of > src and dst buffer to their original position when the method is invoked. > > http://cr.openjdk.java.net/~sherman/base64_malformed2/webrev/ I'd prefer that all variants of the API report the error in a way that allows the users of the API to ignore the error, access the data that caused the error, and supply replacement data if desired. For most of the APIs, decoding as much data as possible and throwing an exception with details about how much has been decoded and where the error was detected would be best. I understand that designing this and getting it right might exceed what you can do in this release. In that case, just throw an exception with no details, and we can figure out what details to provide later. Returning a negative number is kind of a hack, and unlike most other APIs. Plus, if we decide we need to return two numbers (e.g., input and output positions), there's no way to extend it. From mandy.chung at oracle.com Thu Nov 14 23:31:26 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Nov 2013 15:31:26 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <52855574.80703@oracle.com> References: <52855574.80703@oracle.com> Message-ID: <52855D4E.8040300@oracle.com> Hi Kumar, On 11/14/2013 2:57 PM, Kumar Srinivasan wrote: > Hello, > > Please review fixes to the launcher tests, which allows for missing > server vm variant. > > All SE platforms have server vm, however Embedded SE systems do > not contain server, most of them have client, thus these > tests needed to be compensated for that. > > http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ > In ExecutionEnvironment.java, I understand the fix in line 251 and 257 that address the bug reported. However, I don't understand why doExec calls to launch javaCmd has to specify "-server" or "client". The jdk should have a default VM and should the test use that? TestHelper.java 144 JAVA_JRE_LIB = new File((new File(JAVAHOME)).getParentFile(), 145 (isSDK) ? "jre/lib" : "lib").getAbsolutePath(); If JAVA_HOME is a JDK build (or JRE image), does this give you an incorrect path? I expect getParentFile() is not needed in that case. This is copy-n-paste in many places. Does the test require to run on JDK image (not JDK build)? 189 private static boolean haveVmVariant(String type) { 190 if (isWindows) { 191 File vmDir = new File(JAVA_JRE_BIN, type); 192 File jvmFile = new File(vmDir, JVM_DLL); jvm.dll should be under jre/bin/client or jre/bin/server as in other arch, right? Mandy From david.holmes at oracle.com Thu Nov 14 23:32:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Nov 2013 09:32:47 +1000 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' In-Reply-To: References: Message-ID: <52855D9F.4040300@oracle.com> Hi Volker, On 15/11/2013 2:35 AM, Volker Simonis wrote: > Hi, > > I wanted to solve "8026964: Building with an IBM J9 boot jdk requires > special settings for BOOT_RTJAR" > (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the > question what the real semantics of BOOT_RTJAR is? For the combination of the OpenJDK libraries and VM it really just meant rt.jar (not everything on the bootclasspath) as the build system "knows" what is in there and that it is what was needed. The other boot classpath stuff is not relevant to the build processes that set the bootclasspath. I don't see an issue with generalizing it to the full boot classpath but is it necessary? Can't you just define it to be rt.jar plus whatever jar(s) is needed for J9? Cheers, David > Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set > to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not > found). For an IBM J9 boot JDK however this is not so easy because > some essential classes (like Object or String) are not contained in > "rt.jar" (see the before mentioned bug for more details). So for IBM > J9 we need to add additional jar-files to BOOT_RTJAR. > > Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are > the required classes it should contain? Naively I would assume these > are the classes contained in the "sun.boot.class.path" system > property. But for an OpenJDK/Oracle based JDK, this property contains > much more classes than just rt.jar: > > sun.boot.class.path= \ > /jre/lib/resources.jar \ > /jre/lib/rt.jar \ > /jre/lib/sunrsasign.jar \ > /jre/lib/jsse.jar \ > /jre/lib/jce.jar \ > /jre/lib/charsets.jar \ > /jre/lib/jfr.jar \ > /jre/classes > > > The Oracle documentation I could find ("How Classes are Found" at > http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html) > states: "...Bootstrap classes are the classes that implement the Java > 2 Platform. Bootstrap classes are in the rt.jar and several other jar > files in the jre/lib directory. These archives are specified by the > value of the bootstrap class path which is stored in the > sun.boot.class.path system property..." > > So for me it seems that the current solution of using just "rt.jar" > works only accidentally until now and it would be more logical to set > BOOT_RTJAR to the value of "sun.boot.class.path". This value could be > queried during the configure process (e.g. by using the -XshowSettings > option). As far as I can see '-XshowSettings' and the > "sun.boot.class.path" property is supported on all the JDKs I know > (OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM). > > So my question is, if there are any objectives if I'd change the > current BOOT_RTJAR detection to the following lines: > > # Parse the settings of the 'sun.boot.class.path' property > # The tricky thing is that we must quote AWK field references (i.e. > $1, $2, ..) > # and the name 'index' which is a M4-buildin function by placing brackets > # (i.e. '[]') into the corresponding names. > BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \ > /path.separator/ { path_separator = $[]3} \ > /sun.boot.class.path/ { sun_boot_class_path = $[]3; \ > while (getline && !in[]dex($[]0,"=")) { \ > sun_boot_class_path = > sun_boot_class_path "\n" $[]1 \ > } \ > } \ > END { gsub("\n", path_separator, sun_boot_class_path); print > sun_boot_class_path }'` > > which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path' > (separated by the valid platform path separator which is also queried > from the output of '-XshowSettings'). > > I've tested this and it works on Linux and Solaris with an OppenJDK > based boot JDK and on AIX with the IBM J9 boot JDK. I think it would > be more robust for other JDKs as well. And of course it fixes my bug:) > > So if there are no general objections I'll be happy to prepare a > formal webrev for this issue. > > Regards, > Volker > From stuart.marks at oracle.com Thu Nov 14 23:56:14 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 15 Nov 2013 00:56:14 +0100 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <52842184.4030606@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> <52842184.4030606@oracle.com> Message-ID: <5285631E.6060801@oracle.com> On 11/14/13 2:04 AM, David Holmes wrote: > Sorry for the delay (been enroute). Only issue I have remains the subSequence > change - you can't weaken the post-condition of CharSequence.subSequence without > breaking subtype substitutability. Hi David, Yes, in general, what you say about weakening post-conditions is true. In this case, though, I can't see how it can cause any practical harm. I think the CharSequence spec for subSequence() is written with the assumption that the CharSequence is mutable. If I'm not mistaken, all the CharSequence implementations except for String are mutable. Thus, in the statement Returns a new CharSequence that is a subsequence of this sequence. the "new" really means that if the value of this sequence is later mutated, it will not affect the value of the returned sequence. Well, strictly speaking, it's ambiguous; the "new" could refer to either the sequences' values, the reference identity of this vs the returned sequence, or both. I'd say that for the mutable CharSequences, keeping the values independent is the important part, and having independent values pretty much implies that the returned sequence is a distinct object. Since Strings are immutable, there is no concern about mutation of the value of the original String affecting the value of the returned String. That leaves reference identity. Obviously identity of mutable objects is really important. For immutable objects, identity is much less important, and so I'm trying to relax the spec to allow more discretion to the implementation about when to create new objects. I guess our choices are as follows: 0) Current webrev: remove "new" from String's spec for subSequence(). Allows 'this' to be returned in certain cases, but weakens the post-condition of its definining interface, which is usually a no-no. 1) Leave String.subSequence() as it stands, requiring a new CharSequence. This fixes the relationship with the CS interface, but the current implementation violates this spec, as it returns 'this' in some cases (where the subSequence represents the entire String). 2) Leave String.subSequence() as it stands, requiring a new CharSequence, and change the implementation so that it always creates a new String, even if the subSequence represents the entire original String. 3) Change the CharSequence.subSequence() spec to be more precise about what it requires (mutation of one doesn't affect the other), allowing String.subSequence() to return 'this' when it can. Anything else? I don't like (1) as it leaves our implementation in violation of a close reading of the spec. I don't like (2) as it de-optimizes the current implementation. I could live with (3) but it's more work, as new wording will have to be generated, and its impact on the other CS implementations will need to be assessed. It would probably result in the "best" (as in, most precise and self-consistent) specification, but I have to question whether it's worth the effort. I still prefer (0), though I acknowledge it does have this issue of weakening the interface's post-condition. I note that there are other places where an implementation doesn't strictly conform to its interface, such as IdentityHashMap and Map. Another possibility, I guess, would be to do something like adding an @apiNote to String.subSequence() explaining why it's different from CS.subSequence(). s'marks > Thanks, > David > > On 12/11/2013 8:43 AM, Stuart Marks wrote: >> Hi all, >> >> Here's an updated version of the String spec change. Changes from the >> previous version address comments made by Brent Christian and David >> Holmes. Specifically: >> >> - Specify copyValueOf() overloads as "equivalent to" corresponding >> valueOf() overloads. >> - Remove extranous changes to subSequence() method >> - Clarify wording of concat() method doc. >> >> Bug report: >> >> https://bugs.openjdk.java.net/browse/JDK-7174936 >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/ >> >> Specdiff: >> >> >> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html >> >> >> Thanks! >> >> s'marks >> >> On 11/7/13 2:31 AM, Stuart Marks wrote: >>> Hi all, >>> >>> Please review the following spec changes to java.lang.String. >>> >>> In several places the specs mention returning "new" strings. This is >>> overspecified; it's sufficient to return "a" string that satisfies the >>> required >>> properties. In some cases the current implementation doesn't create a >>> new string >>> -- for example, substring(0) returns 'this' -- which is strictly a >>> violation of >>> the spec. The solution is to relax the spec requirement to create new >>> strings. >>> >>> Also, this change cleans up the specs for the copyValueOf() overloads >>> to make >>> them identical to the corresponding valueOf() overloads. Previously, >>> they were >>> gratuitously different. I think that some time in the dim, distant past, >>> probably before JDK 1.0, they had different semantics, but now they're >>> identical. The specs should say they're identical. >>> >>> This change is spec only, no code changes. >>> >>> Bug report: >>> >>> https://bugs.openjdk.java.net/browse/jdk-7174936 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ >>> >>> Specdiff: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html >>> >>> >>> >>> Thanks! >>> >>> s'marks From xuelei.fan at oracle.com Fri Nov 15 00:09:50 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 15 Nov 2013 00:09:50 +0000 Subject: hg: jdk8/tl/jdk: 8014266: regression test AsyncSSLSocketClose.java time out. Message-ID: <20131115001002.D76A3625FF@hg.openjdk.java.net> Changeset: 40d0ccd00f87 Author: xuelei Date: 2013-11-14 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d0ccd00f87 8014266: regression test AsyncSSLSocketClose.java time out. Reviewed-by: xuelei Contributed-by: Rajan Halade ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java From kumar.x.srinivasan at oracle.com Fri Nov 15 02:54:09 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 14 Nov 2013 18:54:09 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <52855D4E.8040300@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> Message-ID: <52858CD1.1050203@oracle.com> Hi Mandy, Thanks for reviewing this, comments inlined. > Hi Kumar, > > On 11/14/2013 2:57 PM, Kumar Srinivasan wrote: >> Hello, >> >> Please review fixes to the launcher tests, which allows for missing >> server vm variant. >> >> All SE platforms have server vm, however Embedded SE systems do >> not contain server, most of them have client, thus these >> tests needed to be compensated for that. >> >> http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ >> > > In ExecutionEnvironment.java, I understand the fix in line 251 and 257 > that address the bug reported. However, I don't understand why doExec > calls to launch javaCmd has to specify "-server" or "client". The > jdk should have a default VM and should the test use that? I was being over-zealous, and trying not to rely on jvm.cfg, note that jvm.cfg aliases -client to -server on 64-bit systems, I removed these changes, as it does not add anything. > > TestHelper.java > > 144 JAVA_JRE_LIB = new File((new > File(JAVAHOME)).getParentFile(), > 145 (isSDK) ? "jre/lib" : > "lib").getAbsolutePath(); > > If JAVA_HOME is a JDK build (or JRE image), does this give you > an incorrect path? I expect getParentFile() is not needed in that case. You are right this is an error, fixed. > This is copy-n-paste in many places. Does the test require > to run on JDK image (not JDK build)? The test runs on both j2sdk-image and JDK build, I use both during development with the old infra/jdk7. With the new infra I use only images, because it is much faster now to create images, also on Solaris images are mandatory, because solaris symlinks exists only in the the images and there is a test which checks for these in ExecutionEnvironment.java. Note: these tests cannot be run on j2re-image as jtreg and the test itself needs the compiler, downside of converting to java tests. > > 189 private static boolean haveVmVariant(String type) { > 190 if (isWindows) { > 191 File vmDir = new File(JAVA_JRE_BIN, type); > 192 File jvmFile = new File(vmDir, JVM_DLL); > > > jvm.dll should be under jre/bin/client or jre/bin/server as in other > arch, right? Right windows no arch directory,output below. % find . -name jvm.dll ./j2re-image/bin/server/jvm.dll ./j2sdk-image/jre/bin/server/jvm.dll ./j2sdk-server-image/jre/bin/server/jvm.dll *nixes do have arch directory (i386, amd64, ppc, etc). A minor refactoring done. New full webrev: http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html Delta webrev wrt. webrev.0 http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html Kumar > > Mandy From joe.darcy at oracle.com Fri Nov 15 03:00:40 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 14 Nov 2013 19:00:40 -0800 Subject: Assorted annotation optimizations In-Reply-To: <8713B570-DC40-4C1A-BE6B-81ACB0972A21@oracle.com> References: <52757570.5010503@gmail.com> <8713B570-DC40-4C1A-BE6B-81ACB0972A21@oracle.com> Message-ID: <52858E58.50800@oracle.com> Joel, If you haven't done so already, please file an rfe to capture Peter's suggestions. Thanks, -Joe On 11/4/2013 7:29 AM, Joel Borggr?n-Franck wrote: > Hi Peter, > > As always, thanks for doing this! > > On 2 nov 2013, at 22:58, Peter Levart wrote: > >> 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/ > > Skimming this, I think most (or all) of this is good. However now is not the time to do it. This should go into 9 and 8u as soon as they are open for fixes. > > FWIW I have also been toying with the idea of rewriting the storage of annotations in 9. IIRC you posted a patch with a very specific map for annotations. If we go down that road we should probably do a JEP. > > cheers > /Joel From mandy.chung at oracle.com Fri Nov 15 03:11:07 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Nov 2013 19:11:07 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <52858CD1.1050203@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> <52858CD1.1050203@oracle.com> Message-ID: <528590CB.6040301@oracle.com> On 11/14/2013 6:54 PM, Kumar Srinivasan wrote: > New full webrev: > http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html > > Delta webrev wrt. webrev.0 > http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html > > This looks much better. Nit: JAVA_LIB could be interpreted as jdk/lib which contains tools.jar etc which is the case when you run the test with jdk image. If you run the test with JDK build, jdk/lib doesn't contain tools.jar (but its classes are in the bootclasspath). JAVA_LIB is not currently used. While there is no issue with it, perhaps better to take it out and define it when there is a concrete use of it. It's really minor and will leave it up to you. Mandy From joe.darcy at oracle.com Fri Nov 15 03:21:38 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 14 Nov 2013 19:21:38 -0800 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52722FC9.70607@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> Message-ID: <52859342.7040709@oracle.com> Hello, Catching up on email, the specification of java.lang.Class does not explicitly promise that its notion of equality must be identity for all time. Therefore, while not required for today's implementations, I would prefer that new code we write in the JDK use equals rather than == when comparing classes. Cheers, -Joe On 10/31/2013 3:24 AM, David Holmes wrote: > Hi Andreas, > > On 31/10/2013 7:49 PM, Andreas Lundblad wrote: >> Hi, >> >> Please review the fix for JDK-8027470 below. >> >> Description: >> AnnotationSupport compared Class-instances using '==' where it should >> be using '.equals'. Fixed in this patch. > > Class is final and does not override Object.equals therefore it is > guaranteed to be based on identity. This change, while harmless, is > unnecessary. Comparison of Class instances with == occurs throughout > the JDK. > > David > ----- > >> Link to web review: >> http://cr.openjdk.java.net/~alundblad/8027470 >> >> Link to bug reports: >> http://bugs.openjdk.java.net/browse/JDK-8027470 >> >> -- Andreas Lundblad >> From david.holmes at oracle.com Fri Nov 15 05:00:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Nov 2013 15:00:53 +1000 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <5285631E.6060801@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> <52842184.4030606@oracle.com> <5285631E.6060801@oracle.com> Message-ID: <5285AA85.4090606@oracle.com> Hi Stuart, On 15/11/2013 9:56 AM, Stuart Marks wrote: > > > On 11/14/13 2:04 AM, David Holmes wrote: >> Sorry for the delay (been enroute). Only issue I have remains the >> subSequence >> change - you can't weaken the post-condition of >> CharSequence.subSequence without >> breaking subtype substitutability. > > Hi David, > > Yes, in general, what you say about weakening post-conditions is true. > In this case, though, I can't see how it can cause any practical harm. > > I think the CharSequence spec for subSequence() is written with the > assumption that the CharSequence is mutable. If I'm not mistaken, all > the CharSequence implementations except for String are mutable. Thus, in > the statement > > Returns a new CharSequence that is a subsequence of this sequence. > > the "new" really means that if the value of this sequence is later > mutated, it will not affect the value of the returned sequence. Well, > strictly speaking, it's ambiguous; the "new" could refer to either the > sequences' values, the reference identity of this vs the returned > sequence, or both. I'd say that for the mutable CharSequences, keeping > the values independent is the important part, and having independent > values pretty much implies that the returned sequence is a distinct object. > > Since Strings are immutable, there is no concern about mutation of the > value of the original String affecting the value of the returned String. > That leaves reference identity. Obviously identity of mutable objects is > really important. For immutable objects, identity is much less > important, and so I'm trying to relax the spec to allow more discretion > to the implementation about when to create new objects. > > I guess our choices are as follows: > > 0) Current webrev: remove "new" from String's spec for subSequence(). > Allows 'this' to be returned in certain cases, but weakens the > post-condition of its definining interface, which is usually a no-no. I think this is "wrong" but as you note there is precedent for "adjusting" things this way. > 1) Leave String.subSequence() as it stands, requiring a new > CharSequence. This fixes the relationship with the CS interface, but the > current implementation violates this spec, as it returns 'this' in some > cases (where the subSequence represents the entire String). Also wrong as you note. > 2) Leave String.subSequence() as it stands, requiring a new > CharSequence, and change the implementation so that it always creates a > new String, even if the subSequence represents the entire original String. This is correct and less work than making spec changes, but doesn't achieve the objective of the overall change. > 3) Change the CharSequence.subSequence() spec to be more precise about > what it requires (mutation of one doesn't affect the other), allowing > String.subSequence() to return 'this' when it can. This is right and probably not too much more additional work :) But let someone else weigh in on this. Thanks, David > Anything else? > > I don't like (1) as it leaves our implementation in violation of a close > reading of the spec. I don't like (2) as it de-optimizes the current > implementation. I could live with (3) but it's more work, as new wording > will have to be generated, and its impact on the other CS > implementations will need to be assessed. It would probably result in > the "best" (as in, most precise and self-consistent) specification, but > I have to question whether it's worth the effort. > > I still prefer (0), though I acknowledge it does have this issue of > weakening the interface's post-condition. I note that there are other > places where an implementation doesn't strictly conform to its > interface, such as IdentityHashMap and Map. Another possibility, I > guess, would be to do something like adding an @apiNote to > String.subSequence() explaining why it's different from CS.subSequence(). > > s'marks > > > > > > > > > >> Thanks, >> David >> >> On 12/11/2013 8:43 AM, Stuart Marks wrote: >>> Hi all, >>> >>> Here's an updated version of the String spec change. Changes from the >>> previous version address comments made by Brent Christian and David >>> Holmes. Specifically: >>> >>> - Specify copyValueOf() overloads as "equivalent to" corresponding >>> valueOf() overloads. >>> - Remove extranous changes to subSequence() method >>> - Clarify wording of concat() method doc. >>> >>> Bug report: >>> >>> https://bugs.openjdk.java.net/browse/JDK-7174936 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.1/ >>> >>> Specdiff: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.1/overview-summary.html >>> >>> >>> >>> Thanks! >>> >>> s'marks >>> >>> On 11/7/13 2:31 AM, Stuart Marks wrote: >>>> Hi all, >>>> >>>> Please review the following spec changes to java.lang.String. >>>> >>>> In several places the specs mention returning "new" strings. This is >>>> overspecified; it's sufficient to return "a" string that satisfies the >>>> required >>>> properties. In some cases the current implementation doesn't create a >>>> new string >>>> -- for example, substring(0) returns 'this' -- which is strictly a >>>> violation of >>>> the spec. The solution is to relax the spec requirement to create new >>>> strings. >>>> >>>> Also, this change cleans up the specs for the copyValueOf() overloads >>>> to make >>>> them identical to the corresponding valueOf() overloads. Previously, >>>> they were >>>> gratuitously different. I think that some time in the dim, distant >>>> past, >>>> probably before JDK 1.0, they had different semantics, but now they're >>>> identical. The specs should say they're identical. >>>> >>>> This change is spec only, no code changes. >>>> >>>> Bug report: >>>> >>>> https://bugs.openjdk.java.net/browse/jdk-7174936 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/7174936/webrev.0/ >>>> >>>> Specdiff: >>>> >>>> >>>> http://cr.openjdk.java.net/~smarks/reviews/7174936/specdiff.0/overview-summary.html >>>> >>>> >>>> >>>> >>>> Thanks! >>>> >>>> s'marks From david.holmes at oracle.com Fri Nov 15 05:12:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Nov 2013 15:12:44 +1000 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <52858CD1.1050203@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> <52858CD1.1050203@oracle.com> Message-ID: <5285AD4C.1080302@oracle.com> Hi Kumar, I don't quite see how this gets the "jre" part of a JDK: ! JAVA_JRE_BIN = new File(JAVAHOME, "bin").getAbsolutePath(); ! ! File libDir = (isSDK) ! ? new File((new File(JAVAHOME)).getParentFile(), "lib") ! : new File(JAVAHOME, "lib"); ! JAVA_LIB = libDir.getAbsolutePath(); ! JAVA_JRE_LIB = new File(JAVAHOME, "lib").getAbsolutePath(); do you assume JAVAHOME points to the jre directory ?? BTW these tests being in tools/launcher are defined to require a JDK by definition, but jtreg should be passed a compilejdk when testing a JRE, and the test could also use that for the compiler if it needs one. Thanks, David On 15/11/2013 12:54 PM, Kumar Srinivasan wrote: > > Hi Mandy, > > Thanks for reviewing this, comments inlined. > >> Hi Kumar, >> >> On 11/14/2013 2:57 PM, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review fixes to the launcher tests, which allows for missing >>> server vm variant. >>> >>> All SE platforms have server vm, however Embedded SE systems do >>> not contain server, most of them have client, thus these >>> tests needed to be compensated for that. >>> >>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ >>> >> >> In ExecutionEnvironment.java, I understand the fix in line 251 and 257 >> that address the bug reported. However, I don't understand why doExec >> calls to launch javaCmd has to specify "-server" or "client". The >> jdk should have a default VM and should the test use that? > > I was being over-zealous, and trying not to rely on jvm.cfg, note that > jvm.cfg aliases -client to -server on 64-bit systems, I removed these > changes, as it does not add anything. > >> >> TestHelper.java >> >> 144 JAVA_JRE_LIB = new File((new >> File(JAVAHOME)).getParentFile(), >> 145 (isSDK) ? "jre/lib" : >> "lib").getAbsolutePath(); >> >> If JAVA_HOME is a JDK build (or JRE image), does this give you >> an incorrect path? I expect getParentFile() is not needed in that case. > > You are right this is an error, fixed. > >> This is copy-n-paste in many places. Does the test require >> to run on JDK image (not JDK build)? > > The test runs on both j2sdk-image and JDK build, I use both > during development with the old infra/jdk7. > > With the new infra I use only images, because it is much faster now > to create images, also on Solaris images are mandatory, because > solaris symlinks exists only in the the images and there is a test > which checks for these in ExecutionEnvironment.java. > Note: these tests cannot be run on j2re-image as jtreg and the test itself > needs the compiler, downside of converting to java tests. > >> >> 189 private static boolean haveVmVariant(String type) { >> 190 if (isWindows) { >> 191 File vmDir = new File(JAVA_JRE_BIN, type); >> 192 File jvmFile = new File(vmDir, JVM_DLL); >> >> >> jvm.dll should be under jre/bin/client or jre/bin/server as in other >> arch, right? > > Right windows no arch directory,output below. > % find . -name jvm.dll > ./j2re-image/bin/server/jvm.dll > ./j2sdk-image/jre/bin/server/jvm.dll > ./j2sdk-server-image/jre/bin/server/jvm.dll > > *nixes do have arch directory (i386, amd64, ppc, etc). > > A minor refactoring done. > > New full webrev: > http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html > > Delta webrev wrt. webrev.0 > http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html > > Kumar > >> >> Mandy > From erik.joelsson at oracle.com Fri Nov 15 09:09:31 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Nov 2013 10:09:31 +0100 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' In-Reply-To: References: Message-ID: <5285E4CB.4000001@oracle.com> Hello Volker, I like this solution, even if it could be viewed as a bit of overkill. /Erik On 2013-11-14 17:35, Volker Simonis wrote: > Hi, > > I wanted to solve "8026964: Building with an IBM J9 boot jdk requires > special settings for BOOT_RTJAR" > (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the > question what the real semantics of BOOT_RTJAR is? > > Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set > to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not > found). For an IBM J9 boot JDK however this is not so easy because > some essential classes (like Object or String) are not contained in > "rt.jar" (see the before mentioned bug for more details). So for IBM > J9 we need to add additional jar-files to BOOT_RTJAR. > > Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are > the required classes it should contain? Naively I would assume these > are the classes contained in the "sun.boot.class.path" system > property. But for an OpenJDK/Oracle based JDK, this property contains > much more classes than just rt.jar: > > sun.boot.class.path= \ > /jre/lib/resources.jar \ > /jre/lib/rt.jar \ > /jre/lib/sunrsasign.jar \ > /jre/lib/jsse.jar \ > /jre/lib/jce.jar \ > /jre/lib/charsets.jar \ > /jre/lib/jfr.jar \ > /jre/classes > > > The Oracle documentation I could find ("How Classes are Found" at > http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html) > states: "...Bootstrap classes are the classes that implement the Java > 2 Platform. Bootstrap classes are in the rt.jar and several other jar > files in the jre/lib directory. These archives are specified by the > value of the bootstrap class path which is stored in the > sun.boot.class.path system property..." > > So for me it seems that the current solution of using just "rt.jar" > works only accidentally until now and it would be more logical to set > BOOT_RTJAR to the value of "sun.boot.class.path". This value could be > queried during the configure process (e.g. by using the -XshowSettings > option). As far as I can see '-XshowSettings' and the > "sun.boot.class.path" property is supported on all the JDKs I know > (OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM). > > So my question is, if there are any objectives if I'd change the > current BOOT_RTJAR detection to the following lines: > > # Parse the settings of the 'sun.boot.class.path' property > # The tricky thing is that we must quote AWK field references (i.e. > $1, $2, ..) > # and the name 'index' which is a M4-buildin function by placing brackets > # (i.e. '[]') into the corresponding names. > BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \ > /path.separator/ { path_separator = $[]3} \ > /sun.boot.class.path/ { sun_boot_class_path = $[]3; \ > while (getline && !in[]dex($[]0,"=")) { \ > sun_boot_class_path = > sun_boot_class_path "\n" $[]1 \ > } \ > } \ > END { gsub("\n", path_separator, sun_boot_class_path); print > sun_boot_class_path }'` > > which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path' > (separated by the valid platform path separator which is also queried > from the output of '-XshowSettings'). > > I've tested this and it works on Linux and Solaris with an OppenJDK > based boot JDK and on AIX with the IBM J9 boot JDK. I think it would > be more robust for other JDKs as well. And of course it fixes my bug:) > > So if there are no general objections I'll be happy to prepare a > formal webrev for this issue. > > Regards, > Volker From Alan.Bateman at oracle.com Fri Nov 15 09:45:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Nov 2013 09:45:43 +0000 Subject: RFR: JDK-8028215 - ORB.init fails with SecurityException if properties select the JDK default ORB In-Reply-To: <528542A6.8020806@oracle.com> References: <528542A6.8020806@oracle.com> Message-ID: <5285ED47.3030505@oracle.com> On 14/11/2013 21:37, Mark Sheppard wrote: > Hi, > please oblige and review the following fix > > http://cr.openjdk.java.net/~msheppar/8028215/webrev/ > > which addresses the issue detailed in > > https://bugs.openjdk.java.net/browse/JDK-8028215 > > This addresses an ORB initialization problem, which has arisen when the > com.sun.corba.se.** packages were added to the restricted package list. Thanks for taking this one, I didn't think of this (I assume rare) usage when adding com.sun.corba.se.** to the restricted package list. The change makes the assumption that if the application asks for "com.sun.corba.se.impl.orb.ORBSingleton" then it really means the ORB implementation that is included with the JDK, I guess that should be okay. For the test then is the policy file needed? I would think the default policy file should be okay. I'm also curious why it is named java.policy.applet. One thing that the test could additionally check is that orb.getClass() is of the expected type. -Alan From volker.simonis at gmail.com Fri Nov 15 10:36:51 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Nov 2013 11:36:51 +0100 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' In-Reply-To: <52855D9F.4040300@oracle.com> References: <52855D9F.4040300@oracle.com> Message-ID: On Fri, Nov 15, 2013 at 12:32 AM, David Holmes wrote: > Hi Volker, > > > On 15/11/2013 2:35 AM, Volker Simonis wrote: >> >> Hi, >> >> I wanted to solve "8026964: Building with an IBM J9 boot jdk requires >> special settings for BOOT_RTJAR" >> (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the >> question what the real semantics of BOOT_RTJAR is? > > > For the combination of the OpenJDK libraries and VM it really just meant > rt.jar (not everything on the bootclasspath) as the build system "knows" > what is in there and that it is what was needed. OK, but what is the definition of 'rt.jar'. I doubt that is is something like "..the required classes needed to bootstrat the jdk..". I think that currently the build just works with the Oracle/OpenJDK bootstrap JDKS because it happens that 'rt.jar' contains most of the classes which have to be in the boot class path. But this is not the case for J9 (e.g. they have SAXParser and other xml stuff in an extra xml.jar). They have just distributed the classes over more .jar files which seems perfectly legal. > The other boot classpath > stuff is not relevant to the build processes that set the bootclasspath. > > I don't see an issue with generalizing it to the full boot classpath but is > it necessary? Can't you just define it to be rt.jar plus whatever jar(s) is > needed for J9? > This was my first approach (see the description of https://bugs.openjdk.java.net/browse/JDK-8026964) but I was not sure if I really got all the relevant jars. And this could actually change any time the build references more or other classes or any time the J9 changes their class partition (not to speak about other JDK which may choose yet another boot jar layouts). So just using sun.boot.class.path seemed to be the easiest, most general and most robust solution. > Cheers, > David > > >> Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set >> to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not >> found). For an IBM J9 boot JDK however this is not so easy because >> some essential classes (like Object or String) are not contained in >> "rt.jar" (see the before mentioned bug for more details). So for IBM >> J9 we need to add additional jar-files to BOOT_RTJAR. >> >> Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are >> the required classes it should contain? Naively I would assume these >> are the classes contained in the "sun.boot.class.path" system >> property. But for an OpenJDK/Oracle based JDK, this property contains >> much more classes than just rt.jar: >> >> sun.boot.class.path= \ >> /jre/lib/resources.jar \ >> /jre/lib/rt.jar \ >> /jre/lib/sunrsasign.jar \ >> /jre/lib/jsse.jar \ >> /jre/lib/jce.jar \ >> /jre/lib/charsets.jar \ >> /jre/lib/jfr.jar \ >> /jre/classes >> >> >> The Oracle documentation I could find ("How Classes are Found" at >> http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html) >> states: "...Bootstrap classes are the classes that implement the Java >> 2 Platform. Bootstrap classes are in the rt.jar and several other jar >> files in the jre/lib directory. These archives are specified by the >> value of the bootstrap class path which is stored in the >> sun.boot.class.path system property..." >> >> So for me it seems that the current solution of using just "rt.jar" >> works only accidentally until now and it would be more logical to set >> BOOT_RTJAR to the value of "sun.boot.class.path". This value could be >> queried during the configure process (e.g. by using the -XshowSettings >> option). As far as I can see '-XshowSettings' and the >> "sun.boot.class.path" property is supported on all the JDKs I know >> (OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM). >> >> So my question is, if there are any objectives if I'd change the >> current BOOT_RTJAR detection to the following lines: >> >> # Parse the settings of the 'sun.boot.class.path' property >> # The tricky thing is that we must quote AWK field references (i.e. >> $1, $2, ..) >> # and the name 'index' which is a M4-buildin function by placing >> brackets >> # (i.e. '[]') into the corresponding names. >> BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \ >> /path.separator/ { path_separator = $[]3} \ >> /sun.boot.class.path/ { sun_boot_class_path = $[]3; \ >> while (getline && !in[]dex($[]0,"=")) { \ >> sun_boot_class_path = >> sun_boot_class_path "\n" $[]1 \ >> } \ >> } \ >> END { gsub("\n", path_separator, sun_boot_class_path); print >> sun_boot_class_path }'` >> >> which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path' >> (separated by the valid platform path separator which is also queried >> from the output of '-XshowSettings'). >> >> I've tested this and it works on Linux and Solaris with an OppenJDK >> based boot JDK and on AIX with the IBM J9 boot JDK. I think it would >> be more robust for other JDKs as well. And of course it fixes my bug:) >> >> So if there are no general objections I'll be happy to prepare a >> formal webrev for this issue. >> >> Regards, >> Volker >> > From vicente.romero at oracle.com Fri Nov 15 11:09:04 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 15 Nov 2013 11:09:04 +0000 Subject: hg: jdk8/tl/langtools: 8026231: Look at 'static' flag when checking method references Message-ID: <20131115110918.2F41062617@hg.openjdk.java.net> Changeset: d4cbb671de1c Author: vromero Date: 2013-11-15 11:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d4cbb671de1c 8026231: Look at 'static' flag when checking method references Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference51.java ! test/tools/javac/lambda/MethodReference68.out + test/tools/javac/lambda/MethodReference73.java + test/tools/javac/lambda/MethodReference73.out ! test/tools/javac/lambda/TargetType60.java ! test/tools/javac/lambda/TargetType60.out From sean.coffey at oracle.com Fri Nov 15 12:12:54 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 15 Nov 2013 12:12:54 +0000 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <527D1464.3080508@oracle.com> References: <52791F14.2080305@oracle.com> <527D1464.3080508@oracle.com> Message-ID: <52860FC6.70105@oracle.com> Looks good to me too Aleksej. regards, Sean. On 08/11/2013 16:42, Xueming Shen wrote: > looks fine. I would assume you've also run the corresponding tests at > test/closed repo. > > -Sherman > > On 11/5/2013 8:38 AM, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for tzdata2013h integration [1]. The webrev link >> can be located here [2]. >> >> The following test sets were executed on build with fix: >> test/sun/util/calendar test/java/util/Calendar >> test/sun/util/resources/TimeZone test/sun/util/calendar >> test/java/util/TimeZone test/java/time test/java/util/Formatter >> >> And here is the list of failures: >> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >> FAILED: java/time/tck/java/time/TCKInstant.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >> FAILED: >> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >> FAILED: java/util/Calendar/JavatimeTest.java %1% >> >> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >> >> >> The group %1% tests failures relates to the JDK-8027622 bug and are >> expected (actually, it was already resolved in hotspot repo). >> The 'TestZoneInfo310' test failure is an actual error in current >> ZoneInfoFile class implementation in JDK. I have filled a bug for >> this one [3] and will send a separate review with fix later today. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8027370 >> [2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8027848 > From sean.coffey at oracle.com Fri Nov 15 12:13:19 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 15 Nov 2013 12:13:19 +0000 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <527A7A01.3010301@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> <52797D6F.3080209@oracle.com> <527A7A01.3010301@oracle.com> Message-ID: <52860FDF.4040002@oracle.com> Looks good here too Aleksej.. in case you need a second reviewer. regards, Sean. On 06/11/2013 17:18, Xueming Shen wrote: > Looks fine. > > thanks! > -Sherman > > On 11/05/2013 03:21 PM, Aleksej Efimov wrote: >> Sherman, >> Thank you for a quick review. I totally agree with you on all items. >> Actually, I missed fact that the transitions are sorted. And yes - >> the change can be done on line #431. >> The new tested fix can be found here: >> http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ >> >> >> -Aleksej >> >> On 11/05/2013 10:58 PM, Xueming Shen wrote: >>> On 11/05/2013 10:50 AM, Xueming Shen wrote: >>>> Aleksej, >>>> >>>> For better performance >>>> (1) the currT should be "static final" so we dont have to access the >>>> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >>>> (2) instead of iterating through the standardTransitions(), >>>> shouldn't we just >>>> check the last one? given it's a sorted list. >>> >>> and maybe this willGMTOffsetChange setting can be done just at >>> line#431. >>> >>> -Sherman >>> >>>> >>>> btw, in theory, the change now uses the "current vm starttime" >>>> instead of >>>> the "tzdb generated" time. But it should be fine, given >>>> ZoneInfo.getRawOffset() >>>> will just do a search for the current rawoffset. I may consider to >>>> add the >>>> "generated time" into the tzdb.dat in the future, if desired. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>>>> Hi, >>>>> Can I have a review for a 8027848 [1] bug fix . There is >>>>> unimplemented functionality related to the future GMT offset changes. >>>>> The ZoneInfoFile class doesn't analyses if there is such offset >>>>> changes and as a result incorrectly creates the ZoneInfo instance. >>>>> It was discovered during the TestZoneInfo310 test execution as >>>>> part of tzdata2013h update [3]. >>>>> >>>>> Thanks, >>>>> Aleksej >>>>> >>>>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>>>> [2] Proposed fix: >>>>> http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>>>> [3] tzdata2013h review thread: >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >>>> >>> >> > From Alan.Bateman at oracle.com Fri Nov 15 12:21:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Nov 2013 12:21:05 +0000 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <52855C4C.8050504@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> <5284DBA7.2050803@oracle.com> <52852088.9080100@oracle.com> <5285226F.8080707@oracle.com> <52855C4C.8050504@oracle.com> Message-ID: <528611B1.5040802@oracle.com> On 14/11/2013 23:27, Bill Shannon wrote: > : > I'd prefer that all variants of the API report the error in a way that allows > the users of the API to ignore the error, access the data that caused the error, > and supply replacement data if desired. > > For most of the APIs, decoding as much data as possible and throwing an > exception with details about how much has been decoded and where the error > was detected would be best. I understand that designing this and getting > it right might exceed what you can do in this release. In that case, just > throw an exception with no details, and we can figure out what details to > provide later. Returning a negative number is kind of a hack, and unlike > most other APIs. Plus, if we decide we need to return two numbers (e.g., > input and output positions), there's no way to extend it. This is where the methods that decode buffers are useful as the input and output buffer positions can be advanced to reflect the input that had been decoded successfully. So even when strict then it should be possible (although maybe ugly due to the exception) then you at least know where the corruption starts and you have the bytes that have been successfully decoded. As regards adding API support for ignore or replace then I think this will need to be something to consider for the future (it's just too late for JDK 8). -Alan. From joel.franck at oracle.com Fri Nov 15 12:26:36 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Fri, 15 Nov 2013 13:26:36 +0100 Subject: RFR: JDK-8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType Message-ID: <20131115122636.GB7721@oracle.com> Hi Please review this javadoc clarification for j.l.annnotation.Target and j.l.annotation.ElementType as part of the type annotations work. Webrev: http://cr.openjdk.java.net/~jfranck/8027413/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8027413 This is based on the update to JLS from Alex: http://cr.openjdk.java.net/~abuckley/308.pdf (section 1.6). cheers /Joel From andreas.lundblad at oracle.com Fri Nov 15 12:40:23 2013 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 15 Nov 2013 13:40:23 +0100 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52859342.7040709@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> Message-ID: <20131115124022.GA27709@e6430> On Thu, Nov 14, 2013 at 07:21:38PM -0800, Joseph Darcy wrote: > Hello, > > Catching up on email, the specification of java.lang.Class does not > explicitly promise that its notion of equality must be identity for > all time. Therefore, while not required for today's implementations, > I would prefer that new code we write in the JDK use equals rather > than == when comparing classes. Thank you for getting back on this matter. First of all, I agree with you that 'equals' is in a sense more future proof than plain '=='. Strictly speaking though, can't one say that todays docs implicitly specify that j.l.Class.equals *must* be identity-based (since it does not explicitly refine the spec of Object.equals)? If so, wouldn't it be a breaking change to add a j.l.Class.equals which refines this by specifying something else? (Side note, At the moment I neighter consider this review as accepted nor rejected, and assume that the patch won't make it into 8 regardless.) -- Andreas From scolebourne at joda.org Fri Nov 15 12:56:17 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 15 Nov 2013 12:56:17 +0000 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52859342.7040709@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> Message-ID: On 15 November 2013 03:21, Joseph Darcy wrote: > Catching up on email, the specification of java.lang.Class does not > explicitly promise that its notion of equality must be identity for all > time. Therefore, while not required for today's implementations, I would > prefer that new code we write in the JDK use equals rather than == when > comparing classes. I've used == for Class for many years. I expect many other developers have done the same. I think that changing Class so identity was not respected would break a *lot* of code. Stephen From vitalyd at gmail.com Fri Nov 15 13:11:31 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 15 Nov 2013 08:11:31 -0500 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> Message-ID: +1 The amount of code in the wild that would break (if this were to change) virtually guarantees that such a change won't happen, regardless of what current spec does or does not say. It would probably be easier to just update the spec at this point to match implementation. Vitaly Sent from my phone On Nov 15, 2013 7:57 AM, "Stephen Colebourne" wrote: > On 15 November 2013 03:21, Joseph Darcy wrote: > > Catching up on email, the specification of java.lang.Class does not > > explicitly promise that its notion of equality must be identity for all > > time. Therefore, while not required for today's implementations, I would > > prefer that new code we write in the JDK use equals rather than == when > > comparing classes. > > I've used == for Class for many years. I expect many other developers > have done the same. I think that changing Class so identity was not > respected would break a *lot* of code. > > Stephen > From Alan.Bateman at oracle.com Fri Nov 15 14:36:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Nov 2013 14:36:24 +0000 Subject: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8 In-Reply-To: <528539CF.1010200@oracle.com> References: <528539CF.1010200@oracle.com> Message-ID: <52863168.2020408@oracle.com> On 14/11/2013 20:59, Xueming Shen wrote: > : > > Here is the webrev for the undo (keep the mime encoder(...) rename > change) > > http://cr.openjdk.java.net/~sherman/8028397/webrev I think is okay except for the restoring of the buffer position when an error occurs. If we try to keep consistent with CharsetDecoder then they should be advanced for this case. Also this is consistent with the side effect that bytes may have been written to the output buffer. -Alan. From david.holmes at oracle.com Fri Nov 15 16:34:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Nov 2013 02:34:19 +1000 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> Message-ID: <52864D0B.4010100@oracle.com> On 15/11/2013 11:11 PM, Vitaly Davidovich wrote: > +1 > > The amount of code in the wild that would break (if this were to change) > virtually guarantees that such a change won't happen, regardless of what > current spec does or does not say. It would probably be easier to just > update the spec at this point to match implementation. There is no need to update spec or implementation. Current code aligns exactly with spec and spec is perfectly valid. The change to use equals() over == was being proposed to future-proof the code in case the implicit specification of Class.equals were to change in the future. Harmless but pointless in my opinion. David ----- > Vitaly > > Sent from my phone > On Nov 15, 2013 7:57 AM, "Stephen Colebourne" wrote: > >> On 15 November 2013 03:21, Joseph Darcy wrote: >>> Catching up on email, the specification of java.lang.Class does not >>> explicitly promise that its notion of equality must be identity for all >>> time. Therefore, while not required for today's implementations, I would >>> prefer that new code we write in the JDK use equals rather than == when >>> comparing classes. >> >> I've used == for Class for many years. I expect many other developers >> have done the same. I think that changing Class so identity was not >> respected would break a *lot* of code. >> >> Stephen >> From volker.simonis at gmail.com Fri Nov 15 16:34:47 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Nov 2013 17:34:47 +0100 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' In-Reply-To: <5285E4CB.4000001@oracle.com> References: <5285E4CB.4000001@oracle.com> Message-ID: Hi Erik, On Fri, Nov 15, 2013 at 10:09 AM, Erik Joelsson wrote: > Hello Volker, > > I like this solution, even if it could be viewed as a bit of overkill. > thanks:) I've just posted a RFR to the build-dev list: http://mail.openjdk.java.net/pipermail/build-dev/2013-November/011108.html with two small enhancements: - remove non-existing path elements from the 'sun.boot.class.path' path list (e.g. jre/classes, jfr.jar, ..) - convert the path list to Unix form (with cygpath) on Windows to avoid problems with FIXPATH later on. Hope you like it:) Volker > /Erik > > > On 2013-11-14 17:35, Volker Simonis wrote: >> >> Hi, >> >> I wanted to solve "8026964: Building with an IBM J9 boot jdk requires >> special settings for BOOT_RTJAR" >> (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the >> question what the real semantics of BOOT_RTJAR is? >> >> Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set >> to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not >> found). For an IBM J9 boot JDK however this is not so easy because >> some essential classes (like Object or String) are not contained in >> "rt.jar" (see the before mentioned bug for more details). So for IBM >> J9 we need to add additional jar-files to BOOT_RTJAR. >> >> Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are >> the required classes it should contain? Naively I would assume these >> are the classes contained in the "sun.boot.class.path" system >> property. But for an OpenJDK/Oracle based JDK, this property contains >> much more classes than just rt.jar: >> >> sun.boot.class.path= \ >> /jre/lib/resources.jar \ >> /jre/lib/rt.jar \ >> /jre/lib/sunrsasign.jar \ >> /jre/lib/jsse.jar \ >> /jre/lib/jce.jar \ >> /jre/lib/charsets.jar \ >> /jre/lib/jfr.jar \ >> /jre/classes >> >> >> The Oracle documentation I could find ("How Classes are Found" at >> http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html) >> states: "...Bootstrap classes are the classes that implement the Java >> 2 Platform. Bootstrap classes are in the rt.jar and several other jar >> files in the jre/lib directory. These archives are specified by the >> value of the bootstrap class path which is stored in the >> sun.boot.class.path system property..." >> >> So for me it seems that the current solution of using just "rt.jar" >> works only accidentally until now and it would be more logical to set >> BOOT_RTJAR to the value of "sun.boot.class.path". This value could be >> queried during the configure process (e.g. by using the -XshowSettings >> option). As far as I can see '-XshowSettings' and the >> "sun.boot.class.path" property is supported on all the JDKs I know >> (OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM). >> >> So my question is, if there are any objectives if I'd change the >> current BOOT_RTJAR detection to the following lines: >> >> # Parse the settings of the 'sun.boot.class.path' property >> # The tricky thing is that we must quote AWK field references (i.e. >> $1, $2, ..) >> # and the name 'index' which is a M4-buildin function by placing >> brackets >> # (i.e. '[]') into the corresponding names. >> BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \ >> /path.separator/ { path_separator = $[]3} \ >> /sun.boot.class.path/ { sun_boot_class_path = $[]3; \ >> while (getline && !in[]dex($[]0,"=")) { \ >> sun_boot_class_path = >> sun_boot_class_path "\n" $[]1 \ >> } \ >> } \ >> END { gsub("\n", path_separator, sun_boot_class_path); print >> sun_boot_class_path }'` >> >> which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path' >> (separated by the valid platform path separator which is also queried >> from the output of '-XshowSettings'). >> >> I've tested this and it works on Linux and Solaris with an OppenJDK >> based boot JDK and on AIX with the IBM J9 boot JDK. I think it would >> be more robust for other JDKs as well. And of course it fixes my bug:) >> >> So if there are no general objections I'll be happy to prepare a >> formal webrev for this issue. >> >> Regards, >> Volker > > From Alan.Bateman at oracle.com Fri Nov 15 16:36:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Nov 2013 16:36:15 +0000 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <5285631E.6060801@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> <52842184.4030606@oracle.com> <5285631E.6060801@oracle.com> Message-ID: <52864D7F.3040104@oracle.com> On 14/11/2013 23:56, Stuart Marks wrote: > > > On 11/14/13 2:04 AM, David Holmes wrote: >> Sorry for the delay (been enroute). Only issue I have remains the >> subSequence >> change - you can't weaken the post-condition of >> CharSequence.subSequence without >> breaking subtype substitutability. > > Hi David, > > Yes, in general, what you say about weakening post-conditions is true. > In this case, though, I can't see how it can cause any practical harm. I've looked through the webrev and read the exchange between you and David. I think it might be better to leave the subSequence change out for now (the @apiNote is fine) and submit another bug to track the discrepancy between the spec and implementation. From what I can tell, this has existed since CharSequence was added in 1.4, in which case there may be a good argument to just document the potential deviation. -Alan From kumar.x.srinivasan at oracle.com Fri Nov 15 16:37:59 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 15 Nov 2013 08:37:59 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <5285AD4C.1080302@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> <52858CD1.1050203@oracle.com> <5285AD4C.1080302@oracle.com> Message-ID: <52864DE7.4020909@oracle.com> Hi David, > Hi Kumar, > > I don't quite see how this gets the "jre" part of a JDK: > > ! JAVA_JRE_BIN = new File(JAVAHOME, "bin").getAbsolutePath(); > ! > ! File libDir = (isSDK) > ! ? new File((new File(JAVAHOME)).getParentFile(), "lib") > ! : new File(JAVAHOME, "lib"); > ! JAVA_LIB = libDir.getAbsolutePath(); > ! JAVA_JRE_LIB = new File(JAVAHOME, "lib").getAbsolutePath(); > > do you assume JAVAHOME points to the jre directory ?? JAVAHOME = System.getProperty("java.home"); so in the case of the jdk that is exactly what happens, see output below. % ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -XshowSettings:props -version 2>&1 | grep java.home java.home = /X-OUT/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre % ./build/linux-x86_64-normal-server-release/jdk/bin/java -XshowSettings:props -version 2>&1 | grep java.home java.home = /X-OUT/build/linux-x86_64-normal-server-release/jdk % ./build/linux-x86_64-normal-server-release/images/j2re-image/bin/java -XshowSettings:props -version 2>&1 | grep java.home java.home = /X-OUT/build/linux-x86_64-normal-server-release/images/j2re-image > > BTW these tests being in tools/launcher are defined to require a JDK > by definition, but jtreg should be passed a compilejdk when testing a > JRE, and the test could also use that for the compiler if it needs one. thanks for pointing that out, I had forgotten all about compilejdk. Kumar > > Thanks, > David > > On 15/11/2013 12:54 PM, Kumar Srinivasan wrote: >> >> Hi Mandy, >> >> Thanks for reviewing this, comments inlined. >> >>> Hi Kumar, >>> >>> On 11/14/2013 2:57 PM, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> Please review fixes to the launcher tests, which allows for missing >>>> server vm variant. >>>> >>>> All SE platforms have server vm, however Embedded SE systems do >>>> not contain server, most of them have client, thus these >>>> tests needed to be compensated for that. >>>> >>>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ >>>> >>> >>> In ExecutionEnvironment.java, I understand the fix in line 251 and 257 >>> that address the bug reported. However, I don't understand why doExec >>> calls to launch javaCmd has to specify "-server" or "client". The >>> jdk should have a default VM and should the test use that? >> >> I was being over-zealous, and trying not to rely on jvm.cfg, note that >> jvm.cfg aliases -client to -server on 64-bit systems, I removed these >> changes, as it does not add anything. >> >>> >>> TestHelper.java >>> >>> 144 JAVA_JRE_LIB = new File((new >>> File(JAVAHOME)).getParentFile(), >>> 145 (isSDK) ? "jre/lib" : >>> "lib").getAbsolutePath(); >>> >>> If JAVA_HOME is a JDK build (or JRE image), does this give you >>> an incorrect path? I expect getParentFile() is not needed in that >>> case. >> >> You are right this is an error, fixed. >> >>> This is copy-n-paste in many places. Does the test require >>> to run on JDK image (not JDK build)? >> >> The test runs on both j2sdk-image and JDK build, I use both >> during development with the old infra/jdk7. >> >> With the new infra I use only images, because it is much faster now >> to create images, also on Solaris images are mandatory, because >> solaris symlinks exists only in the the images and there is a test >> which checks for these in ExecutionEnvironment.java. >> Note: these tests cannot be run on j2re-image as jtreg and the test >> itself >> needs the compiler, downside of converting to java tests. >> >>> >>> 189 private static boolean haveVmVariant(String type) { >>> 190 if (isWindows) { >>> 191 File vmDir = new File(JAVA_JRE_BIN, type); >>> 192 File jvmFile = new File(vmDir, JVM_DLL); >>> >>> >>> jvm.dll should be under jre/bin/client or jre/bin/server as in other >>> arch, right? >> >> Right windows no arch directory,output below. >> % find . -name jvm.dll >> ./j2re-image/bin/server/jvm.dll >> ./j2sdk-image/jre/bin/server/jvm.dll >> ./j2sdk-server-image/jre/bin/server/jvm.dll >> >> *nixes do have arch directory (i386, amd64, ppc, etc). >> >> A minor refactoring done. >> >> New full webrev: >> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html >> >> Delta webrev wrt. webrev.0 >> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html >> >> >> Kumar >> >>> >>> Mandy >> From david.holmes at oracle.com Fri Nov 15 16:39:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Nov 2013 02:39:32 +1000 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' In-Reply-To: References: <52855D9F.4040300@oracle.com> Message-ID: <52864E44.8050704@oracle.com> On 15/11/2013 8:36 PM, Volker Simonis wrote: > On Fri, Nov 15, 2013 at 12:32 AM, David Holmes wrote: >> Hi Volker, >> >> >> On 15/11/2013 2:35 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> I wanted to solve "8026964: Building with an IBM J9 boot jdk requires >>> special settings for BOOT_RTJAR" >>> (https://bugs.openjdk.java.net/browse/JDK-8026964) and came across the >>> question what the real semantics of BOOT_RTJAR is? >> >> >> For the combination of the OpenJDK libraries and VM it really just meant >> rt.jar (not everything on the bootclasspath) as the build system "knows" >> what is in there and that it is what was needed. > > OK, but what is the definition of 'rt.jar'. I doubt that is is > something like "..the required classes needed to bootstrat the jdk..". No it is the set of required classes to run a Java application on the (Open)JDK that doesn't use any of the "optional" Java API's that exist in other jar files. Cheers, David > I think that currently the build just works with the Oracle/OpenJDK > bootstrap JDKS because it happens that 'rt.jar' contains most of the > classes which have to be in the boot class path. But this is not the > case for J9 (e.g. they have SAXParser and other xml stuff in an extra > xml.jar). They have just distributed the classes over more .jar files > which seems perfectly legal. > >> The other boot classpath >> stuff is not relevant to the build processes that set the bootclasspath. >> >> I don't see an issue with generalizing it to the full boot classpath but is >> it necessary? Can't you just define it to be rt.jar plus whatever jar(s) is >> needed for J9? >> > > This was my first approach (see the description of > https://bugs.openjdk.java.net/browse/JDK-8026964) but I was not sure > if I really got all the relevant jars. And this could actually change > any time the build references more or other classes or any time the J9 > changes their class partition (not to speak about other JDK which may > choose yet another boot jar layouts). > > So just using sun.boot.class.path seemed to be the easiest, most > general and most robust solution. > >> Cheers, >> David >> >> >>> Currently, for OpenJDK/Oracle based boot JDKs BOOT_RTJAR is simply set >>> to "rt.jar" (and for MacOSX to "classes.jar" if "rt.jar" is not >>> found). For an IBM J9 boot JDK however this is not so easy because >>> some essential classes (like Object or String) are not contained in >>> "rt.jar" (see the before mentioned bug for more details). So for IBM >>> J9 we need to add additional jar-files to BOOT_RTJAR. >>> >>> Now I wonder what's the exact semantics of BOOT_RTJAR i.e. which are >>> the required classes it should contain? Naively I would assume these >>> are the classes contained in the "sun.boot.class.path" system >>> property. But for an OpenJDK/Oracle based JDK, this property contains >>> much more classes than just rt.jar: >>> >>> sun.boot.class.path= \ >>> /jre/lib/resources.jar \ >>> /jre/lib/rt.jar \ >>> /jre/lib/sunrsasign.jar \ >>> /jre/lib/jsse.jar \ >>> /jre/lib/jce.jar \ >>> /jre/lib/charsets.jar \ >>> /jre/lib/jfr.jar \ >>> /jre/classes >>> >>> >>> The Oracle documentation I could find ("How Classes are Found" at >>> http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html) >>> states: "...Bootstrap classes are the classes that implement the Java >>> 2 Platform. Bootstrap classes are in the rt.jar and several other jar >>> files in the jre/lib directory. These archives are specified by the >>> value of the bootstrap class path which is stored in the >>> sun.boot.class.path system property..." >>> >>> So for me it seems that the current solution of using just "rt.jar" >>> works only accidentally until now and it would be more logical to set >>> BOOT_RTJAR to the value of "sun.boot.class.path". This value could be >>> queried during the configure process (e.g. by using the -XshowSettings >>> option). As far as I can see '-XshowSettings' and the >>> "sun.boot.class.path" property is supported on all the JDKs I know >>> (OpenJDK, Oracle JDK, SAP JVM, IBM J9, HP JVM). >>> >>> So my question is, if there are any objectives if I'd change the >>> current BOOT_RTJAR detection to the following lines: >>> >>> # Parse the settings of the 'sun.boot.class.path' property >>> # The tricky thing is that we must quote AWK field references (i.e. >>> $1, $2, ..) >>> # and the name 'index' which is a M4-buildin function by placing >>> brackets >>> # (i.e. '[]') into the corresponding names. >>> BOOT_RTJAR=`$BOOT_JDK/bin/java -XshowSettings 2>&1 | $NAWK ' \ >>> /path.separator/ { path_separator = $[]3} \ >>> /sun.boot.class.path/ { sun_boot_class_path = $[]3; \ >>> while (getline && !in[]dex($[]0,"=")) { \ >>> sun_boot_class_path = >>> sun_boot_class_path "\n" $[]1 \ >>> } \ >>> } \ >>> END { gsub("\n", path_separator, sun_boot_class_path); print >>> sun_boot_class_path }'` >>> >>> which effectively set BOOT_RTJAR to the value of 'sun.boot.class.path' >>> (separated by the valid platform path separator which is also queried >>> from the output of '-XshowSettings'). >>> >>> I've tested this and it works on Linux and Solaris with an OppenJDK >>> based boot JDK and on AIX with the IBM J9 boot JDK. I think it would >>> be more robust for other JDKs as well. And of course it fixes my bug:) >>> >>> So if there are no general objections I'll be happy to prepare a >>> formal webrev for this issue. >>> >>> Regards, >>> Volker >>> >> From kumar.x.srinivasan at oracle.com Fri Nov 15 16:42:47 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 15 Nov 2013 08:42:47 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <528590CB.6040301@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> <52858CD1.1050203@oracle.com> <528590CB.6040301@oracle.com> Message-ID: <52864F07.9030101@oracle.com> On 11/14/2013 7:11 PM, Mandy Chung wrote: > > On 11/14/2013 6:54 PM, Kumar Srinivasan wrote: >> New full webrev: >> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html >> >> Delta webrev wrt. webrev.0 >> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html >> >> > > This looks much better. Nit: JAVA_LIB could be interpreted as > jdk/lib which contains tools.jar etc which is the case when you run > the test with jdk image. If you run the test with JDK build, jdk/lib > doesn't contain tools.jar (but its classes are in the bootclasspath). > JAVA_LIB is not currently used. While there is no issue with it, > perhaps better to take it out and define it when there is a concrete > use of it. It's really minor and will leave it up to you. Right, noted if there are other changes I will address it with those. Thanks for the review. Kumar > > Mandy From david.holmes at oracle.com Fri Nov 15 17:07:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Nov 2013 03:07:09 +1000 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <52864DE7.4020909@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> <52858CD1.1050203@oracle.com> <5285AD4C.1080302@oracle.com> <52864DE7.4020909@oracle.com> Message-ID: <528654BD.7060501@oracle.com> On 16/11/2013 2:37 AM, Kumar Srinivasan wrote: > > Hi David, > >> Hi Kumar, >> >> I don't quite see how this gets the "jre" part of a JDK: >> >> ! JAVA_JRE_BIN = new File(JAVAHOME, "bin").getAbsolutePath(); >> ! >> ! File libDir = (isSDK) >> ! ? new File((new File(JAVAHOME)).getParentFile(), "lib") >> ! : new File(JAVAHOME, "lib"); >> ! JAVA_LIB = libDir.getAbsolutePath(); >> ! JAVA_JRE_LIB = new File(JAVAHOME, "lib").getAbsolutePath(); >> >> do you assume JAVAHOME points to the jre directory ?? > > JAVAHOME = System.getProperty("java.home"); > > so in the case of the jdk that is exactly what happens, see output below. > > % ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java > -XshowSettings:props -version 2>&1 | grep java.home > java.home = > /X-OUT/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre > > % ./build/linux-x86_64-normal-server-release/jdk/bin/java > -XshowSettings:props -version 2>&1 | grep java.home > java.home = /X-OUT/build/linux-x86_64-normal-server-release/jdk > > % ./build/linux-x86_64-normal-server-release/images/j2re-image/bin/java > -XshowSettings:props -version 2>&1 | grep java.home > java.home = > /X-OUT/build/linux-x86_64-normal-server-release/images/j2re-image Thanks for clarifying that. I was confused by the fact that when I have to set JAVA_HOME it points to the the directory that contains the bin directory (which may be top-level or jre). David ----- >> >> BTW these tests being in tools/launcher are defined to require a JDK >> by definition, but jtreg should be passed a compilejdk when testing a >> JRE, and the test could also use that for the compiler if it needs one. > > thanks for pointing that out, I had forgotten all about compilejdk. > > Kumar > >> >> Thanks, >> David >> >> On 15/11/2013 12:54 PM, Kumar Srinivasan wrote: >>> >>> Hi Mandy, >>> >>> Thanks for reviewing this, comments inlined. >>> >>>> Hi Kumar, >>>> >>>> On 11/14/2013 2:57 PM, Kumar Srinivasan wrote: >>>>> Hello, >>>>> >>>>> Please review fixes to the launcher tests, which allows for missing >>>>> server vm variant. >>>>> >>>>> All SE platforms have server vm, however Embedded SE systems do >>>>> not contain server, most of them have client, thus these >>>>> tests needed to be compensated for that. >>>>> >>>>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ >>>>> >>>> >>>> In ExecutionEnvironment.java, I understand the fix in line 251 and 257 >>>> that address the bug reported. However, I don't understand why doExec >>>> calls to launch javaCmd has to specify "-server" or "client". The >>>> jdk should have a default VM and should the test use that? >>> >>> I was being over-zealous, and trying not to rely on jvm.cfg, note that >>> jvm.cfg aliases -client to -server on 64-bit systems, I removed these >>> changes, as it does not add anything. >>> >>>> >>>> TestHelper.java >>>> >>>> 144 JAVA_JRE_LIB = new File((new >>>> File(JAVAHOME)).getParentFile(), >>>> 145 (isSDK) ? "jre/lib" : >>>> "lib").getAbsolutePath(); >>>> >>>> If JAVA_HOME is a JDK build (or JRE image), does this give you >>>> an incorrect path? I expect getParentFile() is not needed in that >>>> case. >>> >>> You are right this is an error, fixed. >>> >>>> This is copy-n-paste in many places. Does the test require >>>> to run on JDK image (not JDK build)? >>> >>> The test runs on both j2sdk-image and JDK build, I use both >>> during development with the old infra/jdk7. >>> >>> With the new infra I use only images, because it is much faster now >>> to create images, also on Solaris images are mandatory, because >>> solaris symlinks exists only in the the images and there is a test >>> which checks for these in ExecutionEnvironment.java. >>> Note: these tests cannot be run on j2re-image as jtreg and the test >>> itself >>> needs the compiler, downside of converting to java tests. >>> >>>> >>>> 189 private static boolean haveVmVariant(String type) { >>>> 190 if (isWindows) { >>>> 191 File vmDir = new File(JAVA_JRE_BIN, type); >>>> 192 File jvmFile = new File(vmDir, JVM_DLL); >>>> >>>> >>>> jvm.dll should be under jre/bin/client or jre/bin/server as in other >>>> arch, right? >>> >>> Right windows no arch directory,output below. >>> % find . -name jvm.dll >>> ./j2re-image/bin/server/jvm.dll >>> ./j2sdk-image/jre/bin/server/jvm.dll >>> ./j2sdk-server-image/jre/bin/server/jvm.dll >>> >>> *nixes do have arch directory (i386, amd64, ppc, etc). >>> >>> A minor refactoring done. >>> >>> New full webrev: >>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html >>> >>> Delta webrev wrt. webrev.0 >>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html >>> >>> >>> Kumar >>> >>>> >>>> Mandy >>> > From xueming.shen at oracle.com Fri Nov 15 17:12:31 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 15 Nov 2013 09:12:31 -0800 Subject: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8 In-Reply-To: <52863168.2020408@oracle.com> References: <528539CF.1010200@oracle.com> <52863168.2020408@oracle.com> Message-ID: <528655FF.9030508@oracle.com> On 11/15/13 6:36 AM, Alan Bateman wrote: > On 14/11/2013 20:59, Xueming Shen wrote: >> : >> >> Here is the webrev for the undo (keep the mime encoder(...) rename >> change) >> >> http://cr.openjdk.java.net/~sherman/8028397/webrev > I think is okay except for the restoring of the buffer position when > an error occurs. If we try to keep consistent with CharsetDecoder then > they should be advanced for this case. Also this is consistent with > the side effect that bytes may have been written to the output buffer. > > -Alan. I'm happy to put the "IAE with advanced positions" change back, the webrev has been updated according. http://cr.openjdk.java.net/~sherman/8028397/webrev/ Thanks! -Sherman From bill.shannon at oracle.com Fri Nov 15 18:17:43 2013 From: bill.shannon at oracle.com (Bill Shannon) Date: Fri, 15 Nov 2013 10:17:43 -0800 Subject: RFR 8025003: Base64 should be less strict with padding In-Reply-To: <528611B1.5040802@oracle.com> References: <526850D3.20509@oracle.com> <526AE077.9020608@oracle.com> <526AEE75.5040307@oracle.com> <526AEF87.4000804@oracle.com> <527D6717.6090702@oracle.com> <5282AE17.3000508@oracle.com> <5282BAA1.9090004@oracle.com> <5282C6DF.9040201@oracle.com> <5282FE48.8010204@oracle.com> <5283ADF6.8060104@oracle.com> <5283C7D5.2000401@oracle.com> <5283CEF4.6060406@oracle.com> <5283D50A.6080407@oracle.com> <5283E0EE.1000405@oracle.com> <5284DBA7.2050803@oracle.com> <52852088.9080100@oracle.com> <5285226F.8080707@oracle.com> <52855C4C.8050504@oracle.com> <528611B1.5040802@oracle.com> Message-ID: <52866547.8050801@oracle.com> Alan Bateman wrote on 11/15/13 04:21: > On 14/11/2013 23:27, Bill Shannon wrote: >> : >> I'd prefer that all variants of the API report the error in a way that allows >> the users of the API to ignore the error, access the data that caused the error, >> and supply replacement data if desired. >> >> For most of the APIs, decoding as much data as possible and throwing an >> exception with details about how much has been decoded and where the error >> was detected would be best. I understand that designing this and getting >> it right might exceed what you can do in this release. In that case, just >> throw an exception with no details, and we can figure out what details to >> provide later. Returning a negative number is kind of a hack, and unlike >> most other APIs. Plus, if we decide we need to return two numbers (e.g., >> input and output positions), there's no way to extend it. > This is where the methods that decode buffers are useful as the input and output > buffer positions can be advanced to reflect the input that had been decoded > successfully. So even when strict then it should be possible (although maybe > ugly due to the exception) then you at least know where the corruption starts > and you have the bytes that have been successfully decoded. And hopefully the same for the stream-based version. > As regards adding API support for ignore or replace then I think this will need > to be something to consider for the future (it's just too late for JDK 8). Right, as long as I can wrap the strict API to provide this effect, that's good enough for now. From kumar.x.srinivasan at oracle.com Fri Nov 15 19:24:05 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 15 Nov 2013 11:24:05 -0800 Subject: RFR: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm In-Reply-To: <528654BD.7060501@oracle.com> References: <52855574.80703@oracle.com> <52855D4E.8040300@oracle.com> <52858CD1.1050203@oracle.com> <5285AD4C.1080302@oracle.com> <52864DE7.4020909@oracle.com> <528654BD.7060501@oracle.com> Message-ID: <528674D5.5040302@oracle.com> On 11/15/2013 9:07 AM, David Holmes wrote: > On 16/11/2013 2:37 AM, Kumar Srinivasan wrote: >> >> Hi David, >> >>> Hi Kumar, >>> >>> I don't quite see how this gets the "jre" part of a JDK: >>> >>> ! JAVA_JRE_BIN = new File(JAVAHOME, "bin").getAbsolutePath(); >>> ! >>> ! File libDir = (isSDK) >>> ! ? new File((new File(JAVAHOME)).getParentFile(), >>> "lib") >>> ! : new File(JAVAHOME, "lib"); >>> ! JAVA_LIB = libDir.getAbsolutePath(); >>> ! JAVA_JRE_LIB = new File(JAVAHOME, "lib").getAbsolutePath(); >>> >>> do you assume JAVAHOME points to the jre directory ?? >> >> JAVAHOME = System.getProperty("java.home"); >> >> so in the case of the jdk that is exactly what happens, see output >> below. >> >> % ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java >> -XshowSettings:props -version 2>&1 | grep java.home >> java.home = >> /X-OUT/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre >> >> % ./build/linux-x86_64-normal-server-release/jdk/bin/java >> -XshowSettings:props -version 2>&1 | grep java.home >> java.home = /X-OUT/build/linux-x86_64-normal-server-release/jdk >> >> % ./build/linux-x86_64-normal-server-release/images/j2re-image/bin/java >> -XshowSettings:props -version 2>&1 | grep java.home >> java.home = >> /X-OUT/build/linux-x86_64-normal-server-release/images/j2re-image > > Thanks for clarifying that. I was confused by the fact that when I > have to set JAVA_HOME it points to the the directory that contains the > bin directory (which may be top-level or jre). I think that was the reason I named that var JAVAHOME vs. JAVA_HOME when I initially created TestHelper.java, I think it ought to be JRE_HOME, oh well that is for another rainy day. Kumar > > David > ----- > >>> >>> BTW these tests being in tools/launcher are defined to require a JDK >>> by definition, but jtreg should be passed a compilejdk when testing a >>> JRE, and the test could also use that for the compiler if it needs one. >> >> thanks for pointing that out, I had forgotten all about compilejdk. >> >> Kumar >> >>> >>> Thanks, >>> David >>> >>> On 15/11/2013 12:54 PM, Kumar Srinivasan wrote: >>>> >>>> Hi Mandy, >>>> >>>> Thanks for reviewing this, comments inlined. >>>> >>>>> Hi Kumar, >>>>> >>>>> On 11/14/2013 2:57 PM, Kumar Srinivasan wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fixes to the launcher tests, which allows for missing >>>>>> server vm variant. >>>>>> >>>>>> All SE platforms have server vm, however Embedded SE systems do >>>>>> not contain server, most of them have client, thus these >>>>>> tests needed to be compensated for that. >>>>>> >>>>>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.0/ >>>>>> >>>>> >>>>> In ExecutionEnvironment.java, I understand the fix in line 251 and >>>>> 257 >>>>> that address the bug reported. However, I don't understand why >>>>> doExec >>>>> calls to launch javaCmd has to specify "-server" or "client". The >>>>> jdk should have a default VM and should the test use that? >>>> >>>> I was being over-zealous, and trying not to rely on jvm.cfg, note that >>>> jvm.cfg aliases -client to -server on 64-bit systems, I removed these >>>> changes, as it does not add anything. >>>> >>>>> >>>>> TestHelper.java >>>>> >>>>> 144 JAVA_JRE_LIB = new File((new >>>>> File(JAVAHOME)).getParentFile(), >>>>> 145 (isSDK) ? "jre/lib" : >>>>> "lib").getAbsolutePath(); >>>>> >>>>> If JAVA_HOME is a JDK build (or JRE image), does this give you >>>>> an incorrect path? I expect getParentFile() is not needed in that >>>>> case. >>>> >>>> You are right this is an error, fixed. >>>> >>>>> This is copy-n-paste in many places. Does the test require >>>>> to run on JDK image (not JDK build)? >>>> >>>> The test runs on both j2sdk-image and JDK build, I use both >>>> during development with the old infra/jdk7. >>>> >>>> With the new infra I use only images, because it is much faster now >>>> to create images, also on Solaris images are mandatory, because >>>> solaris symlinks exists only in the the images and there is a test >>>> which checks for these in ExecutionEnvironment.java. >>>> Note: these tests cannot be run on j2re-image as jtreg and the test >>>> itself >>>> needs the compiler, downside of converting to java tests. >>>> >>>>> >>>>> 189 private static boolean haveVmVariant(String type) { >>>>> 190 if (isWindows) { >>>>> 191 File vmDir = new File(JAVA_JRE_BIN, type); >>>>> 192 File jvmFile = new File(vmDir, JVM_DLL); >>>>> >>>>> >>>>> jvm.dll should be under jre/bin/client or jre/bin/server as in other >>>>> arch, right? >>>> >>>> Right windows no arch directory,output below. >>>> % find . -name jvm.dll >>>> ./j2re-image/bin/server/jvm.dll >>>> ./j2sdk-image/jre/bin/server/jvm.dll >>>> ./j2sdk-server-image/jre/bin/server/jvm.dll >>>> >>>> *nixes do have arch directory (i386, amd64, ppc, etc). >>>> >>>> A minor refactoring done. >>>> >>>> New full webrev: >>>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/index.html >>>> >>>> Delta webrev wrt. webrev.0 >>>> http://cr.openjdk.java.net/~ksrini/8023978/webrev.1/webrev.delta/index.html >>>> >>>> >>>> >>>> Kumar >>>> >>>>> >>>>> Mandy >>>> >> From ioi.lam at oracle.com Fri Nov 15 20:37:24 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 15 Nov 2013 12:37:24 -0800 Subject: lib/ext JAR file search order Message-ID: <52868604.4040104@oracle.com> From sun.misc.Launcher$ExtClassLoader: private static URL[] getExtURLs(File[] dirs) throws IOException { Vector urls = new Vector(); for (int i = 0; i < dirs.length; i++) { String[] files = dirs[i].list(); if (files != null) { for (int j = 0; j < files.length; j++) { if (!files[j].equals("meta-index")) { File f = new File(dirs[i], files[j]); urls.add(getFileURL(f)); } } } } URL[] ua = new URL[urls.size()]; urls.copyInto(ua); return ua; } the search order is completely depending on the order of files returned by File.list(), whose Javadoc explictly says the order is not defined: http://docs.oracle.com/javase/6/docs/api/java/io/File.html#list() "There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order." So, what happens when the same class file exists in two JAR files in lib/ext? Thanks - Ioi From Alan.Bateman at oracle.com Fri Nov 15 21:01:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Nov 2013 21:01:17 +0000 Subject: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8 In-Reply-To: <528655FF.9030508@oracle.com> References: <528539CF.1010200@oracle.com> <52863168.2020408@oracle.com> <528655FF.9030508@oracle.com> Message-ID: <52868B9D.1040209@oracle.com> On 15/11/2013 17:12, Xueming Shen wrote: > I'm happy to put the "IAE with advanced positions" change back, the > webrev has been updated > according. > > http://cr.openjdk.java.net/~sherman/8028397/webrev/ That looks much better. One case that is still a bit awkward is where there are insufficient bits remaining in the source buffer, say when you are consuming from a channel and reading a chunk at a time. The decode(ByteBuffer, ByteBuffer) method really needs a boolean to indicate to the decoder if it capable of providing more bits. I guess it's too late to add that now. As regards the javadoc updates then a small typo on L660 (=> "is a padding character"). On L849, I think I would drop "current". Do you think decode(ByteBuffer) needs a sentence to make it clear that the input buffer's position may be advanced even if an exception is thrown? On the test then it looks like there isn't any coverage to check the output buffer's position has been advanced. Otherwise looks fine. -Alan. From john.r.rose at oracle.com Fri Nov 15 21:04:32 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 15 Nov 2013 13:04:32 -0800 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52859342.7040709@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> Message-ID: <23F42AA5-B243-46FA-8EFE-9CD95C2E0B76@oracle.com> On Nov 14, 2013, at 7:21 PM, Joseph Darcy wrote: > Catching up on email, the specification of java.lang.Class does not explicitly promise that its notion of equality must be identity for all time. Therefore, while not required for today's implementations, I would prefer that new code we write in the JDK use equals rather than == when comparing classes. There's no possible future where java.lang.Class would return true for equals but false for == (acmp). So there's no future-proofing to do here. Reification of generics might require something like this, but we could not break class identity without (as others have pointed out) breaking compatibility with a huge amount of code "in the wild". Before that would happen, we would introduce a new auxiliary type (e.g., java.lang.Species and java.lang.Object::getSpecies) that would represent the richer view of an object's runtime type. I do hope, in a future release, to "hack" reference equality, but in a different direction, allowing == (acmp) to return true *more often*, not allowing it to return *less often*. The point will be to align the semantics of equals and acmp *more* closely for some types, notably the wrappers and java.lang.String. (Interned referneces are so last-century.) ? John From mandy.chung at oracle.com Fri Nov 15 21:15:48 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Nov 2013 13:15:48 -0800 Subject: lib/ext JAR file search order In-Reply-To: <52868604.4040104@oracle.com> References: <52868604.4040104@oracle.com> Message-ID: <52868F04.7060106@oracle.com> On 11/15/2013 12:37 PM, Ioi Lam wrote: > From sun.misc.Launcher$ExtClassLoader: > > private static URL[] getExtURLs(File[] dirs) throws IOException { > Vector urls = new Vector(); > for (int i = 0; i < dirs.length; i++) { > String[] files = dirs[i].list(); > if (files != null) { > for (int j = 0; j < files.length; j++) { > if (!files[j].equals("meta-index")) { > File f = new File(dirs[i], files[j]); > urls.add(getFileURL(f)); > } > } > } > } > URL[] ua = new URL[urls.size()]; > urls.copyInto(ua); > return ua; > } > > > the search order is completely depending on the order of files > returned by File.list(), whose Javadoc explictly says the order is not > defined: > > http://docs.oracle.com/javase/6/docs/api/java/io/File.html#list() > > "There is no guarantee that the name strings in the > resulting array will appear in any specific order; > they are not, in particular, guaranteed to appear > in alphabetical order." > > So, what happens when the same class file exists in two JAR files in > lib/ext? > AFAIK The extension mechanism [1] doesn't specify the ordering of files searched in the directories listed in java.ext.dirs system property. If there are two JAR files in lib/ext containing the class file of the same name, the behavior is undefined. Mandy [1] http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html#installed From xueming.shen at oracle.com Fri Nov 15 21:22:14 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 15 Nov 2013 13:22:14 -0800 Subject: RFR JDK-8028397: Undo the lenient mimi decoder suport change (JDK-8025003) in jdk8 In-Reply-To: <52868B9D.1040209@oracle.com> References: <528539CF.1010200@oracle.com> <52863168.2020408@oracle.com> <528655FF.9030508@oracle.com> <52868B9D.1040209@oracle.com> Message-ID: <52869086.1080202@oracle.com> On 11/15/13 1:01 PM, Alan Bateman wrote: > On 15/11/2013 17:12, Xueming Shen wrote: >> I'm happy to put the "IAE with advanced positions" change back, the >> webrev has been updated >> according. >> >> http://cr.openjdk.java.net/~sherman/8028397/webrev/ > > That looks much better. > > One case that is still a bit awkward is where there are insufficient > bits remaining in the source buffer, say when you are consuming from a > channel and reading a chunk at a time. The decode(ByteBuffer, > ByteBuffer) method really needs a boolean to indicate to the decoder > if it capable of providing more bits. I guess it's too late to add > that now. We really need CodeResult here to have a full control of the decoding life circle. But the original goal is to have a "simple" API, without getting into this decoding state management. That said, to return a native value (either -1 or the native value of the bytes written) is better than to throw a IAE if you expect app to use this method to take care "under_flow" (charset term) management. It might look better to check the return value < 0, instead of catching the IAE and then recovery. > > As regards the javadoc updates then a small typo on L660 (=> "is a > padding character"). On L849, I think I would drop "current". Do you > think decode(ByteBuffer) needs a sentence to make it clear that the > input buffer's position may be advanced even if an exception is thrown? Did you mean "to make it clear that the input buffer's position will NOT be advanced"? the implementation and the intent of the spec is not to advance, since when we have a malformed input, we don't get an output buffer to collect the bytes decoded. So the case here is "there is malformed input, I can't do nothing for it, so I will not touch the src position..." > > > On the test then it looks like there isn't any coverage to check the > output buffer's position has been advanced. Otherwise looks fine. > The output buffer's position is "checked" by checking the its available (decoded) bytes against the expected. -Sherman From vitalyd at gmail.com Fri Nov 15 21:38:12 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 15 Nov 2013 16:38:12 -0500 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52864D0B.4010100@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> <52864D0B.4010100@oracle.com> Message-ID: Well using equals() would make byte code slightly larger and probably slow down interpreter for no good reason, so it's not fully harmless (with JIT code, yes, it's harmless). Sent from my phone On Nov 15, 2013 11:34 AM, "David Holmes" wrote: > On 15/11/2013 11:11 PM, Vitaly Davidovich wrote: > >> +1 >> >> The amount of code in the wild that would break (if this were to change) >> virtually guarantees that such a change won't happen, regardless of what >> current spec does or does not say. It would probably be easier to just >> update the spec at this point to match implementation. >> > > There is no need to update spec or implementation. Current code aligns > exactly with spec and spec is perfectly valid. The change to use equals() > over == was being proposed to future-proof the code in case the implicit > specification of Class.equals were to change in the future. Harmless but > pointless in my opinion. > > David > ----- > > Vitaly >> >> Sent from my phone >> On Nov 15, 2013 7:57 AM, "Stephen Colebourne" >> wrote: >> >> On 15 November 2013 03:21, Joseph Darcy wrote: >>> >>>> Catching up on email, the specification of java.lang.Class does not >>>> explicitly promise that its notion of equality must be identity for all >>>> time. Therefore, while not required for today's implementations, I would >>>> prefer that new code we write in the JDK use equals rather than == when >>>> comparing classes. >>>> >>> >>> I've used == for Class for many years. I expect many other developers >>> have done the same. I think that changing Class so identity was not >>> respected would break a *lot* of code. >>> >>> Stephen >>> >>> From mandy.chung at oracle.com Fri Nov 15 22:48:31 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Nov 2013 14:48:31 -0800 Subject: RFR: JDK-8028215 - ORB.init fails with SecurityException if properties select the JDK default ORB In-Reply-To: <528542A6.8020806@oracle.com> References: <528542A6.8020806@oracle.com> Message-ID: <5286A4BF.4000500@oracle.com> On 11/14/2013 1:37 PM, Mark Sheppard wrote: > Hi, > please oblige and review the following fix > > http://cr.openjdk.java.net/~msheppar/8028215/webrev/ > Looks okay. Seems like it worths some refactoring and change create_impl to take the classname of the default implementation and move the creation of the default implementation class instance in the create_impl method. As Alan mentioned, looks like java.policy.applet is same as the default policy file and it isn't needed. Mandy From mike.duigou at oracle.com Thu Nov 14 21:29:18 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 14 Nov 2013 14:29:18 -0700 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: References: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> Message-ID: Hi Steven; We were able to get some parts of your UUID patch into Java 8 but I unfortunately didn't get time to get all the pieces in before the Java 8 rampdown began. I was hoping to get the parsing part in next as it seemed to have a bigger payoff than the remaining toString() changes. These changes will likely happen early in Java 9 repo and then can be backported to Java 8. I will followup with Robert's patch as well. Mike On Nov 11 2013, at 11:39 , Steven Schlansker wrote: > > On Nov 6, 2013, at 4:19 PM, Robert Stupp wrote: > >> Hi, >> >> the current implementation of java.util.UUID.fromName() and java.util.UUID.toString() unnecessarily produce a lot of temporary objects. Especially the fromName() method creates some instances of java.lang.Long and indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString() creates at least 10 String objects plus the implicitly created char[] instances. >> >> Here's a hg diff which reduces the temporary object count while still providing the same functionality. >> > > > Hi Robert, > > I identified the same problem and submitted a patch earlier this year: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013494.html > http://osdir.com/ml/core-libs-dev/2013-03/msg00403.html > > Sorry I don?t have the best list message references here, Oracle seems to have decided to break all the links through the old Sun bug database, so all my references are gone. Bummer. :( > > It?s currently living at CR 8006627 and CR 8007398, although I?m having real trouble finding a public link to the bugs. > > Last I heard, Mike (CCed) has this in a patch queue somewhere waiting to commit it. Maybe he will take the good parts from my patch and the good parts from your patch and make an even better patch :) > > Regards, > Steven Schlansker > From mike.duigou at oracle.com Fri Nov 15 22:09:20 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 15 Nov 2013 15:09:20 -0700 Subject: RFR: patch to reduce use of many temporary objects in java.util.UUID In-Reply-To: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> References: <7870E2E9-5168-4A92-8B47-DFE59B4B077B@gmx.de> Message-ID: <23274BF3-07B4-4817-BD91-6EF309C9CAF9@oracle.com> Hi Robert; As mentioned in another thread with Steven Schlansker there is a patch in progress with similar goals. I will look at your patch and see how much overlap there is and merge in any relevant parts. This improvement won't make it into Java 8 but will be implemented early in the Java 9 lifecycle and can be backported to Java 8 updates. Thanks! Mike On Nov 6 2013, at 17:19 , Robert Stupp wrote: > Hi, > > the current implementation of java.util.UUID.fromName() and java.util.UUID.toString() unnecessarily produce a lot of temporary objects. Especially the fromName() method creates some instances of java.lang.Long and indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString() creates at least 10 String objects plus the implicitly created char[] instances. > > Here's a hg diff which reduces the temporary object count while still providing the same functionality. > > - > Robert > > > > > diff --git a/src/share/classes/java/util/UUID.java b/src/share/classes/java/util/UUID.java > --- a/src/share/classes/java/util/UUID.java > +++ b/src/share/classes/java/util/UUID.java > @@ -189,23 +189,68 @@ > * > */ > public static UUID fromString(String name) { > - String[] components = name.split("-"); > - if (components.length != 5) > + if (name.length() != 36) > throw new IllegalArgumentException("Invalid UUID string: "+name); > - for (int i=0; i<5; i++) > - components[i] = "0x"+components[i]; > > - long mostSigBits = Long.decode(components[0]).longValue(); > - mostSigBits <<= 16; > - mostSigBits |= Long.decode(components[1]).longValue(); > - mostSigBits <<= 16; > - mostSigBits |= Long.decode(components[2]).longValue(); > + long lo; > + long hi; > + lo = hi = 0; > > - long leastSigBits = Long.decode(components[3]).longValue(); > - leastSigBits <<= 48; > - leastSigBits |= Long.decode(components[4]).longValue(); > + for (int i = 0, j = 0; i < 36; ++j) { > + // Need to bypass hyphens: > > - return new UUID(mostSigBits, leastSigBits); > + switch (i) { > + case 8: > + case 13: > + case 18: > + case 23: > + if (name.charAt(i) != '-') > + throw new IllegalArgumentException("Invalid UUID string: "+name); > + > + ++i; > + } // switch > + > + int curr; > + char c = name.charAt(i); > + > + if (c >= '0' && c <= '9') > + curr = (c - '0'); > + > + else if (c >= 'a' && c <= 'f') > + curr = (c - 'a' + 10); > + > + else if (c >= 'A' && c <= 'F') > + curr = (c - 'A' + 10); > + > + else > + throw new IllegalArgumentException("Invalid UUID string: "+name); > + > + curr <<= 4; > + > + c = name.charAt(++i); > + > + if (c >= '0' && c <= '9') > + curr |= (c - '0'); > + > + else if (c >= 'a' && c <= 'f') > + curr |= (c - 'a' + 10); > + > + else if (c >= 'A' && c <= 'F') > + curr |= (c - 'A' + 10); > + > + else > + throw new IllegalArgumentException("Invalid UUID string: "+name); > + > + if (j < 8) > + hi = (hi << 8) | curr; > + > + else > + lo = (lo << 8) | curr; > + > + ++i; > + } // for > + > + return new UUID(hi, lo); > } > > // Field Accessor Methods > @@ -373,17 +418,27 @@ > * @return A string representation of this {@code UUID} > */ > public String toString() { > - return (digits(mostSigBits >> 32, 8) + "-" + > - digits(mostSigBits >> 16, 4) + "-" + > - digits(mostSigBits, 4) + "-" + > - digits(leastSigBits >> 48, 4) + "-" + > - digits(leastSigBits, 12)); > + char[] arr = new char[36]; > + arr[8] = arr[13] = arr[18] = arr[23] = '-'; > + long msb = mostSigBits; > + long lsb = leastSigBits; > + // upper 32 bit of MSB > + digits(msb >> 32, 8, arr, 0); > + // upper 16 bit of lower 32 bit of MSB > + digits(msb >> 16, 4, arr, 9); > + // lower 16 bit of lower 32 bit of MSB > + digits(msb, 4, arr, 14); > + // upper 16 bit of LSB > + digits(lsb, 4, arr, 19); > + // lower 48 bit of LSB > + digits(lsb, 12, arr, 24); > + return new String(arr); > } > > - /** Returns val represented by the specified number of hex digits. */ > - private static String digits(long val, int digits) { > - long hi = 1L << (digits * 4); > - return Long.toHexString(hi | (val & (hi - 1))).substring(1); > + private static final char[] HEX = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'}; > + private void digits(long v, int digits, char[] arr, int off) { > + for ( ; digits > 0 ; off++ ) > + arr[off] = HEX[ (int)(v&15) ]; > } > > /** > > From forax at univ-mlv.fr Sat Nov 16 10:21:08 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 16 Nov 2013 11:21:08 +0100 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52859342.7040709@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> Message-ID: <52874714.2030808@univ-mlv.fr> On 11/15/2013 04:21 AM, Joseph Darcy wrote: > Hello, > > Catching up on email, the specification of java.lang.Class does not > explicitly promise that its notion of equality must be identity for > all time. Therefore, while not required for today's implementations, I > would prefer that new code we write in the JDK use equals rather than > == when comparing classes. > > Cheers, > > -Joe The JLS requires implicitly that Class object are interned. JLS7 8.4.3.6 says that synchronized on a static method is equivalent to synchronized(Class.forName("CurrentClass")) so == is fine. cheers, R?mi > > On 10/31/2013 3:24 AM, David Holmes wrote: >> Hi Andreas, >> >> On 31/10/2013 7:49 PM, Andreas Lundblad wrote: >>> Hi, >>> >>> Please review the fix for JDK-8027470 below. >>> >>> Description: >>> AnnotationSupport compared Class-instances using '==' where it >>> should be using '.equals'. Fixed in this patch. >> >> Class is final and does not override Object.equals therefore it is >> guaranteed to be based on identity. This change, while harmless, is >> unnecessary. Comparison of Class instances with == occurs throughout >> the JDK. >> >> David >> ----- >> >>> Link to web review: >>> http://cr.openjdk.java.net/~alundblad/8027470 >>> >>> Link to bug reports: >>> http://bugs.openjdk.java.net/browse/JDK-8027470 >>> >>> -- Andreas Lundblad >>> > From forax at univ-mlv.fr Sat Nov 16 10:23:46 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 16 Nov 2013 11:23:46 +0100 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <23F42AA5-B243-46FA-8EFE-9CD95C2E0B76@oracle.com> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> <23F42AA5-B243-46FA-8EFE-9CD95C2E0B76@oracle.com> Message-ID: <528747B2.8030407@univ-mlv.fr> On 11/15/2013 10:04 PM, John Rose wrote: > On Nov 14, 2013, at 7:21 PM, Joseph Darcy wrote: > >> Catching up on email, the specification of java.lang.Class does not explicitly promise that its notion of equality must be identity for all time. Therefore, while not required for today's implementations, I would prefer that new code we write in the JDK use equals rather than == when comparing classes. > There's no possible future where java.lang.Class would return true for equals but false for == (acmp). So there's no future-proofing to do here. > > Reification of generics might require something like this, but we could not break class identity without (as others have pointed out) breaking compatibility with a huge amount of code "in the wild". > > Before that would happen, we would introduce a new auxiliary type (e.g., java.lang.Species and java.lang.Object::getSpecies) that would represent the richer view of an object's runtime type. > > I do hope, in a future release, to "hack" reference equality, but in a different direction, allowing == (acmp) to return true *more often*, not allowing it to return *less often*. The point will be to align the semantics of equals and acmp *more* closely for some types, notably the wrappers and java.lang.String. (Interned referneces are so last-century.) > > ? John +1 I think I prefer Variety to Species to get ride of the ambiguous plural. R?mi From forax at univ-mlv.fr Sat Nov 16 14:00:26 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 16 Nov 2013 15:00:26 +0100 Subject: An ad-hoc polymorphism way to create a stream Message-ID: <52877A7A.1050504@univ-mlv.fr> During Devoxx Belgium, after the talk of Brian and Jose Paumard, there was an interesting discussion among some Java8 early adopters about the fact that in the API there no xommon way to get a Stream for anything that is conceptually a collection. I propose to introduce the following new methods on Stream: /** * Returns a sequential|Stream| with the iterable as its source. * * @param T the type of stream elements. * @param iterable the iterable used as source of the stream. * @return a sequential stream. */ public static Stream from(Iterable iterable) { return StreamSupport.stream(iterable.spliterator(), false); } /** * Returns a sequential|Stream| with the collection as its source. * * @param T the type of stream elements. * @param collection the collection used as source of the stream. * @return a sequential stream. */ public static Stream from(Collection collection) { return collection.stream(); } /** * Returns a sequential|Stream| with the array as its source. * * @param T the type of stream elements. * @param array the array used as source of the stream. * @return a sequential stream. */ public static Stream from(T[] array) { return Stream.of(array); } These methods are like the of() methods but of() overloads deal with values while from() deal with collections. This also re-introduce a way to get a stream from an unknown Iterable that was removed from Iterable because we want implementation of Iterable to be able to return Stream of primitives. I know that this is late in the game, but I think that given these methods just delegates to existing methods, it will be better to introduce them in Java8 than in Java9. cheers, R?mi From patrick at reini.net Sat Nov 16 16:14:25 2013 From: patrick at reini.net (Patrick Reinhart) Date: Sat, 16 Nov 2013 17:14:25 +0100 Subject: An ad-hoc polymorphism way to create a stream In-Reply-To: <52877A7A.1050504@univ-mlv.fr> References: <52877A7A.1050504@univ-mlv.fr> Message-ID: <3D3CA7CE-4C1F-48ED-BBE8-6E1349428BC1@reini.net> Hi Remi, That was also the first failed lookup try after starting with Lambdas, specially because we got a lot of own implementation implementing Iterable. It would have been more natural from me to find some according methods on the Stream interface. Especially as a beginner. Cheers Patrick Am 16.11.2013 um 15:00 schrieb Remi Forax : > During Devoxx Belgium, after the talk of Brian and Jose Paumard, there was an interesting discussion among some Java8 early adopters about the fact that in the API there no xommon way to get a Stream for anything that is conceptually a collection. > > I propose to introduce the following new methods on Stream: > > /** > * Returns a sequential|Stream| with the iterable as its source. > * > * @param T the type of stream elements. > * @param iterable the iterable used as source of the stream. > * @return a sequential stream. > */ > public static Stream from(Iterable iterable) { > return StreamSupport.stream(iterable.spliterator(), false); > } > > /** > * Returns a sequential|Stream| with the collection as its source. > * > * @param T the type of stream elements. > * @param collection the collection used as source of the stream. > * @return a sequential stream. > */ > public static Stream from(Collection collection) { > return collection.stream(); > } > > /** > * Returns a sequential|Stream| with the array as its source. > * > * @param T the type of stream elements. > * @param array the array used as source of the stream. > * @return a sequential stream. > */ > public static Stream from(T[] array) { > return Stream.of(array); > } > > These methods are like the of() methods but of() overloads deal with values while from() deal with collections. > > This also re-introduce a way to get a stream from an unknown Iterable that was removed from Iterable > because we want implementation of Iterable to be able to return Stream of primitives. > I know that this is late in the game, but I think that given these methods just delegates to existing methods, > it will be better to introduce them in Java8 than in Java9. > > cheers, > R?mi > From patrick at reini.net Sat Nov 16 16:24:31 2013 From: patrick at reini.net (Patrick Reinhart) Date: Sat, 16 Nov 2013 17:24:31 +0100 Subject: An ad-hoc polymorphism way to create a stream In-Reply-To: <3D3CA7CE-4C1F-48ED-BBE8-6E1349428BC1@reini.net> References: <52877A7A.1050504@univ-mlv.fr> <3D3CA7CE-4C1F-48ED-BBE8-6E1349428BC1@reini.net> Message-ID: Quoting myself. What is the reason for naming the methods: "from(xx)" instead of "of(xx)" as the existing ones taking varargs and so on? Cheers Patrick Am 16.11.2013 um 17:14 schrieb Patrick Reinhart : > Hi Remi, > > That was also the first failed lookup try after starting with Lambdas, specially because we got a lot of own implementation implementing Iterable. It would have been more natural from me to find some according methods on the Stream interface. Especially as a beginner. > > Cheers Patrick > > Am 16.11.2013 um 15:00 schrieb Remi Forax : > >> During Devoxx Belgium, after the talk of Brian and Jose Paumard, there was an interesting discussion among some Java8 early adopters about the fact that in the API there no xommon way to get a Stream for anything that is conceptually a collection. >> >> I propose to introduce the following new methods on Stream: >> >> /** >> * Returns a sequential|Stream| with the iterable as its source. >> * >> * @param T the type of stream elements. >> * @param iterable the iterable used as source of the stream. >> * @return a sequential stream. >> */ >> public static Stream from(Iterable iterable) { >> return StreamSupport.stream(iterable.spliterator(), false); >> } >> >> /** >> * Returns a sequential|Stream| with the collection as its source. >> * >> * @param T the type of stream elements. >> * @param collection the collection used as source of the stream. >> * @return a sequential stream. >> */ >> public static Stream from(Collection collection) { >> return collection.stream(); >> } >> >> /** >> * Returns a sequential|Stream| with the array as its source. >> * >> * @param T the type of stream elements. >> * @param array the array used as source of the stream. >> * @return a sequential stream. >> */ >> public static Stream from(T[] array) { >> return Stream.of(array); >> } >> >> These methods are like the of() methods but of() overloads deal with values while from() deal with collections. >> >> This also re-introduce a way to get a stream from an unknown Iterable that was removed from Iterable >> because we want implementation of Iterable to be able to return Stream of primitives. >> I know that this is late in the game, but I think that given these methods just delegates to existing methods, >> it will be better to introduce them in Java8 than in Java9. >> >> cheers, >> R?mi >> > From joel.franck at oracle.com Mon Nov 18 07:54:32 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Mon, 18 Nov 2013 08:54:32 +0100 Subject: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects In-Reply-To: <52874714.2030808@univ-mlv.fr> References: <20131031094920.GA28773@e6430> <52722FC9.70607@oracle.com> <52859342.7040709@oracle.com> <52874714.2030808@univ-mlv.fr> Message-ID: <20131118075432.GA13952@oracle.com> Hi all, On 2013-11-16, Remi Forax wrote: > On 11/15/2013 04:21 AM, Joseph Darcy wrote: > >Hello, > > > >Catching up on email, the specification of java.lang.Class does > >not explicitly promise that its notion of equality must be > >identity for all time. Therefore, while not required for today's > >implementations, I would prefer that new code we write in the JDK > >use equals rather than == when comparing classes. > > > >Cheers, > > > >-Joe > > The JLS requires implicitly that Class object are interned. > JLS7 8.4.3.6 says that synchronized on a static method is equivalent to > synchronized(Class.forName("CurrentClass")) > so == is fine. > Also the VM spec $5.3 notes that "A well-behaved class loader should maintain three properties: Given the same name, a good class loader should always return the same Class object." (Granted "the same" might not be formal, and this is a recommendation.) cheers /Joel From tomasz.kowalczewski at gmail.com Mon Nov 18 08:46:33 2013 From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski) Date: Mon, 18 Nov 2013 09:46:33 +0100 Subject: Why stream from BufferedReader::lines is not closing the reader? Message-ID: Hi, I am starting to learn how streams interact with I/O and I have question on java.io.BufferedReader::lines method. Please excuse me if this is not the right list (I did not found core-libs-discuss or similar). I am using build 115. The stream returned by call to ::lines does not close the reader after terminal operation is executed (e.g. collect()). Javadoc for this method states that: *

After execution of the terminal stream operation there are no * guarantees that the reader will be at a specific position from which to * read the next character or line. This implies that the reader is not closed. But: 1. For clarity it might be good to spell it out that reader is not closed. 2. If, according to the javadoc, the reader is left in undefined state after stream terminal operation then why not close it already? I know that I can read more lines from it afterwards and it will work, others will notice it too. This might lead to unpleasant surprises once some (minor or major) java update changes the implementation and all code relying in this feature will break in subtle ways (e.g. missing a line or two). 3. If I want the stream to be closed I need to do: reader.lines().onClose(is::close).doStreamyStuff().collect(...); where *is* is an underlying InputStream. The problem with this code is that ::close throws IOException which is not compatible with Runnable accepted by onClose(); Is there a better way? Some wrapper I can use to inject a call to close? -- Regards, Tomasz Kowalczewski From staffan.larsen at oracle.com Mon Nov 18 09:23:38 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 18 Nov 2013 09:23:38 +0000 Subject: hg: jdk8/tl/jdk: 8023138: [TEST_BUG] java/lang/instrument/PremainClass/NoPremainAgent.sh fails intermittently Message-ID: <20131118092351.C8CA76265B@hg.openjdk.java.net> Changeset: 64a492bc0ba7 Author: sla Date: 2013-11-14 12:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64a492bc0ba7 8023138: [TEST_BUG] java/lang/instrument/PremainClass/NoPremainAgent.sh fails intermittently Summary: Port tests for java/lang/instrument/PremainClass from script to java Reviewed-by: sla Contributed-by: mattias.tobiasson at oracle.com - test/java/lang/instrument/PremainClass/NoPremainAgent.sh + test/java/lang/instrument/PremainClass/NoPremainAgentTest.java + test/java/lang/instrument/PremainClass/PremainClassTest.java - test/java/lang/instrument/PremainClass/PremainClassTest.sh - test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh + test/java/lang/instrument/PremainClass/ZeroArgPremainAgentTest.java ! test/lib/testlibrary/jdk/testlibrary/Utils.java From mcnepp02 at googlemail.com Mon Nov 18 10:03:46 2013 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 18 Nov 2013 11:03:46 +0100 Subject: Why stream from BufferedReader::lines is not closing the reader? In-Reply-To: References: Message-ID: Hi Tomasz, I think the answer to your question "Why does the stream from BufferedReader.lines() not close the Reader?" is: Because the stream did not open the Reader! It mainly boils down to following a well-proven convention: Whoever creates a Resource is responsible for closing it. Thus, you should wrap your BufferedReader in a try-with-resources-block and be done with it, or resort to the static method java.nio.files.Files.lines(Path, Charset). That one does indeed create the underlying resource, and thus, as you'd expect, disposes of it in the Stream's close method! 2013/11/18 Tomasz Kowalczewski > Hi, > > I am starting to learn how streams interact with I/O and I have question on > java.io.BufferedReader::lines method. Please excuse me if this is not the > right list (I did not found core-libs-discuss or similar). > > I am using build 115. > > The stream returned by call to ::lines does not close the reader after > terminal operation is executed (e.g. collect()). Javadoc for this method > states that: > > *

After execution of the terminal stream operation there are no > * guarantees that the reader will be at a specific position from which > to > * read the next character or line. > > This implies that the reader is not closed. But: > > 1. For clarity it might be good to spell it out that reader is not closed. > 2. If, according to the javadoc, the reader is left in undefined state > after stream terminal operation then why not close it already? I know that > I can read more lines from it afterwards and it will work, others will > notice it too. This might lead to unpleasant surprises once some (minor or > major) java update changes the implementation and all code relying in this > feature will break in subtle ways (e.g. missing a line or two). > 3. If I want the stream to be closed I need to do: > > reader.lines().onClose(is::close).doStreamyStuff().collect(...); > > where *is* is an underlying InputStream. > > The problem with this code is that ::close throws IOException which is not > compatible with Runnable accepted by onClose(); Is there a better way? Some > wrapper I can use to inject a call to close? > > -- > Regards, > Tomasz Kowalczewski > From Alan.Bateman at oracle.com Mon Nov 18 10:10:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Nov 2013 10:10:16 +0000 Subject: Why stream from BufferedReader::lines is not closing the reader? In-Reply-To: References: Message-ID: <5289E788.4090504@oracle.com> On 18/11/2013 08:46, Tomasz Kowalczewski wrote: > 3. If I want the stream to be closed I need to do: > > reader.lines().onClose(is::close).doStreamyStuff().collect(...); > > where *is* is an underlying InputStream. > > The problem with this code is that ::close throws IOException which is not > compatible with Runnable accepted by onClose(); Is there a better way? Some > wrapper I can use to inject a call to close? > As you have a reference to the buffered reader it might be simplest to use try-with-resources so that the reader (and hence the underlying input stream) will be closed, something like: try (BufferReader reader = ...) { reader.lines().doStreamyStuff().collect(...); } Alternatively, if the reader is to a file then you can use Files.lines as it returns a Stream that will arrange to close the underlying file when you close the stream. Otherwise if you really need to really want the stream close to close the underlying input stream (or reader more likely) then the runnable will need to translate the checked IOException to an unchecked exception. The new java.io.UncheckedIOException is probably what you want. -Alan. From Alan.Bateman at oracle.com Mon Nov 18 10:17:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Nov 2013 10:17:03 +0000 Subject: RFR: JDK-8028215 - ORB.init fails with SecurityException if properties select the JDK default ORB In-Reply-To: <5286A4BF.4000500@oracle.com> References: <528542A6.8020806@oracle.com> <5286A4BF.4000500@oracle.com> Message-ID: <5289E91F.9050509@oracle.com> On 15/11/2013 22:48, Mandy Chung wrote: > : > > Looks okay. Seems like it worths some refactoring and change > create_impl to take the classname of the default implementation and > move the creation of the default implementation class instance in the > create_impl method. It used to do that but we deliberately changed it to statically reference the default implementation as part of the changes to restrict access to com.sun.corba.se.**. -Alan. From tomasz.kowalczewski at gmail.com Mon Nov 18 12:42:28 2013 From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski) Date: Mon, 18 Nov 2013 13:42:28 +0100 Subject: Why stream from BufferedReader::lines is not closing the reader? In-Reply-To: <5289E788.4090504@oracle.com> References: <5289E788.4090504@oracle.com> Message-ID: Hi, thanks for your answers. Typically I would agree with Gernot that "Whoever creates a Resource is responsible for closing it.". My example here might have been little misleading in this regard. Reader close() method closes the InputStream that was passed to it (thus violating this principle) and what I really wanted is to close the Reader (which in turns closes the input stream). I still think that it would be more user friendly if classes dealing with I/O should indicate if and when they (don't) close the stream. As for Alan's answer: My motivation was following use case: I am downloading files from remote service and flatMapping them into lines they contain. Creation of the Reader was hidden inside the mapper. My code does exactly what you suggested with wrapping the ::close call and throwing UncheckedIOException. I hoped to get some guidance in how can I reduce boilerplate even further. As I see it now everyone will be writing such wrappers themselves. It is not to say that I don't greatly appreciate all the hard work of all people involved in lambdification of Java. It's fantastic work you have done. On Mon, Nov 18, 2013 at 11:10 AM, Alan Bateman wrote: > On 18/11/2013 08:46, Tomasz Kowalczewski wrote: > >> 3. If I want the stream to be closed I need to do: >> >> reader.lines().onClose(is::close).doStreamyStuff().collect(...); >> >> where *is* is an underlying InputStream. >> >> The problem with this code is that ::close throws IOException which is not >> compatible with Runnable accepted by onClose(); Is there a better way? >> Some >> wrapper I can use to inject a call to close? >> >> As you have a reference to the buffered reader it might be simplest to > use try-with-resources so that the reader (and hence the underlying input > stream) will be closed, something like: > > try (BufferReader reader = ...) { > reader.lines().doStreamyStuff().collect(...); > } > > Alternatively, if the reader is to a file then you can use Files.lines as > it returns a Stream that will arrange to close the underlying file when you > close the stream. > > Otherwise if you really need to really want the stream close to close the > underlying input stream (or reader more likely) then the runnable will need > to translate the checked IOException to an unchecked exception. The new > java.io.UncheckedIOException is probably what you want. > > -Alan. > > > > > > > > -- Tomasz Kowalczewski From jaroslav.bachorik at oracle.com Mon Nov 18 14:27:18 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Mon, 18 Nov 2013 14:27:18 +0000 Subject: hg: jdk8/tl/jdk: 8027163: sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be updated for jdk8 removal of solaris-32bit support Message-ID: <20131118142734.7C3B362664@hg.openjdk.java.net> Changeset: d842131d12d8 Author: jbachorik Date: 2013-11-18 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d842131d12d8 8027163: sun/management/jmxremote/bootstrap/CustomLauncherTest.java should be updated for jdk8 removal of solaris-32bit support Reviewed-by: sla ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java + test/sun/management/jmxremote/bootstrap/solaris-amd64/launcher - test/sun/management/jmxremote/bootstrap/solaris-i586/launcher - test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher + test/sun/management/jmxremote/bootstrap/solaris-sparcv9/launcher From brian.goetz at oracle.com Mon Nov 18 14:28:25 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 18 Nov 2013 09:28:25 -0500 Subject: Why stream from BufferedReader::lines is not closing the reader? In-Reply-To: References: <5289E788.4090504@oracle.com> Message-ID: <528A2409.8030401@oracle.com> Gernot's answer is exactly correct. Think of it this way: do you expect BufferedReader.readLine() to close the stream when it is at the EOF? Because that's all lines() does -- repeatedly call readLine() for you. If you opened the buffered reader, then try-with-resources is what you want. But, all is not lost. Based on your complaint, my guess is that you're wondering what to do in a case where you open the BR as part of a flatMap operation, like "enumerate the files, then for each file, enumerate the lines". Here, we support the rule of "whoever opens the stream, closes the stream" by closing the stream that is returned by a flatMapper after iterating it. 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 br.lines.onClose(br::close); } ... Now, this is not terrible, but a little roundabout. We anticipated this would be a common case and created static methods in Files which create streams that are already set up with close handlers. So you could do: try { Files.walk(dir) .flatMap(Files::lines) ... and everything will work as you expect. Actually, to be totally safe, you should also handle the closing of the top-level stream: try (Stream paths = Files.walk(dir)) { paths.flatMap(Files::lines)... } To summarize, flatMap() is the only operation that internally closes the stream after its done, and for good reason -- it is the only case where the stream is effectively opened by the operation itself, and therefore should be closed by the operation too. Any other streams are assumed to be opened by the caller, and therefore should be closed by the caller. On 11/18/2013 7:42 AM, Tomasz Kowalczewski wrote: > Hi, > > thanks for your answers. > > Typically I would agree with Gernot that "Whoever creates a Resource is > responsible for closing it.". My example here might have been little > misleading in this regard. > Reader close() method closes the InputStream that was passed to it (thus > violating this principle) and what I really wanted is to close the Reader > (which in turns closes the input stream). > > I still think that it would be more user friendly if classes dealing with > I/O should indicate if and when they (don't) close the stream. > > As for Alan's answer: > > My motivation was following use case: I am downloading files from remote > service and flatMapping them into lines they contain. Creation of the > Reader was hidden inside the mapper. My code does exactly what you > suggested with wrapping the ::close call and throwing UncheckedIOException. > > I hoped to get some guidance in how can I reduce boilerplate even further. > As I see it now everyone will be writing such wrappers themselves. > > It is not to say that I don't greatly appreciate all the hard work of all > people involved in lambdification of Java. It's fantastic work you have > done. > > > > > On Mon, Nov 18, 2013 at 11:10 AM, Alan Bateman wrote: > >> On 18/11/2013 08:46, Tomasz Kowalczewski wrote: >> >>> 3. If I want the stream to be closed I need to do: >>> >>> reader.lines().onClose(is::close).doStreamyStuff().collect(...); >>> >>> where *is* is an underlying InputStream. >>> >>> The problem with this code is that ::close throws IOException which is not >>> compatible with Runnable accepted by onClose(); Is there a better way? >>> Some >>> wrapper I can use to inject a call to close? >>> >>> As you have a reference to the buffered reader it might be simplest to >> use try-with-resources so that the reader (and hence the underlying input >> stream) will be closed, something like: >> >> try (BufferReader reader = ...) { >> reader.lines().doStreamyStuff().collect(...); >> } >> >> Alternatively, if the reader is to a file then you can use Files.lines as >> it returns a Stream that will arrange to close the underlying file when you >> close the stream. >> >> Otherwise if you really need to really want the stream close to close the >> underlying input stream (or reader more likely) then the runnable will need >> to translate the checked IOException to an unchecked exception. The new >> java.io.UncheckedIOException is probably what you want. >> >> -Alan. >> >> >> >> >> >> >> >> > > From blackdrag at gmx.org Mon Nov 18 14:59:29 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 18 Nov 2013 15:59:29 +0100 Subject: CallerSensitive access rights problems Message-ID: <528A2B51.1020203@gmx.org> 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 want to build our runtime structure for this class, and the security manager is not allowing access to sun.reflect, then we get into trouble. https://jira.codehaus.org/browse/GROOVY-6405 is caused by this. What do you suggest people with this problem, if adding accessClassInPackage.sun.reflect is no option? bye Jochen From jaroslav.bachorik at oracle.com Mon Nov 18 15:22:31 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Mon, 18 Nov 2013 15:22:31 +0000 Subject: hg: jdk8/tl/jdk: 8028433: [TESTBUG] add -XX:+UsePerfData to some sun.management tests Message-ID: <20131118152246.47D0762666@hg.openjdk.java.net> Changeset: 0298ebbaf3b8 Author: jbachorik Date: 2013-11-18 16:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0298ebbaf3b8 8028433: [TESTBUG] add -XX:+UsePerfData to some sun.management tests Reviewed-by: sla, egahlin ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java From Alan.Bateman at oracle.com Mon Nov 18 15:31:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Nov 2013 15:31:51 +0000 Subject: CallerSensitive access rights problems In-Reply-To: <528A2B51.1020203@gmx.org> References: <528A2B51.1020203@gmx.org> Message-ID: <528A32E7.2080505@oracle.com> 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 want to build our runtime structure for this > class, and the security manager is not allowing access to sun.reflect, > then we get into trouble. https://jira.codehaus.org/browse/GROOVY-6405 > is caused by this. > > What do you suggest people with this problem, if adding > accessClassInPackage.sun.reflect is no option? Is it sun.reflect.CallerSensitive.class.getDeclaredMethods that is failing? -Alan. From paul.sandoz at oracle.com Mon Nov 18 15:38:04 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 18 Nov 2013 16:38:04 +0100 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <528484F3.5030706@oracle.com> References: <528484F3.5030706@oracle.com> Message-ID: <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> Hi Joe, You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: public final OptionalDouble average() { double[] avg = collect(() -> new double[2], (ll, i) -> { ll[0]++; ll[1] += i; }, (ll, rr) -> { ll[0] += rr[0]; ll[1] += rr[1]; }); return avg[0] > 0 ? OptionalDouble.of(avg[1] / avg[0]) : OptionalDouble.empty(); } That would be the most expedient way. However, for sum() it is somewhat unfortunate to have to create a double[1] box for each leaf. If you are willing to write a little more more code you can create your own double sum ReducingSink implementation as Brian suggests. Testing wise you don't need to implement an Iterator, you can do the following: DoubleStream.iterate(base, e -> increment).limit(count) It might be more convenient to test as follows: Stream s = Stream.iterate(false, e -> true).limit(count); // [*] DoubleSummaryStatistics stats = s.collect(Collectors.summarizingDouble(e -> e ? increment : base)); // Cross fingers that compiles! Stream s = Stream.iterate(false, e -> true).limit(count); Double d = s.iterate(false, e -> true).limit(count)..collect(Collectors.summingDouble(e ? increment : base)); Thereby covering both Collector implementations. I guess it might be harder to test the combining step using parallel streams since combining will be platform dependent (depends on #cores) unless you track how things are combined. Perhaps the Collector instance could be tested directly with combination? Paul. [*] Another way is to use stream concatenation: Stream.concat(Stream.of(false), IntStream.range(1, count).mapToObj(e -> true)) Stream.concat(Stream.of(false), Stream.generate(() -> true)).limit(count) On Nov 14, 2013, at 9:08 AM, Joe Darcy wrote: > Hello, > > Please take an initial look over a fix for > > JDK-8006572 DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors > http://cr.openjdk.java.net/~darcy/8006572.0/ > > The basic approach is to use compensated summation > > http://en.wikipedia.org/wiki/Kahan_summation_algorithm > > to computed streams-related sum and average statistics in the various locations that this can be done. > > All existing streams tests pass and new newly-written test passes too. > > I believe the DoubleSummaryStatistics.java portion, including the test, is fully review-worthy. In the test, for the sample computation in question, the naive summation implementation had a error of 500,000 ulps compared to 2 ups with the new implementation. > > Two other locations I've found where this summation technique should be used are in > > java.util.stream.Collectors.{summingDouble, averagingDouble} > > and > > java.util.stream.DoublePipeline.{sum, average} > > DoublePipeline is the primary implementation class of DoubleStream. > > For Collectors, the proposed code is a fairly clear adaptation of how the current code passes state around; there is not currently a dedicated test for the new summation technique in this location. > > I'm new to the streams API so for DoublePipeline I don't know the idiomatic way to phrase the collect I want to perform over the code. (Based on my current understanding, I believe I want to perform a collect rather than a reduce since for the compensated summation I need to maintain some additional state.) Guidance here welcome. > > Thanks, > > -Joe From peter.levart at gmail.com Mon Nov 18 15:39:36 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 18 Nov 2013 16:39:36 +0100 Subject: Why stream from BufferedReader::lines is not closing the reader? In-Reply-To: <528A2409.8030401@oracle.com> References: <5289E788.4090504@oracle.com> <528A2409.8030401@oracle.com> Message-ID: <528A34B8.8010908@gmail.com> 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 br.lines.onClose(br::close); > } > ... ...the only problem with above code is that it doesn't compile, because of IOException declared on BufferedReader (FileReader actually!) constructor and BufferedReader.close() method. The solutions to this have already been discussed on the list some time ago, and one of the propositions was to create interfaces like: public interface IOFunction extends Function { default R apply(T t) { try { return applyIO(t); } catch (IOException e) { throw new UncheckedIOException(e); } } R applyIO(T t) throws IOException; } public interface IORunnable extends Runnable { default void run() { try { runIO(); } catch (IOException e) { throw new UncheckedIOException(e); } } void ruinIO() throws IOException; } ...etc, and use them in code like this: List paths = ... paths .stream() .flatMap((IOFunction>) path -> { BufferedReader br = new BufferedReader(new FileReader(path)); return br.lines().onClose((IORunnable) br::close); }) .forEach(System.out::println); Regards, Peter From alexander.zuev at oracle.com Mon Nov 18 16:23:09 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 18 Nov 2013 16:23:09 +0000 Subject: hg: jdk8/tl/jdk: 8028197: tools/launcher/DiacriticTest.java failed on MacOSX: Input length = 1 Message-ID: <20131118162324.0DF626266A@hg.openjdk.java.net> Changeset: c2b56fe61626 Author: kizune Date: 2013-11-18 20:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2b56fe61626 8028197: tools/launcher/DiacriticTest.java failed on MacOSX: Input length = 1 Reviewed-by: ksrini ! test/tools/launcher/DiacriticTest.java From peter.levart at gmail.com Mon Nov 18 16:36:50 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 18 Nov 2013 17:36:50 +0100 Subject: CallerSensitive access rights problems In-Reply-To: <528A32E7.2080505@oracle.com> References: <528A2B51.1020203@gmx.org> <528A32E7.2080505@oracle.com> Message-ID: <528A4222.8070105@gmail.com> 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 want to build our runtime structure for this >> class, and the security manager is not allowing access to >> sun.reflect, then we get into trouble. >> https://jira.codehaus.org/browse/GROOVY-6405 is caused by this. >> >> What do you suggest people with this problem, if adding >> accessClassInPackage.sun.reflect is no option? > Is it sun.reflect.CallerSensitive.class.getDeclaredMethods that is > failing? > > -Alan. From GROOVY-6405 discussion I think it is, yes. The work-around suggested in GROOVY-6405 does not work, because it has a bug. It should be written as: private static void setAnnotationMetaData(Annotation[] annotations /*, AnnotatedNode an */) { for (Annotation annotation : annotations) { if (annotation*.annotationType()*.getPackage() == null || !"sun.reflect".equals(annotation*.annotationType()*.getPackage().getName())) { System.out.println("Processing: " + annotation.annotationType().getName()); } else { System.out.println("Skipping: " + annotation.annotationType().getName()); } } } ... i.e. don't call annotation.*getClass()* because what you get is a dynamic Proxy class implementing the annotation interface and such Proxy class does not live in the same package as the annotation interface... There is another such annotation to watch for, in another protected package: *sun.misc.Contended* ... Regards, Peter From tom.hawtin at oracle.com Mon Nov 18 16:54:04 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 18 Nov 2013 16:54:04 +0000 Subject: CallerSensitive access rights problems In-Reply-To: <528A2B51.1020203@gmx.org> References: <528A2B51.1020203@gmx.org> Message-ID: <528A462C.7070504@oracle.com> On 18/11/2013 14:59, Jochen Theodorou wrote: > > 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 want to build our runtime structure for this > class, and the security manager is not allowing access to sun.reflect, > then we get into trouble. https://jira.codehaus.org/browse/GROOVY-6405 > is caused by this. The stack trace in the bug report is running under Google App Engine. I have no idea what GAE does about security. Anyway, it appears that that you are trying to access an annotation under package.access applied to a public class. If you are running untrusted code under a security manager, I guess you just want to ignore those. Catching the security exception seems more reliable that testing for a specific package name. Tom From magnus.ihse.bursie at oracle.com Mon Nov 18 17:53:58 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:53:58 +0000 Subject: hg: jdk8/tl: 8027566: Remove the old build system Message-ID: <20131118175359.385806266D@hg.openjdk.java.net> Changeset: a667caba1e84 Author: ihse Date: 2013-11-14 10:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a667caba1e84 8027566: Remove the old build system Reviewed-by: erikj, tbell ! Makefile - NewMakefile.gmk ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/compare.sh - common/makefiles/HotspotWrapper.gmk - common/makefiles/IdlCompilation.gmk - common/makefiles/JavaCompilation.gmk - common/makefiles/Jprt.gmk - common/makefiles/Main.gmk - common/makefiles/MakeBase.gmk - common/makefiles/MakeHelpers.gmk - common/makefiles/Makefile - common/makefiles/NativeCompilation.gmk - common/makefiles/RMICompilation.gmk - common/makefiles/devkit/Makefile - common/makefiles/devkit/Tools.gmk - common/makefiles/javadoc/CORE_PKGS.gmk - common/makefiles/javadoc/Javadoc.gmk - common/makefiles/javadoc/NON_CORE_PKGS.gmk - common/makefiles/javadoc/Notes.html - common/makefiles/support/ListPathsSafely-post-compress.incl - common/makefiles/support/ListPathsSafely-pre-compress.incl - common/makefiles/support/ListPathsSafely-uncompress.sed - common/makefiles/support/unicode2x.sed ! common/nb_native/nbproject/configurations.xml - make/Defs-internal.gmk + make/HotspotWrapper.gmk + make/Javadoc.gmk + make/Jprt.gmk + make/Main.gmk + make/MakeHelpers.gmk - make/README.pre-components + make/common/CORE_PKGS.gmk + make/common/IdlCompilation.gmk + make/common/JavaCompilation.gmk + make/common/MakeBase.gmk + make/common/NON_CORE_PKGS.gmk + make/common/NativeCompilation.gmk + make/common/RMICompilation.gmk + make/common/support/ListPathsSafely-post-compress.incl + make/common/support/ListPathsSafely-pre-compress.incl + make/common/support/ListPathsSafely-uncompress.sed + make/common/support/unicode2x.sed - make/corba-rules.gmk - make/deploy-rules.gmk + make/devkit/Makefile + make/devkit/Tools.gmk - make/hotspot-rules.gmk - make/install-rules.gmk - make/jaxp-rules.gmk - make/jaxws-rules.gmk - make/jdk-rules.gmk - make/jprt.gmk - make/langtools-rules.gmk - make/nashorn-rules.gmk - make/sanity-rules.gmk - make/scripts/fixpath.pl - make/scripts/vsvars.sh - make/sponsors-rules.gmk From magnus.ihse.bursie at oracle.com Mon Nov 18 17:54:40 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:54:40 +0000 Subject: hg: jdk8/tl/jaxp: 8027566: Remove the old build system Message-ID: <20131118175447.806826266F@hg.openjdk.java.net> Changeset: 80acb8151797 Author: ihse Date: 2013-11-04 11:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/80acb8151797 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildJaxp.gmk ! make/Makefile - make/jprt.properties - make/scripts/update_src.sh - makefiles/BuildJaxp.gmk - makefiles/Makefile From magnus.ihse.bursie at oracle.com Mon Nov 18 17:54:07 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:54:07 +0000 Subject: hg: jdk8/tl/corba: 8027566: Remove the old build system Message-ID: <20131118175409.7B3D76266E@hg.openjdk.java.net> Changeset: 9729f9862eb4 Author: ihse Date: 2013-11-04 11:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9729f9862eb4 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildCorba.gmk ! make/Makefile - make/com/Makefile - make/com/sun/Makefile - make/com/sun/corba/Makefile - make/com/sun/corba/minclude/com_sun_corba_se_PortableActivationIDL.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_activation.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_corba.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_core.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_interceptors.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_legacy.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_logging.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_monitoring.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_cosnaming.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_namingutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_naming_pcosnaming.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_poa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_oa_toa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_orb.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_presentation_rmi.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_resolver.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_transport.jmk - make/com/sun/corba/minclude/com_sun_corba_se_impl_util.jmk - make/com/sun/corba/minclude/com_sun_corba_se_internal_LegacyFiles.jmk - make/com/sun/corba/minclude/com_sun_corba_se_pept.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_activation.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_copyobject.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_encoding.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_extension.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_ior.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_connection.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_logging.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_oa.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_orb.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_orbutil.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_protocol.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_resolver.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_servicecontext.jmk - make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk - make/com/sun/corba/minclude/com_sun_tools_corba_se_idl_toJavaPortable.jmk - make/com/sun/corba/minclude/javax_activity.jmk - make/com/sun/corba/minclude/javax_rmi.jmk - make/com/sun/corba/minclude/javax_rmi_CORBA.jmk - make/com/sun/corba/minclude/javax_transaction.jmk - make/com/sun/corba/minclude/org_omg_CORBA.jmk - make/com/sun/corba/minclude/org_omg_CORBAX.jmk - make/com/sun/corba/minclude/org_omg_CORBA_2_3.jmk - make/com/sun/corba/minclude/org_omg_CosNaming.jmk - make/com/sun/corba/minclude/org_omg_DynamicAny.jmk - make/com/sun/corba/minclude/org_omg_IOP.jmk - make/com/sun/corba/minclude/org_omg_Messaging.jmk - make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk - make/com/sun/corba/minclude/org_omg_PortableServer.jmk - make/com/sun/corba/minclude/org_omg_SendingContext.jmk - make/com/sun/corba/minclude/sun_corba.jmk - make/com/sun/corba/se/Makefile - make/com/sun/corba/se/PortableActivationIDL/Makefile - make/com/sun/corba/se/connection/FILES_java.gmk - make/com/sun/corba/se/connection/Makefile - make/com/sun/corba/se/core/Makefile - make/com/sun/corba/se/corespi/Makefile - make/com/sun/corba/se/impl/Makefile - make/com/sun/corba/se/impl/activation/Makefile - make/com/sun/corba/se/impl/activation/orbd/Makefile - make/com/sun/corba/se/impl/activation/servertool/Makefile - make/com/sun/corba/se/impl/interceptors/Makefile - make/com/sun/corba/se/impl/logging/Makefile - make/com/sun/corba/se/impl/monitoring/Makefile - make/com/sun/corba/se/impl/naming/Makefile - make/com/sun/corba/se/impl/naming/cosnaming/Makefile - make/com/sun/corba/se/impl/naming/namingutil/Makefile - make/com/sun/corba/se/impl/naming/pcosnaming/Makefile - make/com/sun/corba/se/impl/oa/Makefile - make/com/sun/corba/se/impl/oa/poa/Makefile - make/com/sun/corba/se/impl/oa/toa/Makefile - make/com/sun/corba/se/interceptor/FILES_java.gmk - make/com/sun/corba/se/interceptor/Makefile - make/com/sun/corba/se/pept/Makefile - make/com/sun/corba/se/rmi/Makefile - make/com/sun/corba/se/rmi/rmic/Makefile - make/com/sun/corba/se/rmi/rmic/SUN_RMI_RMIC_IIOP_java.gmk - make/com/sun/corba/se/sources/Makefile - make/com/sun/corba/se/spi/Makefile - make/com/sun/corba/se/spi/activation/Makefile - make/com/sun/corba/se/spi/copyobject/Makefile - make/com/sun/corba/se/spi/encoding/Makefile - make/com/sun/corba/se/spi/extension/Makefile - make/com/sun/corba/se/spi/legacy/Makefile - make/com/sun/corba/se/spi/legacy/connection/Makefile - make/com/sun/corba/se/spi/legacy/interceptor/Makefile - make/com/sun/corba/se/spi/logging/Makefile - make/com/sun/corba/se/spi/monitoring/Makefile - make/common/BuildToolJar.gmk - make/common/CancelImplicits.gmk - make/common/Classes.gmk - make/common/Defs-bsd.gmk - make/common/Defs-linux.gmk - make/common/Defs-solaris.gmk - make/common/Defs-windows.gmk - make/common/Defs.gmk - make/common/Rules.gmk - make/common/internal/Resources.gmk - make/common/shared/Defs-bsd.gmk - make/common/shared/Defs-java.gmk - make/common/shared/Defs-linux.gmk - make/common/shared/Defs-solaris.gmk - make/common/shared/Defs-utils.gmk - make/common/shared/Defs-windows.gmk - make/common/shared/Defs.gmk - make/common/shared/Platform.gmk - make/javax/Makefile - make/javax/xa/Makefile - make/jprt.properties - make/org/Makefile - make/org/omg/CORBA/Makefile - make/org/omg/CORBAX_java.gmk - make/org/omg/CosNaming/Makefile - make/org/omg/DynamicAny/Makefile - make/org/omg/Makefile - make/org/omg/PortableInterceptor/Makefile - make/org/omg/PortableServer/Makefile - make/org/omg/idl/FILES_java.gmk - make/org/omg/idl/Makefile - make/org/omg/sources/Makefile - make/sun/Makefile - make/sun/corba/Makefile - make/sun/corba/core/Makefile - make/sun/corba/org/Makefile - make/sun/corba/org/omg/FILES_java.gmk - make/sun/corba/org/omg/Makefile - make/sun/rmi/Makefile - make/sun/rmi/corbalogcompile/Makefile - make/sun/rmi/corbalogsources/Makefile - make/sun/rmi/rmic/FILES.gmk - make/sun/rmi/rmic/Makefile - make/tools/Makefile - make/tools/idlj/Makefile - make/tools/logutil/Makefile - make/tools/strip_properties/Makefile - makefiles/BuildCorba.gmk - makefiles/Makefile From magnus.ihse.bursie at oracle.com Mon Nov 18 17:55:06 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:55:06 +0000 Subject: hg: jdk8/tl/jdk: 8027566: Remove the old build system Message-ID: <20131118175522.0FECE62671@hg.openjdk.java.net> Changeset: 4be14673b9bf Author: ihse Date: 2013-11-14 11:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4be14673b9bf 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildJdk.gmk + make/Bundles.gmk + make/CompileDemos.gmk + make/CompileJavaClasses.gmk + make/CompileLaunchers.gmk + make/CompileNativeLibraries.gmk + make/CopyFiles.gmk + make/CopyIntoClasses.gmk + make/CopySamples.gmk + make/CreateJars.gmk + make/CreateSecurityJars.gmk + make/GenerateClasses.gmk + make/GenerateData.gmk + make/GenerateSources.gmk + make/Images.gmk + make/Import.gmk ! make/Makefile - make/PatchList.solaris + make/ProfileNames.gmk + make/Profiles.gmk + make/Setup.gmk + make/SignJars.gmk + make/Tools.gmk - make/altclasses/Makefile - make/apple/Makefile - make/apple/applescript/Makefile - make/bridge/AccessBridgeJava/Makefile - make/bridge/JAWTAccessBridge/Files_cpp.gmk - make/bridge/JAWTAccessBridge/Makefile - make/bridge/Jabswitch/Makefile - make/bridge/Jaccess/Makefile - make/bridge/JavaAccessBridge/Files_cpp.gmk - make/bridge/JavaAccessBridge/Makefile - make/bridge/Makefile - make/bridge/WindowsAccessBridge/Files_cpp.gmk - make/bridge/WindowsAccessBridge/Makefile - make/com/Makefile - make/com/apple/Makefile - make/com/apple/osx/Makefile - make/com/apple/osxui/Makefile - make/com/oracle/Makefile - make/com/oracle/jfr/Makefile - make/com/oracle/net/Makefile - make/com/oracle/nio/Makefile - make/com/oracle/security/ucrypto/FILES_c.gmk - make/com/oracle/security/ucrypto/Makefile - make/com/oracle/security/ucrypto/mapfile-vers - make/com/oracle/util/Makefile - make/com/sun/Makefile - make/com/sun/crypto/provider/Makefile - make/com/sun/demo/Makefile - make/com/sun/demo/jvmti/Makefile - make/com/sun/demo/jvmti/hprof/Makefile - make/com/sun/image/Makefile - make/com/sun/jarsigner/Makefile - make/com/sun/java/Makefile - make/com/sun/java/browser/Makefile - make/com/sun/java/browser/dom/Makefile - make/com/sun/java/browser/net/Makefile - make/com/sun/java/pack/FILES_cpp.gmk - make/com/sun/java/pack/Makefile - make/com/sun/java/pack/mapfile-vers - make/com/sun/java/pack/mapfile-vers-unpack200 - make/com/sun/java/pack/prop/Makefile - make/com/sun/jmx/Makefile - make/com/sun/jmx/snmp/Makefile - make/com/sun/jndi/Makefile - make/com/sun/jndi/cosnaming/Makefile - make/com/sun/jndi/dns/Makefile - make/com/sun/jndi/ldap/Makefile - make/com/sun/jndi/rmi/Makefile - make/com/sun/jndi/rmi/registry/Makefile - make/com/sun/jndi/toolkit/Makefile - make/com/sun/net/httpserver/Makefile - make/com/sun/net/ssl/Makefile - make/com/sun/nio/Makefile - make/com/sun/nio/sctp/Exportedfiles.gmk - make/com/sun/nio/sctp/FILES_c.gmk - make/com/sun/nio/sctp/FILES_java.gmk - make/com/sun/nio/sctp/Makefile - make/com/sun/nio/sctp/mapfile-vers - make/com/sun/org/Makefile - make/com/sun/org/apache/Makefile - make/com/sun/org/apache/xml/Makefile - make/com/sun/rowset/Makefile - make/com/sun/security/Makefile - make/com/sun/security/auth/FILES_java.gmk - make/com/sun/security/auth/Makefile - make/com/sun/security/auth/module/FILES_c_solaris.gmk - make/com/sun/security/auth/module/FILES_c_unix.gmk - make/com/sun/security/auth/module/FILES_c_windows.gmk - make/com/sun/security/auth/module/FILES_export_solaris.gmk - make/com/sun/security/auth/module/FILES_export_unix.gmk - make/com/sun/security/auth/module/FILES_export_windows.gmk - make/com/sun/security/auth/module/FILES_java.gmk - make/com/sun/security/auth/module/Makefile - make/com/sun/security/auth/module/mapfile-vers - make/com/sun/security/jgss/Makefile - make/com/sun/security/ntlm/Makefile - make/com/sun/security/sasl/Makefile - make/com/sun/sql/FILES_java.gmk - make/com/sun/sql/Makefile - make/com/sun/tools/Makefile - make/com/sun/tools/attach/Exportedfiles.gmk - make/com/sun/tools/attach/FILES_c.gmk - make/com/sun/tools/attach/FILES_java.gmk - make/com/sun/tools/attach/Makefile - make/com/sun/tools/attach/mapfile-bsd - make/com/sun/tools/attach/mapfile-linux - make/com/sun/tools/attach/mapfile-solaris - make/com/sun/tracing/Makefile - make/com/sun/tracing/dtrace/Makefile - make/common/BuildToolJar.gmk - make/common/CancelImplicits.gmk - make/common/Classes.gmk - make/common/Cscope.gmk - make/common/Defs-linux.gmk - make/common/Defs-macosx.gmk - make/common/Defs-solaris.gmk - make/common/Defs-windows.gmk - make/common/Defs.gmk - make/common/Demo.gmk - make/common/Library.gmk - make/common/Mapfile-vers.gmk - make/common/Program.gmk - make/common/Release-macosx.gmk - make/common/Release.gmk - make/common/Rules.gmk - make/common/Sanity.gmk - make/common/Subdirs.gmk - make/common/internal/Defs-corba.gmk - make/common/internal/Defs-jaxp.gmk - make/common/internal/Defs-jaxws.gmk - make/common/internal/Defs-langtools.gmk - make/common/internal/ImportComponents.gmk - make/common/internal/NativeCompileRules.gmk - make/common/internal/Resources.gmk - make/common/shared/Compiler-gcc.gmk - make/common/shared/Compiler-llvm.gmk - make/common/shared/Compiler-msvc.gmk - make/common/shared/Compiler-sun.gmk - make/common/shared/Defs-control.gmk - make/common/shared/Defs-java.gmk - make/common/shared/Defs-javadoc.gmk - make/common/shared/Defs-linux.gmk - make/common/shared/Defs-macosx.gmk - make/common/shared/Defs-solaris.gmk - make/common/shared/Defs-utils.gmk - make/common/shared/Defs-versions.gmk - make/common/shared/Defs-windows.gmk - make/common/shared/Defs.gmk - make/common/shared/Platform.gmk - make/common/shared/PrivateDefs.gmk-example - make/common/shared/Sanity-Settings.gmk - make/common/shared/Sanity.gmk + make/data/characterdata/CharacterData00.java.template + make/data/characterdata/CharacterData01.java.template + make/data/characterdata/CharacterData02.java.template + make/data/characterdata/CharacterData0E.java.template + make/data/characterdata/CharacterDataLatin1.java.template + make/data/characterdata/CharacterDataPrivateUse.java.template + make/data/characterdata/CharacterDataUndefined.java.template + make/data/charsetmapping/Big5.map + make/data/charsetmapping/Big5.nr + make/data/charsetmapping/DoubleByte-X.java.template + make/data/charsetmapping/EUC_CN.map + make/data/charsetmapping/EUC_KR.map + make/data/charsetmapping/GBK.map + make/data/charsetmapping/HKSCS2001.c2b + make/data/charsetmapping/HKSCS2001.map + make/data/charsetmapping/HKSCS2008.c2b + make/data/charsetmapping/HKSCS2008.map + make/data/charsetmapping/HKSCS_XP.c2b + make/data/charsetmapping/HKSCS_XP.map + make/data/charsetmapping/IBM037.c2b + make/data/charsetmapping/IBM037.map + make/data/charsetmapping/IBM037.nr + make/data/charsetmapping/IBM1006.map + make/data/charsetmapping/IBM1025.c2b + make/data/charsetmapping/IBM1025.map + make/data/charsetmapping/IBM1025.nr + make/data/charsetmapping/IBM1026.c2b + make/data/charsetmapping/IBM1026.map + make/data/charsetmapping/IBM1026.nr + make/data/charsetmapping/IBM1046.map + make/data/charsetmapping/IBM1047.map + make/data/charsetmapping/IBM1097.map + make/data/charsetmapping/IBM1098.map + make/data/charsetmapping/IBM1112.c2b + make/data/charsetmapping/IBM1112.map + make/data/charsetmapping/IBM1112.nr + make/data/charsetmapping/IBM1122.c2b + make/data/charsetmapping/IBM1122.map + make/data/charsetmapping/IBM1122.nr + make/data/charsetmapping/IBM1123.c2b + make/data/charsetmapping/IBM1123.map + make/data/charsetmapping/IBM1123.nr + make/data/charsetmapping/IBM1124.map + make/data/charsetmapping/IBM1140.c2b + make/data/charsetmapping/IBM1140.map + make/data/charsetmapping/IBM1141.c2b + make/data/charsetmapping/IBM1141.map + make/data/charsetmapping/IBM1142.c2b + make/data/charsetmapping/IBM1142.map + make/data/charsetmapping/IBM1143.c2b + make/data/charsetmapping/IBM1143.map + make/data/charsetmapping/IBM1144.c2b + make/data/charsetmapping/IBM1144.map + make/data/charsetmapping/IBM1145.c2b + make/data/charsetmapping/IBM1145.map + make/data/charsetmapping/IBM1146.c2b + make/data/charsetmapping/IBM1146.map + make/data/charsetmapping/IBM1147.c2b + make/data/charsetmapping/IBM1147.map + make/data/charsetmapping/IBM1148.c2b + make/data/charsetmapping/IBM1148.map + make/data/charsetmapping/IBM1149.c2b + make/data/charsetmapping/IBM1149.map + make/data/charsetmapping/IBM1364.c2b + make/data/charsetmapping/IBM1364.map + make/data/charsetmapping/IBM1381.c2b + make/data/charsetmapping/IBM1381.map + make/data/charsetmapping/IBM1383.c2b + make/data/charsetmapping/IBM1383.map + make/data/charsetmapping/IBM1383.nr + make/data/charsetmapping/IBM273.c2b + make/data/charsetmapping/IBM273.map + make/data/charsetmapping/IBM273.nr + make/data/charsetmapping/IBM277.c2b + make/data/charsetmapping/IBM277.map + make/data/charsetmapping/IBM277.nr + make/data/charsetmapping/IBM278.c2b + make/data/charsetmapping/IBM278.map + make/data/charsetmapping/IBM278.nr + make/data/charsetmapping/IBM280.c2b + make/data/charsetmapping/IBM280.map + make/data/charsetmapping/IBM280.nr + make/data/charsetmapping/IBM284.c2b + make/data/charsetmapping/IBM284.map + make/data/charsetmapping/IBM284.nr + make/data/charsetmapping/IBM285.c2b + make/data/charsetmapping/IBM285.map + make/data/charsetmapping/IBM285.nr + make/data/charsetmapping/IBM290.c2b + make/data/charsetmapping/IBM290.map + make/data/charsetmapping/IBM297.c2b + make/data/charsetmapping/IBM297.map + make/data/charsetmapping/IBM297.nr + make/data/charsetmapping/IBM300.c2b + make/data/charsetmapping/IBM300.map + make/data/charsetmapping/IBM420.c2b + make/data/charsetmapping/IBM420.map + make/data/charsetmapping/IBM420.nr + make/data/charsetmapping/IBM424.c2b + make/data/charsetmapping/IBM424.map + make/data/charsetmapping/IBM424.nr + make/data/charsetmapping/IBM437.map + make/data/charsetmapping/IBM500.c2b + make/data/charsetmapping/IBM500.map + make/data/charsetmapping/IBM500.nr + make/data/charsetmapping/IBM737.map + make/data/charsetmapping/IBM775.map + make/data/charsetmapping/IBM833.c2b + make/data/charsetmapping/IBM833.map + make/data/charsetmapping/IBM838.c2b + make/data/charsetmapping/IBM838.map + make/data/charsetmapping/IBM838.nr + make/data/charsetmapping/IBM850.map + make/data/charsetmapping/IBM852.map + make/data/charsetmapping/IBM855.map + make/data/charsetmapping/IBM856.map + make/data/charsetmapping/IBM857.map + make/data/charsetmapping/IBM858.map + make/data/charsetmapping/IBM860.map + make/data/charsetmapping/IBM861.map + make/data/charsetmapping/IBM862.map + make/data/charsetmapping/IBM863.map + make/data/charsetmapping/IBM864.map + make/data/charsetmapping/IBM865.map + make/data/charsetmapping/IBM866.map + make/data/charsetmapping/IBM868.map + make/data/charsetmapping/IBM869.map + make/data/charsetmapping/IBM870.c2b + make/data/charsetmapping/IBM870.map + make/data/charsetmapping/IBM870.nr + make/data/charsetmapping/IBM871.c2b + make/data/charsetmapping/IBM871.map + make/data/charsetmapping/IBM871.nr + make/data/charsetmapping/IBM874.map + make/data/charsetmapping/IBM874.nr + make/data/charsetmapping/IBM875.c2b + make/data/charsetmapping/IBM875.map + make/data/charsetmapping/IBM875.nr + make/data/charsetmapping/IBM918.c2b + make/data/charsetmapping/IBM918.map + make/data/charsetmapping/IBM918.nr + make/data/charsetmapping/IBM921.map + make/data/charsetmapping/IBM922.map + make/data/charsetmapping/IBM930.c2b + make/data/charsetmapping/IBM930.map + make/data/charsetmapping/IBM930.nr + make/data/charsetmapping/IBM933.c2b + make/data/charsetmapping/IBM933.map + make/data/charsetmapping/IBM935.c2b + make/data/charsetmapping/IBM935.map + make/data/charsetmapping/IBM935.nr + make/data/charsetmapping/IBM937.c2b + make/data/charsetmapping/IBM937.map + make/data/charsetmapping/IBM937.nr + make/data/charsetmapping/IBM939.c2b + make/data/charsetmapping/IBM939.map + make/data/charsetmapping/IBM939.nr + make/data/charsetmapping/IBM942.c2b + make/data/charsetmapping/IBM942.map + make/data/charsetmapping/IBM943.map + make/data/charsetmapping/IBM943.nr + make/data/charsetmapping/IBM948.c2b + make/data/charsetmapping/IBM948.map + make/data/charsetmapping/IBM949.map + make/data/charsetmapping/IBM950.c2b + make/data/charsetmapping/IBM950.map + make/data/charsetmapping/IBM970.c2b + make/data/charsetmapping/IBM970.map + make/data/charsetmapping/ISO_8859_11.map + make/data/charsetmapping/ISO_8859_13.map + make/data/charsetmapping/ISO_8859_15.map + make/data/charsetmapping/ISO_8859_2.map + make/data/charsetmapping/ISO_8859_3.map + make/data/charsetmapping/ISO_8859_4.map + make/data/charsetmapping/ISO_8859_5.map + make/data/charsetmapping/ISO_8859_6.map + make/data/charsetmapping/ISO_8859_7.map + make/data/charsetmapping/ISO_8859_8.map + make/data/charsetmapping/ISO_8859_9.map + make/data/charsetmapping/JIS_X_0201.c2b + make/data/charsetmapping/JIS_X_0201.map + make/data/charsetmapping/JIS_X_0208.map + make/data/charsetmapping/JIS_X_0208_MS5022X.c2b + make/data/charsetmapping/JIS_X_0208_MS5022X.map + make/data/charsetmapping/JIS_X_0208_MS932.map + make/data/charsetmapping/JIS_X_0208_MS932.nr + make/data/charsetmapping/JIS_X_0208_Solaris.map + make/data/charsetmapping/JIS_X_0208_Solaris.nr + make/data/charsetmapping/JIS_X_0212.map + make/data/charsetmapping/JIS_X_0212_MS5022X.map + make/data/charsetmapping/JIS_X_0212_Solaris.map + make/data/charsetmapping/JIS_X_0212_Solaris.nr + make/data/charsetmapping/Johab.map + make/data/charsetmapping/KOI8_R.map + make/data/charsetmapping/KOI8_U.map + make/data/charsetmapping/MS1250.map + make/data/charsetmapping/MS1251.map + make/data/charsetmapping/MS1252.map + make/data/charsetmapping/MS1253.map + make/data/charsetmapping/MS1254.map + make/data/charsetmapping/MS1255.map + make/data/charsetmapping/MS1256.map + make/data/charsetmapping/MS1257.map + make/data/charsetmapping/MS1258.map + make/data/charsetmapping/MS874.map + make/data/charsetmapping/MS932.c2b + make/data/charsetmapping/MS932.map + make/data/charsetmapping/MS932.nr + make/data/charsetmapping/MS936.map + make/data/charsetmapping/MS949.map + make/data/charsetmapping/MS950.map + make/data/charsetmapping/MS950.nr + make/data/charsetmapping/MacArabic.map + make/data/charsetmapping/MacCentralEurope.map + make/data/charsetmapping/MacCroatian.map + make/data/charsetmapping/MacCyrillic.map + make/data/charsetmapping/MacDingbat.map + make/data/charsetmapping/MacGreek.map + make/data/charsetmapping/MacHebrew.map + make/data/charsetmapping/MacIceland.map + make/data/charsetmapping/MacRoman.map + make/data/charsetmapping/MacRomania.map + make/data/charsetmapping/MacSymbol.map + make/data/charsetmapping/MacThai.map + make/data/charsetmapping/MacTurkish.map + make/data/charsetmapping/MacUkraine.map + make/data/charsetmapping/PCK.c2b + make/data/charsetmapping/PCK.map + make/data/charsetmapping/PCK.nr + make/data/charsetmapping/SJIS.c2b + make/data/charsetmapping/SJIS.map + make/data/charsetmapping/SingleByte-X.java.template + make/data/charsetmapping/TIS_620.map + make/data/charsetmapping/dbcs + make/data/charsetmapping/euc_tw.map + make/data/charsetmapping/extsbcs + make/data/charsetmapping/sbcs + make/data/charsetmapping/sjis0213.map + make/data/checkdeps/refs.allowed + make/data/classlist/classlist.linux + make/data/classlist/classlist.macosx + make/data/classlist/classlist.solaris + make/data/classlist/classlist.windows + make/data/cryptopolicy/limited/LIMITED + make/data/cryptopolicy/limited/default_local.policy + make/data/cryptopolicy/limited/exempt_local.policy + make/data/cryptopolicy/unlimited/UNLIMITED + make/data/cryptopolicy/unlimited/default_US_export.policy + make/data/cryptopolicy/unlimited/default_local.policy + make/data/dtdbuilder/HTMLlat1.sgml + make/data/dtdbuilder/HTMLspecial.sgml + make/data/dtdbuilder/HTMLsymbol.sgml + make/data/dtdbuilder/html32.dtd + make/data/dtdbuilder/public.map + make/data/jdwp/jdwp.spec + make/data/mainmanifest/manifest.mf + make/data/swingbeaninfo/SwingBeanInfo.template + make/data/swingbeaninfo/images/AbstractButtonColor16.gif + make/data/swingbeaninfo/images/BorderColor16.gif + make/data/swingbeaninfo/images/BoxColor16.gif + make/data/swingbeaninfo/images/BoxColor32.gif + make/data/swingbeaninfo/images/BoxMono16.gif + make/data/swingbeaninfo/images/BoxMono32.gif + make/data/swingbeaninfo/images/JAppletColor16.gif + make/data/swingbeaninfo/images/JAppletColor32.gif + make/data/swingbeaninfo/images/JAppletMono16.gif + make/data/swingbeaninfo/images/JAppletMono32.gif + make/data/swingbeaninfo/images/JButtonColor16.gif + make/data/swingbeaninfo/images/JButtonColor32.gif + make/data/swingbeaninfo/images/JButtonMono16.gif + make/data/swingbeaninfo/images/JButtonMono32.gif + make/data/swingbeaninfo/images/JCheckBoxColor16.gif + make/data/swingbeaninfo/images/JCheckBoxColor32.gif + make/data/swingbeaninfo/images/JCheckBoxMenuItemColor16.gif + make/data/swingbeaninfo/images/JCheckBoxMenuItemColor32.gif + make/data/swingbeaninfo/images/JCheckBoxMenuItemMono16.gif + make/data/swingbeaninfo/images/JCheckBoxMenuItemMono32.gif + make/data/swingbeaninfo/images/JCheckBoxMono16.gif + make/data/swingbeaninfo/images/JCheckBoxMono32.gif + make/data/swingbeaninfo/images/JColorChooserColor16.gif + make/data/swingbeaninfo/images/JColorChooserColor32.gif + make/data/swingbeaninfo/images/JColorChooserMono16.gif + make/data/swingbeaninfo/images/JColorChooserMono32.gif + make/data/swingbeaninfo/images/JComboBoxColor16.gif + make/data/swingbeaninfo/images/JComboBoxColor32.gif + make/data/swingbeaninfo/images/JComboBoxMono16.gif + make/data/swingbeaninfo/images/JComboBoxMono32.gif + make/data/swingbeaninfo/images/JComponentColor16.gif + make/data/swingbeaninfo/images/JDesktopPaneColor16.gif + make/data/swingbeaninfo/images/JDesktopPaneColor32.gif + make/data/swingbeaninfo/images/JDesktopPaneMono16.gif + make/data/swingbeaninfo/images/JDesktopPaneMono32.gif + make/data/swingbeaninfo/images/JDialogColor16.gif + make/data/swingbeaninfo/images/JDialogColor32.gif + make/data/swingbeaninfo/images/JDialogMono16.gif + make/data/swingbeaninfo/images/JDialogMono32.gif + make/data/swingbeaninfo/images/JEditorPaneColor16.gif + make/data/swingbeaninfo/images/JEditorPaneColor32.gif + make/data/swingbeaninfo/images/JEditorPaneMono16.gif + make/data/swingbeaninfo/images/JEditorPaneMono32.gif + make/data/swingbeaninfo/images/JFileChooserColor16.gif + make/data/swingbeaninfo/images/JFileChooserColor32.gif + make/data/swingbeaninfo/images/JFileChooserMono16.gif + make/data/swingbeaninfo/images/JFileChooserMono32.gif + make/data/swingbeaninfo/images/JFormattedTextFieldColor16.gif + make/data/swingbeaninfo/images/JFormattedTextFieldColor32.gif + make/data/swingbeaninfo/images/JFormattedTextFieldMono16.gif + make/data/swingbeaninfo/images/JFormattedTextFieldMono32.gif + make/data/swingbeaninfo/images/JFrameColor16.gif + make/data/swingbeaninfo/images/JFrameColor32.gif + make/data/swingbeaninfo/images/JFrameMono16.gif + make/data/swingbeaninfo/images/JFrameMono32.gif + make/data/swingbeaninfo/images/JInternalFrameColor16.gif + make/data/swingbeaninfo/images/JInternalFrameColor32.gif + make/data/swingbeaninfo/images/JInternalFrameMono16.gif + make/data/swingbeaninfo/images/JInternalFrameMono32.gif + make/data/swingbeaninfo/images/JLabelColor16.gif + make/data/swingbeaninfo/images/JLabelColor32.gif + make/data/swingbeaninfo/images/JLabelMono16.gif + make/data/swingbeaninfo/images/JLabelMono32.gif + make/data/swingbeaninfo/images/JLayeredPaneColor16.gif + make/data/swingbeaninfo/images/JLayeredPaneColor32.gif + make/data/swingbeaninfo/images/JLayeredPaneMono16.gif + make/data/swingbeaninfo/images/JLayeredPaneMono32.gif + make/data/swingbeaninfo/images/JListColor16.gif + make/data/swingbeaninfo/images/JListColor32.gif + make/data/swingbeaninfo/images/JListMono16.gif + make/data/swingbeaninfo/images/JListMono32.gif + make/data/swingbeaninfo/images/JMenuBarColor16.gif + make/data/swingbeaninfo/images/JMenuBarColor32.gif + make/data/swingbeaninfo/images/JMenuBarMono16.gif + make/data/swingbeaninfo/images/JMenuBarMono32.gif + make/data/swingbeaninfo/images/JMenuColor16.gif + make/data/swingbeaninfo/images/JMenuColor32.gif + make/data/swingbeaninfo/images/JMenuItemColor16.gif + make/data/swingbeaninfo/images/JMenuItemColor32.gif + make/data/swingbeaninfo/images/JMenuItemMono16.gif + make/data/swingbeaninfo/images/JMenuItemMono32.gif + make/data/swingbeaninfo/images/JMenuMono16.gif + make/data/swingbeaninfo/images/JMenuMono32.gif + make/data/swingbeaninfo/images/JOptionPaneColor16.gif + make/data/swingbeaninfo/images/JOptionPaneColor32.gif + make/data/swingbeaninfo/images/JOptionPaneMono16.gif + make/data/swingbeaninfo/images/JOptionPaneMono32.gif + make/data/swingbeaninfo/images/JPanelColor16.gif + make/data/swingbeaninfo/images/JPanelColor32.gif + make/data/swingbeaninfo/images/JPanelMono16.gif + make/data/swingbeaninfo/images/JPanelMono32.gif + make/data/swingbeaninfo/images/JPasswordFieldColor16.gif + make/data/swingbeaninfo/images/JPasswordFieldColor32.gif + make/data/swingbeaninfo/images/JPasswordFieldMono16.gif + make/data/swingbeaninfo/images/JPasswordFieldMono32.gif + make/data/swingbeaninfo/images/JPopupMenuColor16.gif + make/data/swingbeaninfo/images/JPopupMenuColor32.gif + make/data/swingbeaninfo/images/JPopupMenuMono16.gif + make/data/swingbeaninfo/images/JPopupMenuMono32.gif + make/data/swingbeaninfo/images/JProgressBarColor16.gif + make/data/swingbeaninfo/images/JProgressBarColor32.gif + make/data/swingbeaninfo/images/JProgressBarMono16.gif + make/data/swingbeaninfo/images/JProgressBarMono32.gif + make/data/swingbeaninfo/images/JRadioButtonColor16.gif + make/data/swingbeaninfo/images/JRadioButtonColor32.gif + make/data/swingbeaninfo/images/JRadioButtonMenuItemColor16.gif + make/data/swingbeaninfo/images/JRadioButtonMenuItemColor32.gif + make/data/swingbeaninfo/images/JRadioButtonMenuItemMono16.gif + make/data/swingbeaninfo/images/JRadioButtonMenuItemMono32.gif + make/data/swingbeaninfo/images/JRadioButtonMono16.gif + make/data/swingbeaninfo/images/JRadioButtonMono32.gif + make/data/swingbeaninfo/images/JRootPaneColor16.gif + make/data/swingbeaninfo/images/JRootPaneColor32.gif + make/data/swingbeaninfo/images/JRootPaneMono16.gif + make/data/swingbeaninfo/images/JRootPaneMono32.gif + make/data/swingbeaninfo/images/JScrollBarColor16.gif + make/data/swingbeaninfo/images/JScrollBarColor32.gif + make/data/swingbeaninfo/images/JScrollBarMono16.gif + make/data/swingbeaninfo/images/JScrollBarMono32.gif + make/data/swingbeaninfo/images/JScrollPaneColor16.gif + make/data/swingbeaninfo/images/JScrollPaneColor32.gif + make/data/swingbeaninfo/images/JScrollPaneMono16.gif + make/data/swingbeaninfo/images/JScrollPaneMono32.gif + make/data/swingbeaninfo/images/JSeparatorColor16.gif + make/data/swingbeaninfo/images/JSeparatorColor32.gif + make/data/swingbeaninfo/images/JSeparatorMono16.gif + make/data/swingbeaninfo/images/JSeparatorMono32.gif + make/data/swingbeaninfo/images/JSliderColor16.gif + make/data/swingbeaninfo/images/JSliderColor32.gif + make/data/swingbeaninfo/images/JSliderMono16.gif + make/data/swingbeaninfo/images/JSliderMono32.gif + make/data/swingbeaninfo/images/JSpinnerColor16.gif + make/data/swingbeaninfo/images/JSpinnerColor32.gif + make/data/swingbeaninfo/images/JSpinnerMono16.gif + make/data/swingbeaninfo/images/JSpinnerMono32.gif + make/data/swingbeaninfo/images/JSplitPaneColor16.gif + make/data/swingbeaninfo/images/JSplitPaneColor32.gif + make/data/swingbeaninfo/images/JSplitPaneMono16.gif + make/data/swingbeaninfo/images/JSplitPaneMono32.gif + make/data/swingbeaninfo/images/JTabbedPaneColor16.gif + make/data/swingbeaninfo/images/JTabbedPaneColor32.gif + make/data/swingbeaninfo/images/JTabbedPaneMono16.gif + make/data/swingbeaninfo/images/JTabbedPaneMono32.gif + make/data/swingbeaninfo/images/JTableColor16.gif + make/data/swingbeaninfo/images/JTableColor32.gif + make/data/swingbeaninfo/images/JTableMono16.gif + make/data/swingbeaninfo/images/JTableMono32.gif + make/data/swingbeaninfo/images/JTextAreaColor16.gif + make/data/swingbeaninfo/images/JTextAreaColor32.gif + make/data/swingbeaninfo/images/JTextAreaMono16.gif + make/data/swingbeaninfo/images/JTextAreaMono32.gif + make/data/swingbeaninfo/images/JTextFieldColor16.gif + make/data/swingbeaninfo/images/JTextFieldColor32.gif + make/data/swingbeaninfo/images/JTextFieldMono16.gif + make/data/swingbeaninfo/images/JTextFieldMono32.gif + make/data/swingbeaninfo/images/JTextPaneColor16.gif + make/data/swingbeaninfo/images/JTextPaneColor32.gif + make/data/swingbeaninfo/images/JTextPaneMono16.gif + make/data/swingbeaninfo/images/JTextPaneMono32.gif + make/data/swingbeaninfo/images/JToggleButtonColor16.gif + make/data/swingbeaninfo/images/JToggleButtonColor32.gif + make/data/swingbeaninfo/images/JToggleButtonMono16.gif + make/data/swingbeaninfo/images/JToggleButtonMono32.gif + make/data/swingbeaninfo/images/JToolBarColor16.gif + make/data/swingbeaninfo/images/JToolBarColor32.gif + make/data/swingbeaninfo/images/JToolBarMono16.gif + make/data/swingbeaninfo/images/JToolBarMono32.gif + make/data/swingbeaninfo/images/JTreeColor16.gif + make/data/swingbeaninfo/images/JTreeColor32.gif + make/data/swingbeaninfo/images/JTreeMono16.gif + make/data/swingbeaninfo/images/JTreeMono32.gif + make/data/swingbeaninfo/images/JViewportColor16.gif + make/data/swingbeaninfo/images/JViewportColor32.gif + make/data/swingbeaninfo/images/JViewportMono16.gif + make/data/swingbeaninfo/images/JViewportMono32.gif + make/data/swingbeaninfo/images/JWindowColor16.gif + make/data/swingbeaninfo/images/JWindowColor32.gif + make/data/swingbeaninfo/images/JWindowMono16.gif + make/data/swingbeaninfo/images/JWindowMono32.gif + make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java + make/data/swingbeaninfo/manifest.mf + make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java + make/data/tzdata/VERSION + make/data/tzdata/africa + make/data/tzdata/antarctica + make/data/tzdata/asia + make/data/tzdata/australasia + make/data/tzdata/backward + make/data/tzdata/etcetera + make/data/tzdata/europe + make/data/tzdata/factory + make/data/tzdata/gmt + make/data/tzdata/iso3166.tab + make/data/tzdata/jdk11_backward + make/data/tzdata/leapseconds + make/data/tzdata/northamerica + make/data/tzdata/pacificnew + make/data/tzdata/solar87 + make/data/tzdata/solar88 + make/data/tzdata/solar89 + make/data/tzdata/southamerica + make/data/tzdata/systemv + make/data/tzdata/zone.tab + make/data/unicodedata/PropList.txt + make/data/unicodedata/Scripts.txt + make/data/unicodedata/SpecialCasing.txt + make/data/unicodedata/UnicodeData.txt + make/data/unicodedata/VERSION - make/docs/CORE_PKGS.gmk - make/docs/Makefile - make/docs/NON_CORE_PKGS.gmk - make/docs/Notes.html + make/gendata/GendataBreakIterator.gmk + make/gendata/GendataFontConfig.gmk + make/gendata/GendataHtml32dtd.gmk + make/gendata/GendataTZDB.gmk + make/gensrc/GensrcBuffer.gmk + make/gensrc/GensrcCLDR.gmk + make/gensrc/GensrcCharacterData.gmk + make/gensrc/GensrcCharsetCoder.gmk + make/gensrc/GensrcCharsetMapping.gmk + make/gensrc/GensrcExceptions.gmk + make/gensrc/GensrcIcons.gmk + make/gensrc/GensrcJDWP.gmk + make/gensrc/GensrcJObjC.gmk + make/gensrc/GensrcLocaleDataMetaInfo.gmk + make/gensrc/GensrcMisc.gmk + make/gensrc/GensrcProperties.gmk + make/gensrc/GensrcSwing.gmk + make/gensrc/GensrcX11Wrappers.gmk - make/java/Makefile - make/java/applet/Makefile - make/java/awt/Makefile - make/java/beans/Makefile - make/java/fdlibm/FILES_c.gmk - make/java/fdlibm/Makefile - make/java/instrument/Makefile - make/java/instrument/mapfile-vers - make/java/invoke/Makefile - make/java/jar/Makefile - make/java/java/Exportedfiles.gmk - make/java/java/FILES_c.gmk - make/java/java/FILES_java.gmk - make/java/java/Makefile - make/java/java/genlocales.gmk - make/java/java/localegen.sh - make/java/java/localelist.sh - make/java/java/mapfile-vers - make/java/java/reflect/Makefile - make/java/java/reorder-i586 - make/java/java/reorder-sparc - make/java/java/reorder-sparcv9 - make/java/java_crw_demo/Makefile - make/java/java_crw_demo/mapfile-vers - make/java/java_hprof_demo/Makefile - make/java/java_hprof_demo/mapfile-vers - make/java/jexec/Makefile - make/java/jli/Makefile - make/java/jli/mapfile-vers - make/java/jobjc/Makefile - make/java/jvm/Makefile - make/java/logging/Makefile - make/java/main/Makefile - make/java/main/java/Makefile - make/java/main/java/mapfile-amd64 - make/java/main/java/mapfile-i586 - make/java/main/java/mapfile-sparc - make/java/main/java/mapfile-sparcv9 - make/java/main/javaw/Makefile - make/java/management/Exportedfiles.gmk - make/java/management/FILES_c.gmk - make/java/management/Makefile - make/java/management/mapfile-vers - make/java/math/Makefile - make/java/net/FILES_c.gmk - make/java/net/Makefile - make/java/net/mapfile-vers - make/java/nio/Exportedfiles.gmk - make/java/nio/FILES_c.gmk - make/java/nio/FILES_java.gmk - make/java/nio/Makefile - make/java/nio/addNotices.sh - make/java/nio/genBuffer.sh - make/java/nio/genCharsetProvider.sh - make/java/nio/genCoder.sh - make/java/nio/genExceptions.sh - make/java/nio/mapfile-bsd - make/java/nio/mapfile-linux - make/java/nio/mapfile-solaris - make/java/nio/reorder-i586 - make/java/nio/reorder-sparc - make/java/nio/reorder-sparcv9 - make/java/npt/Makefile - make/java/npt/mapfile-vers - make/java/redist/Makefile - make/java/redist/fonts/Makefile - make/java/redist/sajdi/Makefile - make/java/rmi/Makefile - make/java/security/Makefile - make/java/sql/Makefile - make/java/sun_nio/FILES_java.gmk - make/java/sun_nio/Makefile - make/java/text/Makefile - make/java/text/base/FILES_java.gmk - make/java/text/base/Makefile - make/java/text/bidi/Makefile - make/java/time/Makefile - make/java/util/FILES_java.gmk - make/java/util/FILES_properties.gmk - make/java/util/Makefile - make/java/verify/Makefile - make/java/verify/mapfile-vers - make/java/verify/reorder-i586 - make/java/verify/reorder-sparc - make/java/verify/reorder-sparcv9 - make/java/version/Makefile - make/java/zip/FILES_c.gmk - make/java/zip/FILES_java.gmk - make/java/zip/Makefile - make/java/zip/mapfile-vers - make/java/zip/reorder-i586 - make/java/zip/reorder-sparc - make/java/zip/reorder-sparcv9 - make/javax/Makefile - make/javax/accessibility/Makefile - make/javax/crypto/Defs-jce.gmk - make/javax/crypto/Makefile - make/javax/crypto/policy/limited/LIMITED - make/javax/crypto/policy/limited/default_local.policy - make/javax/crypto/policy/limited/exempt_local.policy - make/javax/crypto/policy/unlimited/UNLIMITED - make/javax/crypto/policy/unlimited/default_US_export.policy - make/javax/crypto/policy/unlimited/default_local.policy - make/javax/imageio/Makefile - make/javax/management/Makefile - make/javax/others/Makefile - make/javax/print/Makefile - make/javax/rmi/Makefile - make/javax/rmi/ssl/Makefile - make/javax/security/Makefile - make/javax/sound/FILES_c.gmk - make/javax/sound/Makefile - make/javax/sound/SoundDefs.gmk - make/javax/sound/jsoundalsa/Makefile - make/javax/sound/jsoundalsa/mapfile-vers - make/javax/sound/jsoundds/Makefile - make/javax/sound/mapfile-vers - make/javax/sql/Makefile - make/javax/swing/FILES.gmk - make/javax/swing/Makefile - make/javax/swing/beaninfo/FILES.gmk - make/javax/swing/beaninfo/Makefile - make/javax/swing/beaninfo/SwingBeans.gmk - make/javax/swing/beaninfo/manifest - make/javax/swing/html32dtd/Makefile - make/javax/swing/plaf/FILES.gmk - make/javax/swing/plaf/Makefile - make/jdk/Makefile - make/jdk_generic_profile.sh - make/jpda/Makefile - make/jpda/back/Makefile - make/jpda/back/mapfile-vers - make/jpda/bdi/Makefile - make/jpda/expr/Makefile - make/jpda/front/Makefile - make/jpda/gui/Makefile - make/jpda/jdwp/Makefile - make/jpda/jdwp/jdwp.spec - make/jpda/transport/Makefile - make/jpda/transport/shmem/Makefile - make/jpda/transport/shmem/mapfile-vers - make/jpda/transport/socket/Makefile - make/jpda/transport/socket/mapfile-vers - make/jpda/tty/Makefile - make/jprt.gmk - make/jprt.properties - make/launchers/Makefile - make/launchers/Makefile.launcher + make/lib/Awt2dLibraries.gmk + make/lib/CoreLibraries.gmk + make/lib/NetworkingLibraries.gmk + make/lib/NioLibraries.gmk + make/lib/PlatformLibraries.gmk + make/lib/SecurityLibraries.gmk + make/lib/ServiceabilityLibraries.gmk + make/lib/SoundLibraries.gmk + make/mapfiles/launchers/mapfile-sparc + make/mapfiles/launchers/mapfile-sparcv9 + make/mapfiles/launchers/mapfile-x86 + make/mapfiles/launchers/mapfile-x86_64 + make/mapfiles/libattach/mapfile-linux + make/mapfiles/libattach/mapfile-solaris + make/mapfiles/libattach/reorder-windows-x86 + make/mapfiles/libattach/reorder-windows-x86_64 + make/mapfiles/libawt/mapfile-mawt-vers + make/mapfiles/libawt/mapfile-vers + make/mapfiles/libawt/mapfile-vers-linux + make/mapfiles/libawt_headless/mapfile-vers + make/mapfiles/libawt_headless/reorder-sparc + make/mapfiles/libawt_headless/reorder-sparcv9 + make/mapfiles/libawt_headless/reorder-x86 + make/mapfiles/libawt_xawt/mapfile-vers + make/mapfiles/libdcpr/mapfile-vers + make/mapfiles/libdt_socket/mapfile-vers + make/mapfiles/libfontmanager/mapfile-vers + make/mapfiles/libfontmanager/mapfile-vers.openjdk + make/mapfiles/libhprof/mapfile-vers + make/mapfiles/libinstrument/mapfile-vers + make/mapfiles/libj2gss/mapfile-vers + make/mapfiles/libj2pcsc/mapfile-vers + make/mapfiles/libj2pkcs11/mapfile-vers + make/mapfiles/libj2ucrypto/mapfile-vers + make/mapfiles/libjaas/mapfile-vers + make/mapfiles/libjava/mapfile-vers + make/mapfiles/libjava/reorder-sparc + make/mapfiles/libjava/reorder-sparcv9 + make/mapfiles/libjava/reorder-x86 + make/mapfiles/libjava_crw_demo/mapfile-vers + make/mapfiles/libjawt/mapfile-vers + make/mapfiles/libjdga/mapfile-vers + make/mapfiles/libjdwp/mapfile-vers + make/mapfiles/libjfr/mapfile-vers + make/mapfiles/libjli/mapfile-vers + make/mapfiles/libjpeg/mapfile-vers + make/mapfiles/libjpeg/mapfile-vers-closed + make/mapfiles/libjpeg/reorder-sparc + make/mapfiles/libjpeg/reorder-sparcv9 + make/mapfiles/libjpeg/reorder-x86 + make/mapfiles/libjsdt/mapfile-vers + make/mapfiles/libjsound/mapfile-vers + make/mapfiles/libjsoundalsa/mapfile-vers + make/mapfiles/libkcms/mapfile-vers + make/mapfiles/liblcms/mapfile-vers + make/mapfiles/libmanagement/mapfile-vers + make/mapfiles/libmlib_image/mapfile-vers + make/mapfiles/libnet/mapfile-vers + make/mapfiles/libnio/mapfile-linux + make/mapfiles/libnio/mapfile-macosx + make/mapfiles/libnio/mapfile-solaris + make/mapfiles/libnio/reorder-sparc + make/mapfiles/libnio/reorder-sparcv9 + make/mapfiles/libnio/reorder-x86 + make/mapfiles/libnpt/mapfile-vers + make/mapfiles/libsctp/mapfile-vers + make/mapfiles/libsplashscreen/mapfile-vers + make/mapfiles/libsunec/mapfile-vers + make/mapfiles/libt2k/mapfile-vers + make/mapfiles/libunpack/mapfile-vers + make/mapfiles/libunpack/mapfile-vers-unpack200 + make/mapfiles/libverify/mapfile-vers + make/mapfiles/libverify/reorder-sparc + make/mapfiles/libverify/reorder-sparcv9 + make/mapfiles/libverify/reorder-x86 + make/mapfiles/libzip/mapfile-vers + make/mapfiles/libzip/reorder-sparc + make/mapfiles/libzip/reorder-sparcv9 + make/mapfiles/libzip/reorder-x86 - make/mkdemo/Makefile - make/mkdemo/applets/Animator/Makefile - make/mkdemo/applets/ArcTest/Makefile - make/mkdemo/applets/BarChart/Makefile - make/mkdemo/applets/Blink/Makefile - make/mkdemo/applets/CardTest/Makefile - make/mkdemo/applets/Clock/Makefile - make/mkdemo/applets/DitherTest/Makefile - make/mkdemo/applets/DrawTest/Makefile - make/mkdemo/applets/Fractal/Makefile - make/mkdemo/applets/GraphLayout/Makefile - make/mkdemo/applets/GraphicsTest/Makefile - make/mkdemo/applets/JumpingBox/Makefile - make/mkdemo/applets/Makefile - make/mkdemo/applets/MoleculeViewer/Makefile - make/mkdemo/applets/NervousText/Makefile - make/mkdemo/applets/SimpleGraph/Makefile - make/mkdemo/applets/SortDemo/Makefile - make/mkdemo/applets/SpreadSheet/Makefile - make/mkdemo/applets/TicTacToe/Makefile - make/mkdemo/applets/WireFrame/Makefile - make/mkdemo/jfc/CodePointIM/Makefile - make/mkdemo/jfc/FileChooserDemo/Makefile - make/mkdemo/jfc/Font2DTest/Makefile - make/mkdemo/jfc/Java2D/Makefile - make/mkdemo/jfc/Laffy/Makefile - make/mkdemo/jfc/Makefile - make/mkdemo/jfc/Metalworks/Makefile - make/mkdemo/jfc/Notepad/Makefile - make/mkdemo/jfc/SampleTree/Makefile - make/mkdemo/jfc/Stylepad/Makefile - make/mkdemo/jfc/SwingApplet/Makefile - make/mkdemo/jfc/SwingSet2/Makefile - make/mkdemo/jfc/SwingSet3/Makefile - make/mkdemo/jfc/TableExample/Makefile - make/mkdemo/jfc/TransparentRuler/Makefile - make/mkdemo/jni/Makefile - make/mkdemo/jni/Poller/Makefile - make/mkdemo/jpda/Makefile - make/mkdemo/jvmti/Makefile - make/mkdemo/jvmti/README.txt - make/mkdemo/jvmti/compiledMethodLoad/Makefile - make/mkdemo/jvmti/gctest/Makefile - make/mkdemo/jvmti/heapTracker/Makefile - make/mkdemo/jvmti/heapViewer/Makefile - make/mkdemo/jvmti/hprof/Makefile - make/mkdemo/jvmti/mapfile-vers - make/mkdemo/jvmti/minst/Makefile - make/mkdemo/jvmti/mtrace/Makefile - make/mkdemo/jvmti/versionCheck/Makefile - make/mkdemo/jvmti/waiters/Makefile - make/mkdemo/management/FullThreadDump/Makefile - make/mkdemo/management/JTop/Makefile - make/mkdemo/management/Makefile - make/mkdemo/management/MemoryMonitor/Makefile - make/mkdemo/management/README.txt - make/mkdemo/management/VerboseGC/Makefile - make/mkdemo/nio/Makefile - make/mkdemo/nio/zipfs/Makefile - make/mkdemo/scripting/Makefile - make/mkdemo/scripting/jconsole-plugin/Makefile - make/mksample/Makefile - make/mksample/dtrace/Makefile - make/mksample/forkjoin/Makefile - make/mksample/forkjoin/mergesort/Makefile - make/mksample/jmx/Makefile - make/mksample/jmx/jmx-scandir/Makefile - make/mksample/nbproject/Makefile - make/mksample/nio/Makefile - make/mksample/nio/chatserver/Makefile - make/mksample/nio/file/Makefile - make/mksample/nio/multicast/Makefile - make/mksample/nio/server/Makefile - make/mksample/scripting/Makefile - make/mksample/scripting/scriptpad/Makefile - make/mksample/webservices/EbayClient/Makefile - make/mksample/webservices/EbayServer/Makefile - make/mksample/webservices/Makefile ! make/netbeans/jdwpgen/nbproject/project.properties + make/non-build-utils/reorder/Makefile + make/non-build-utils/reorder/tests/Exit.java + make/non-build-utils/reorder/tests/Hello.java + make/non-build-utils/reorder/tests/IntToString.java + make/non-build-utils/reorder/tests/JHello.java + make/non-build-utils/reorder/tests/LoadFrame.java + make/non-build-utils/reorder/tests/LoadJFrame.java + make/non-build-utils/reorder/tests/LoadToolkit.java + make/non-build-utils/reorder/tests/Null.java + make/non-build-utils/reorder/tests/Sleep.java + make/non-build-utils/reorder/tools/Combine.java + make/non-build-utils/reorder/tools/MaxTime.java + make/non-build-utils/reorder/tools/mcount.c + make/non-build-utils/reorder/tools/remove_mcount.c + make/non-build-utils/reorder/tools/util-i586.il + make/non-build-utils/reorder/tools/util-sparc.il + make/non-build-utils/reorder/tools/util-sparcv9.il + make/non-build-utils/sharing/README.txt + make/non-build-utils/sharing/tests/GHello.java + make/non-build-utils/sharing/tests/Hello.java + make/non-build-utils/sharing/tests/JHello.java + make/non-build-utils/src/build/tools/commentchecker/CommentChecker.java + make/non-build-utils/src/build/tools/dirdiff/DirDiff.java + make/non-build-utils/src/build/tools/makeclasslist/MakeClasslist.java - make/org/Makefile - make/org/ietf/Makefile - make/org/ietf/jgss/FILES_java.gmk - make/org/ietf/jgss/Makefile - make/org/jcp/Makefile + make/profile-includes.txt + make/profile-rtjar-includes.txt + make/scripts/addNotices.sh + make/scripts/genCharsetProvider.sh + make/scripts/genExceptions.sh + make/scripts/localelist.sh + make/src/classes/build/tools/addjsum/AddJsum.java + make/src/classes/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java + make/src/classes/build/tools/buildmetaindex/BuildMetaIndex.java + make/src/classes/build/tools/charsetmapping/DBCS.java + make/src/classes/build/tools/charsetmapping/EUC_TW.java + make/src/classes/build/tools/charsetmapping/HKSCS.java + make/src/classes/build/tools/charsetmapping/JIS0213.java + make/src/classes/build/tools/charsetmapping/Main.java + make/src/classes/build/tools/charsetmapping/SBCS.java + make/src/classes/build/tools/charsetmapping/Utils.java + make/src/classes/build/tools/classfile/RemoveMethods.java + make/src/classes/build/tools/cldrconverter/AbstractLDMLHandler.java + make/src/classes/build/tools/cldrconverter/Bundle.java + make/src/classes/build/tools/cldrconverter/BundleGenerator.java + make/src/classes/build/tools/cldrconverter/CLDRConverter.java + make/src/classes/build/tools/cldrconverter/CalendarType.java + make/src/classes/build/tools/cldrconverter/Container.java + make/src/classes/build/tools/cldrconverter/CopyrightHeaders.java + make/src/classes/build/tools/cldrconverter/Entry.java + make/src/classes/build/tools/cldrconverter/IgnoredContainer.java + make/src/classes/build/tools/cldrconverter/KeyContainer.java + make/src/classes/build/tools/cldrconverter/LDMLParseHandler.java + make/src/classes/build/tools/cldrconverter/MetaZonesParseHandler.java + make/src/classes/build/tools/cldrconverter/NumberingSystemsParseHandler.java + make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java + make/src/classes/build/tools/cldrconverter/StringArrayElement.java + make/src/classes/build/tools/cldrconverter/StringArrayEntry.java + make/src/classes/build/tools/cldrconverter/StringEntry.java + make/src/classes/build/tools/cldrconverter/SupplementDataParseHandler.java + make/src/classes/build/tools/compilefontconfig/CompileFontConfig.java + make/src/classes/build/tools/compileproperties/CompileProperties.java + make/src/classes/build/tools/deps/CheckDeps.java + make/src/classes/build/tools/dtdbuilder/DTDBuilder.java + make/src/classes/build/tools/dtdbuilder/DTDInputStream.java + make/src/classes/build/tools/dtdbuilder/DTDParser.java + make/src/classes/build/tools/dtdbuilder/PublicMapping.java + make/src/classes/build/tools/dtdbuilder/README.txt + make/src/classes/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java + make/src/classes/build/tools/generatebreakiteratordata/CharSet.java + make/src/classes/build/tools/generatebreakiteratordata/CharacterCategory.java + make/src/classes/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java + make/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java + make/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java + make/src/classes/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java + make/src/classes/build/tools/generatecharacter/CharacterName.java + make/src/classes/build/tools/generatecharacter/CharacterScript.java + make/src/classes/build/tools/generatecharacter/GenerateCharacter.java + make/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java + make/src/classes/build/tools/generatecharacter/PropList.java + make/src/classes/build/tools/generatecharacter/SpecialCaseMap.java + make/src/classes/build/tools/generatecharacter/UnicodeSpec.java + make/src/classes/build/tools/generatecharacter/Utility.java + make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java + make/src/classes/build/tools/generatenimbus/AbstractGradient.java + make/src/classes/build/tools/generatenimbus/Border.java + make/src/classes/build/tools/generatenimbus/Canvas.java + make/src/classes/build/tools/generatenimbus/ComponentColor.java + make/src/classes/build/tools/generatenimbus/Dimension.java + make/src/classes/build/tools/generatenimbus/Ellipse.java + make/src/classes/build/tools/generatenimbus/Generator.java + make/src/classes/build/tools/generatenimbus/Gradient.java + make/src/classes/build/tools/generatenimbus/GradientStop.java + make/src/classes/build/tools/generatenimbus/Insets.java + make/src/classes/build/tools/generatenimbus/Layer.java + make/src/classes/build/tools/generatenimbus/Matte.java + make/src/classes/build/tools/generatenimbus/ObjectFactory.java + make/src/classes/build/tools/generatenimbus/Paint.java + make/src/classes/build/tools/generatenimbus/PainterGenerator.java + make/src/classes/build/tools/generatenimbus/Path.java + make/src/classes/build/tools/generatenimbus/Point.java + make/src/classes/build/tools/generatenimbus/RadialGradient.java + make/src/classes/build/tools/generatenimbus/Rectangle.java + make/src/classes/build/tools/generatenimbus/Shape.java + make/src/classes/build/tools/generatenimbus/SynthModel.java + make/src/classes/build/tools/generatenimbus/Typeface.java + make/src/classes/build/tools/generatenimbus/UIColor.java + make/src/classes/build/tools/generatenimbus/UIComponent.java + make/src/classes/build/tools/generatenimbus/UIDefault.java + make/src/classes/build/tools/generatenimbus/UIFont.java + make/src/classes/build/tools/generatenimbus/UIIconRegion.java + make/src/classes/build/tools/generatenimbus/UIProperty.java + make/src/classes/build/tools/generatenimbus/UIRegion.java + make/src/classes/build/tools/generatenimbus/UIState.java + make/src/classes/build/tools/generatenimbus/UIStateType.java + make/src/classes/build/tools/generatenimbus/UIStyle.java + make/src/classes/build/tools/generatenimbus/Utils.java + make/src/classes/build/tools/hasher/Hasher.java + make/src/classes/build/tools/icondata/awt/ToBin.java + make/src/classes/build/tools/icondata/osxapp/ToBin.java + make/src/classes/build/tools/jarreorder/JarReorder.java + make/src/classes/build/tools/jdwpgen/AbstractCommandNode.java + make/src/classes/build/tools/jdwpgen/AbstractGroupNode.java + make/src/classes/build/tools/jdwpgen/AbstractNamedNode.java + make/src/classes/build/tools/jdwpgen/AbstractSimpleNode.java + make/src/classes/build/tools/jdwpgen/AbstractSimpleTypeNode.java + make/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java + make/src/classes/build/tools/jdwpgen/AbstractTypeNode.java + make/src/classes/build/tools/jdwpgen/AltNode.java + make/src/classes/build/tools/jdwpgen/ArrayObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/ArrayRegionTypeNode.java + make/src/classes/build/tools/jdwpgen/ArrayTypeNode.java + make/src/classes/build/tools/jdwpgen/BooleanTypeNode.java + make/src/classes/build/tools/jdwpgen/ByteTypeNode.java + make/src/classes/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/ClassObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/ClassTypeNode.java + make/src/classes/build/tools/jdwpgen/CommandNode.java + make/src/classes/build/tools/jdwpgen/CommandSetNode.java + make/src/classes/build/tools/jdwpgen/CommentNode.java + make/src/classes/build/tools/jdwpgen/ConstantNode.java + make/src/classes/build/tools/jdwpgen/ConstantSetNode.java + make/src/classes/build/tools/jdwpgen/Context.java + make/src/classes/build/tools/jdwpgen/ErrorNode.java + make/src/classes/build/tools/jdwpgen/ErrorSetNode.java + make/src/classes/build/tools/jdwpgen/EventNode.java + make/src/classes/build/tools/jdwpgen/FieldTypeNode.java + make/src/classes/build/tools/jdwpgen/FrameTypeNode.java + make/src/classes/build/tools/jdwpgen/GroupNode.java + make/src/classes/build/tools/jdwpgen/IntTypeNode.java + make/src/classes/build/tools/jdwpgen/InterfaceTypeNode.java + make/src/classes/build/tools/jdwpgen/LocationTypeNode.java + make/src/classes/build/tools/jdwpgen/LongTypeNode.java + make/src/classes/build/tools/jdwpgen/Main.java + make/src/classes/build/tools/jdwpgen/MethodTypeNode.java + make/src/classes/build/tools/jdwpgen/NameNode.java + make/src/classes/build/tools/jdwpgen/NameValueNode.java + make/src/classes/build/tools/jdwpgen/Node.java + make/src/classes/build/tools/jdwpgen/ObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/OutNode.java + make/src/classes/build/tools/jdwpgen/Parse.java + make/src/classes/build/tools/jdwpgen/ReferenceIDTypeNode.java + make/src/classes/build/tools/jdwpgen/ReferenceTypeNode.java + make/src/classes/build/tools/jdwpgen/RepeatNode.java + make/src/classes/build/tools/jdwpgen/ReplyNode.java + make/src/classes/build/tools/jdwpgen/RootNode.java + make/src/classes/build/tools/jdwpgen/SelectNode.java + make/src/classes/build/tools/jdwpgen/StringObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/StringTypeNode.java + make/src/classes/build/tools/jdwpgen/TaggedObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/ThreadObjectTypeNode.java + make/src/classes/build/tools/jdwpgen/TypeNode.java + make/src/classes/build/tools/jdwpgen/UntaggedValueTypeNode.java + make/src/classes/build/tools/jdwpgen/ValueTypeNode.java + make/src/classes/build/tools/spp/Spp.java + make/src/classes/build/tools/stripproperties/StripProperties.java + make/src/classes/build/tools/swingbeaninfo/DocBeanInfo.java + make/src/classes/build/tools/swingbeaninfo/GenDocletBeanInfo.java + make/src/classes/build/tools/swingbeaninfo/GenSwingBeanInfo.java + make/src/classes/build/tools/tzdb/ChronoField.java + make/src/classes/build/tools/tzdb/DateTimeException.java + make/src/classes/build/tools/tzdb/LocalDate.java + make/src/classes/build/tools/tzdb/LocalDateTime.java + make/src/classes/build/tools/tzdb/LocalTime.java + make/src/classes/build/tools/tzdb/TimeDefinition.java + make/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java + make/src/classes/build/tools/tzdb/Utils.java + make/src/classes/build/tools/tzdb/ZoneOffset.java + make/src/classes/build/tools/tzdb/ZoneOffsetTransition.java + make/src/classes/build/tools/tzdb/ZoneOffsetTransitionRule.java + make/src/classes/build/tools/tzdb/ZoneRules.java + make/src/classes/build/tools/tzdb/ZoneRulesBuilder.java + make/src/native/add_gnu_debuglink/add_gnu_debuglink.c + make/src/native/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c - make/sun/Makefile - make/sun/applet/Makefile - make/sun/audio/Makefile - make/sun/awt/CondenseRules.awk - make/sun/awt/Depend.mak - make/sun/awt/Depend.sed - make/sun/awt/FILES_c_unix.gmk - make/sun/awt/FILES_c_windows.gmk - make/sun/awt/FILES_export_unix.gmk - make/sun/awt/FILES_export_windows.gmk - make/sun/awt/Makefile - make/sun/awt/README - make/sun/awt/ToBin.java - make/sun/awt/make.depend - make/sun/awt/mapfile-mawt-vers - make/sun/awt/mapfile-vers - make/sun/awt/mapfile-vers-bsd - make/sun/awt/mapfile-vers-linux - make/sun/awt/mawt.gmk - make/sun/cldr/Makefile - make/sun/cmm/Makefile - make/sun/cmm/kcms/FILES_c_unix.gmk - make/sun/cmm/kcms/FILES_c_windows.gmk - make/sun/cmm/kcms/Makefile - make/sun/cmm/kcms/mapfile-vers - make/sun/cmm/lcms/FILES_c_unix.gmk - make/sun/cmm/lcms/FILES_c_windows.gmk - make/sun/cmm/lcms/Makefile - make/sun/cmm/lcms/mapfile-vers - make/sun/dcpr/FILES_c.gmk - make/sun/dcpr/Makefile - make/sun/dcpr/mapfile-vers - make/sun/font/FILES_c.gmk - make/sun/font/Makefile - make/sun/font/mapfile-vers - make/sun/font/mapfile-vers.openjdk - make/sun/font/reorder-i586 - make/sun/font/reorder-sparc - make/sun/font/reorder-sparcv9 - make/sun/font/t2k/FILES_c.gmk - make/sun/font/t2k/Makefile - make/sun/font/t2k/mapfile-vers - make/sun/headless/Makefile - make/sun/headless/mapfile-vers - make/sun/headless/reorder-i586 - make/sun/headless/reorder-sparc - make/sun/headless/reorder-sparcv9 - make/sun/image/Makefile - make/sun/image/generic/FILES_c.gmk - make/sun/image/generic/Makefile - make/sun/image/generic/mapfile-vers - make/sun/image/vis/FILES_c.gmk - make/sun/image/vis/Makefile - make/sun/jar/Makefile - make/sun/javazic/Makefile - make/sun/javazic/javatz/fullset.txt - make/sun/javazic/javatz/java_11_ids.txt - make/sun/javazic/javatz/java_us_ids.txt - make/sun/javazic/javatz/java_win_ids.txt - make/sun/javazic/javatz/java_zone_ids.txt - make/sun/javazic/javatz/jdk1.1.x_zone_ids.txt - make/sun/javazic/tzdata/VERSION - make/sun/javazic/tzdata/africa - make/sun/javazic/tzdata/antarctica - make/sun/javazic/tzdata/asia - make/sun/javazic/tzdata/australasia - make/sun/javazic/tzdata/backward - make/sun/javazic/tzdata/etcetera - make/sun/javazic/tzdata/europe - make/sun/javazic/tzdata/factory - make/sun/javazic/tzdata/gmt - make/sun/javazic/tzdata/iso3166.tab - make/sun/javazic/tzdata/jdk11_backward - make/sun/javazic/tzdata/leapseconds - make/sun/javazic/tzdata/northamerica - make/sun/javazic/tzdata/pacificnew - make/sun/javazic/tzdata/solar87 - make/sun/javazic/tzdata/solar88 - make/sun/javazic/tzdata/solar89 - make/sun/javazic/tzdata/southamerica - make/sun/javazic/tzdata/systemv - make/sun/javazic/tzdata/zone.tab - make/sun/javazic/tzdata_jdk/gmt - make/sun/javazic/tzdata_jdk/jdk11_backward - make/sun/javazic/tzdata_jdk/jdk11_full_backward - make/sun/jawt/Depend.mak - make/sun/jawt/Depend.sed - make/sun/jawt/Makefile - make/sun/jawt/make.depend - make/sun/jawt/mapfile-vers - make/sun/jconsole/FILES.gmk - make/sun/jconsole/Makefile - make/sun/jdga/Makefile - make/sun/jdga/mapfile-vers - make/sun/jpeg/FILES_c.gmk - make/sun/jpeg/Makefile - make/sun/jpeg/mapfile-vers - make/sun/jpeg/mapfile-vers-closed - make/sun/jpeg/reorder-i586 - make/sun/jpeg/reorder-sparc - make/sun/jpeg/reorder-sparcv9 - make/sun/launcher/Makefile - make/sun/lwawt/FILES_c_macosx.gmk - make/sun/lwawt/FILES_export_macosx.gmk - make/sun/lwawt/Makefile - make/sun/management/Makefile - make/sun/management/jmxremote/Makefile - make/sun/management/snmp/Makefile - make/sun/misc/Makefile - make/sun/native2ascii/Makefile - make/sun/net/FILES_java.gmk - make/sun/net/Makefile - make/sun/net/others/Makefile - make/sun/net/spi/Makefile - make/sun/net/spi/nameservice/Makefile - make/sun/net/spi/nameservice/dns/Makefile - make/sun/nio/Makefile - make/sun/nio/cs/FILES_java.gmk - make/sun/nio/cs/Makefile - make/sun/osxapp/Makefile - make/sun/osxapp/ToBin.java - make/sun/pisces/Makefile - make/sun/rmi/Makefile - make/sun/rmi/cgi/Makefile - make/sun/rmi/oldtools/FILES_java.gmk - make/sun/rmi/oldtools/Makefile - make/sun/rmi/registry/Makefile - make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers - make/sun/rmi/rmic/FILES.gmk - make/sun/rmi/rmic/Makefile - make/sun/rmi/rmid/Makefile - make/sun/security/Makefile - make/sun/security/action/Makefile - make/sun/security/ec/FILES_c.gmk - make/sun/security/ec/Makefile - make/sun/security/ec/mapfile-vers - make/sun/security/jgss/Makefile - make/sun/security/jgss/wrapper/FILES_c.gmk - make/sun/security/jgss/wrapper/Makefile - make/sun/security/jgss/wrapper/mapfile-vers - make/sun/security/krb5/FILES_c_windows.gmk - make/sun/security/krb5/Makefile - make/sun/security/mscapi/FILES_cpp.gmk - make/sun/security/mscapi/Makefile - make/sun/security/other/Makefile - make/sun/security/pkcs11/FILES_c.gmk - make/sun/security/pkcs11/Makefile - make/sun/security/pkcs11/mapfile-vers - make/sun/security/smartcardio/FILES_c.gmk - make/sun/security/smartcardio/Makefile - make/sun/security/smartcardio/mapfile-vers - make/sun/security/tools/Makefile - make/sun/security/util/Makefile - make/sun/serialver/Makefile - make/sun/splashscreen/FILES_c.gmk - make/sun/splashscreen/Makefile - make/sun/splashscreen/mapfile-vers - make/sun/text/FILES_java.gmk - make/sun/text/FILES_properties.gmk - make/sun/text/Makefile - make/sun/tools/Makefile - make/sun/tracing/Makefile - make/sun/tracing/dtrace/Makefile - make/sun/tracing/dtrace/mapfile-vers - make/sun/tzdb/Makefile - make/sun/usagetracker/Makefile - make/sun/util/Makefile - make/sun/xawt/FILES_c_unix.gmk - make/sun/xawt/FILES_export_unix.gmk - make/sun/xawt/Makefile - make/sun/xawt/mapfile-vers - make/templates/bsd-header - make/templates/gpl-cp-header - make/templates/gpl-header - make/tools/CharsetMapping/Big5.map - make/tools/CharsetMapping/Big5.nr - make/tools/CharsetMapping/DoubleByte-X.java.template - make/tools/CharsetMapping/EUC_CN.map - make/tools/CharsetMapping/EUC_KR.map - make/tools/CharsetMapping/GBK.map - make/tools/CharsetMapping/HKSCS2001.c2b - make/tools/CharsetMapping/HKSCS2001.map - make/tools/CharsetMapping/HKSCS2008.c2b - make/tools/CharsetMapping/HKSCS2008.map - make/tools/CharsetMapping/HKSCS_XP.c2b - make/tools/CharsetMapping/HKSCS_XP.map - make/tools/CharsetMapping/IBM037.c2b - make/tools/CharsetMapping/IBM037.map - make/tools/CharsetMapping/IBM037.nr - make/tools/CharsetMapping/IBM1006.map - make/tools/CharsetMapping/IBM1025.c2b - make/tools/CharsetMapping/IBM1025.map - make/tools/CharsetMapping/IBM1025.nr - make/tools/CharsetMapping/IBM1026.c2b - make/tools/CharsetMapping/IBM1026.map - make/tools/CharsetMapping/IBM1026.nr - make/tools/CharsetMapping/IBM1046.map - make/tools/CharsetMapping/IBM1047.map - make/tools/CharsetMapping/IBM1097.map - make/tools/CharsetMapping/IBM1098.map - make/tools/CharsetMapping/IBM1112.c2b - make/tools/CharsetMapping/IBM1112.map - make/tools/CharsetMapping/IBM1112.nr - make/tools/CharsetMapping/IBM1122.c2b - make/tools/CharsetMapping/IBM1122.map - make/tools/CharsetMapping/IBM1122.nr - make/tools/CharsetMapping/IBM1123.c2b - make/tools/CharsetMapping/IBM1123.map - make/tools/CharsetMapping/IBM1123.nr - make/tools/CharsetMapping/IBM1124.map - make/tools/CharsetMapping/IBM1140.c2b - make/tools/CharsetMapping/IBM1140.map - make/tools/CharsetMapping/IBM1141.c2b - make/tools/CharsetMapping/IBM1141.map - make/tools/CharsetMapping/IBM1142.c2b - make/tools/CharsetMapping/IBM1142.map - make/tools/CharsetMapping/IBM1143.c2b - make/tools/CharsetMapping/IBM1143.map - make/tools/CharsetMapping/IBM1144.c2b - make/tools/CharsetMapping/IBM1144.map - make/tools/CharsetMapping/IBM1145.c2b - make/tools/CharsetMapping/IBM1145.map - make/tools/CharsetMapping/IBM1146.c2b - make/tools/CharsetMapping/IBM1146.map - make/tools/CharsetMapping/IBM1147.c2b - make/tools/CharsetMapping/IBM1147.map - make/tools/CharsetMapping/IBM1148.c2b - make/tools/CharsetMapping/IBM1148.map - make/tools/CharsetMapping/IBM1149.c2b - make/tools/CharsetMapping/IBM1149.map - make/tools/CharsetMapping/IBM1364.c2b - make/tools/CharsetMapping/IBM1364.map - make/tools/CharsetMapping/IBM1381.c2b - make/tools/CharsetMapping/IBM1381.map - make/tools/CharsetMapping/IBM1383.c2b - make/tools/CharsetMapping/IBM1383.map - make/tools/CharsetMapping/IBM1383.nr - make/tools/CharsetMapping/IBM273.c2b - make/tools/CharsetMapping/IBM273.map - make/tools/CharsetMapping/IBM273.nr - make/tools/CharsetMapping/IBM277.c2b - make/tools/CharsetMapping/IBM277.map - make/tools/CharsetMapping/IBM277.nr - make/tools/CharsetMapping/IBM278.c2b - make/tools/CharsetMapping/IBM278.map - make/tools/CharsetMapping/IBM278.nr - make/tools/CharsetMapping/IBM280.c2b - make/tools/CharsetMapping/IBM280.map - make/tools/CharsetMapping/IBM280.nr - make/tools/CharsetMapping/IBM284.c2b - make/tools/CharsetMapping/IBM284.map - make/tools/CharsetMapping/IBM284.nr - make/tools/CharsetMapping/IBM285.c2b - make/tools/CharsetMapping/IBM285.map - make/tools/CharsetMapping/IBM285.nr - make/tools/CharsetMapping/IBM290.c2b - make/tools/CharsetMapping/IBM290.map - make/tools/CharsetMapping/IBM297.c2b - make/tools/CharsetMapping/IBM297.map - make/tools/CharsetMapping/IBM297.nr - make/tools/CharsetMapping/IBM300.c2b - make/tools/CharsetMapping/IBM300.map - make/tools/CharsetMapping/IBM420.c2b - make/tools/CharsetMapping/IBM420.map - make/tools/CharsetMapping/IBM420.nr - make/tools/CharsetMapping/IBM424.c2b - make/tools/CharsetMapping/IBM424.map - make/tools/CharsetMapping/IBM424.nr - make/tools/CharsetMapping/IBM437.map - make/tools/CharsetMapping/IBM500.c2b - make/tools/CharsetMapping/IBM500.map - make/tools/CharsetMapping/IBM500.nr - make/tools/CharsetMapping/IBM737.map - make/tools/CharsetMapping/IBM775.map - make/tools/CharsetMapping/IBM833.c2b - make/tools/CharsetMapping/IBM833.map - make/tools/CharsetMapping/IBM838.c2b - make/tools/CharsetMapping/IBM838.map - make/tools/CharsetMapping/IBM838.nr - make/tools/CharsetMapping/IBM850.map - make/tools/CharsetMapping/IBM852.map - make/tools/CharsetMapping/IBM855.map - make/tools/CharsetMapping/IBM856.map - make/tools/CharsetMapping/IBM857.map - make/tools/CharsetMapping/IBM858.map - make/tools/CharsetMapping/IBM860.map - make/tools/CharsetMapping/IBM861.map - make/tools/CharsetMapping/IBM862.map - make/tools/CharsetMapping/IBM863.map - make/tools/CharsetMapping/IBM864.map - make/tools/CharsetMapping/IBM865.map - make/tools/CharsetMapping/IBM866.map - make/tools/CharsetMapping/IBM868.map - make/tools/CharsetMapping/IBM869.map - make/tools/CharsetMapping/IBM870.c2b - make/tools/CharsetMapping/IBM870.map - make/tools/CharsetMapping/IBM870.nr - make/tools/CharsetMapping/IBM871.c2b - make/tools/CharsetMapping/IBM871.map - make/tools/CharsetMapping/IBM871.nr - make/tools/CharsetMapping/IBM874.map - make/tools/CharsetMapping/IBM874.nr - make/tools/CharsetMapping/IBM875.c2b - make/tools/CharsetMapping/IBM875.map - make/tools/CharsetMapping/IBM875.nr - make/tools/CharsetMapping/IBM918.c2b - make/tools/CharsetMapping/IBM918.map - make/tools/CharsetMapping/IBM918.nr - make/tools/CharsetMapping/IBM921.map - make/tools/CharsetMapping/IBM922.map - make/tools/CharsetMapping/IBM930.c2b - make/tools/CharsetMapping/IBM930.map - make/tools/CharsetMapping/IBM930.nr - make/tools/CharsetMapping/IBM933.c2b - make/tools/CharsetMapping/IBM933.map - make/tools/CharsetMapping/IBM935.c2b - make/tools/CharsetMapping/IBM935.map - make/tools/CharsetMapping/IBM935.nr - make/tools/CharsetMapping/IBM937.c2b - make/tools/CharsetMapping/IBM937.map - make/tools/CharsetMapping/IBM937.nr - make/tools/CharsetMapping/IBM939.c2b - make/tools/CharsetMapping/IBM939.map - make/tools/CharsetMapping/IBM939.nr - make/tools/CharsetMapping/IBM942.c2b - make/tools/CharsetMapping/IBM942.map - make/tools/CharsetMapping/IBM943.map - make/tools/CharsetMapping/IBM943.nr - make/tools/CharsetMapping/IBM948.c2b - make/tools/CharsetMapping/IBM948.map - make/tools/CharsetMapping/IBM949.map - make/tools/CharsetMapping/IBM950.c2b - make/tools/CharsetMapping/IBM950.map - make/tools/CharsetMapping/IBM970.c2b - make/tools/CharsetMapping/IBM970.map - make/tools/CharsetMapping/ISO_8859_11.map - make/tools/CharsetMapping/ISO_8859_13.map - make/tools/CharsetMapping/ISO_8859_15.map - make/tools/CharsetMapping/ISO_8859_2.map - make/tools/CharsetMapping/ISO_8859_3.map - make/tools/CharsetMapping/ISO_8859_4.map - make/tools/CharsetMapping/ISO_8859_5.map - make/tools/CharsetMapping/ISO_8859_6.map - make/tools/CharsetMapping/ISO_8859_7.map - make/tools/CharsetMapping/ISO_8859_8.map - make/tools/CharsetMapping/ISO_8859_9.map - make/tools/CharsetMapping/JIS_X_0201.c2b - make/tools/CharsetMapping/JIS_X_0201.map - make/tools/CharsetMapping/JIS_X_0208.map - make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b - make/tools/CharsetMapping/JIS_X_0208_MS5022X.map - make/tools/CharsetMapping/JIS_X_0208_MS932.map - make/tools/CharsetMapping/JIS_X_0208_MS932.nr - make/tools/CharsetMapping/JIS_X_0208_Solaris.map - make/tools/CharsetMapping/JIS_X_0208_Solaris.nr - make/tools/CharsetMapping/JIS_X_0212.map - make/tools/CharsetMapping/JIS_X_0212_MS5022X.map - make/tools/CharsetMapping/JIS_X_0212_Solaris.map - make/tools/CharsetMapping/JIS_X_0212_Solaris.nr - make/tools/CharsetMapping/Johab.map - make/tools/CharsetMapping/KOI8_R.map - make/tools/CharsetMapping/KOI8_U.map - make/tools/CharsetMapping/MS1250.map - make/tools/CharsetMapping/MS1251.map - make/tools/CharsetMapping/MS1252.map - make/tools/CharsetMapping/MS1253.map - make/tools/CharsetMapping/MS1254.map - make/tools/CharsetMapping/MS1255.map - make/tools/CharsetMapping/MS1256.map - make/tools/CharsetMapping/MS1257.map - make/tools/CharsetMapping/MS1258.map - make/tools/CharsetMapping/MS874.map - make/tools/CharsetMapping/MS932.c2b - make/tools/CharsetMapping/MS932.map - make/tools/CharsetMapping/MS932.nr - make/tools/CharsetMapping/MS936.map - make/tools/CharsetMapping/MS949.map - make/tools/CharsetMapping/MS950.map - make/tools/CharsetMapping/MS950.nr - make/tools/CharsetMapping/MacArabic.map - make/tools/CharsetMapping/MacCentralEurope.map - make/tools/CharsetMapping/MacCroatian.map - make/tools/CharsetMapping/MacCyrillic.map - make/tools/CharsetMapping/MacDingbat.map - make/tools/CharsetMapping/MacGreek.map - make/tools/CharsetMapping/MacHebrew.map - make/tools/CharsetMapping/MacIceland.map - make/tools/CharsetMapping/MacRoman.map - make/tools/CharsetMapping/MacRomania.map - make/tools/CharsetMapping/MacSymbol.map - make/tools/CharsetMapping/MacThai.map - make/tools/CharsetMapping/MacTurkish.map - make/tools/CharsetMapping/MacUkraine.map - make/tools/CharsetMapping/Makefile - make/tools/CharsetMapping/PCK.c2b - make/tools/CharsetMapping/PCK.map - make/tools/CharsetMapping/PCK.nr - make/tools/CharsetMapping/SJIS.c2b - make/tools/CharsetMapping/SJIS.map - make/tools/CharsetMapping/SingleByte-X.java.template - make/tools/CharsetMapping/TIS_620.map - make/tools/CharsetMapping/dbcs - make/tools/CharsetMapping/euc_tw.map - make/tools/CharsetMapping/extsbcs - make/tools/CharsetMapping/sbcs - make/tools/CharsetMapping/sjis0213.map - make/tools/GenerateCharacter/Character.c.template - make/tools/GenerateCharacter/CharacterData00.java.template - make/tools/GenerateCharacter/CharacterData01.java.template - make/tools/GenerateCharacter/CharacterData02.java.template - make/tools/GenerateCharacter/CharacterData0E.java.template - make/tools/GenerateCharacter/CharacterDataLatin1.java.template - make/tools/GenerateCharacter/CharacterDataPrivateUse.java.template - make/tools/GenerateCharacter/CharacterDataUndefined.java.template - make/tools/GenerateCharacter/Makefile - make/tools/GenerateCharacter/check_class.c.template - make/tools/Makefile - make/tools/README.txt - make/tools/UnicodeData/PropList.txt - make/tools/UnicodeData/Scripts.txt - make/tools/UnicodeData/SpecialCasing.txt - make/tools/UnicodeData/UnicodeData.txt - make/tools/UnicodeData/VERSION - make/tools/add_gnu_debuglink/Makefile - make/tools/add_gnu_debuglink/add_gnu_debuglink.c - make/tools/addjsum/Makefile - make/tools/addtorestrictedpkgs/Makefile - make/tools/buildmetaindex/Makefile - make/tools/cldrconverter/Makefile - make/tools/commentchecker/Makefile - make/tools/compile_font_config/Makefile - make/tools/compile_properties/Makefile - make/tools/dir_diff/Makefile - make/tools/dtdbuilder/Makefile - make/tools/dtdbuilder/dtds/HTMLlat1.sgml - make/tools/dtdbuilder/dtds/HTMLspecial.sgml - make/tools/dtdbuilder/dtds/HTMLsymbol.sgml - make/tools/dtdbuilder/dtds/html32.dtd - make/tools/dtdbuilder/dtds/public.map - make/tools/fix_empty_sec_hdr_flags/Makefile - make/tools/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c - make/tools/freetypecheck/Makefile - make/tools/freetypecheck/freetypecheck.c - make/tools/generate_break_iterator/Makefile - make/tools/generate_nimbus/Makefile - make/tools/generatecurrencydata/Makefile - make/tools/hasher_classes/Makefile - make/tools/jarreorder/Makefile - make/tools/jarsplit/Makefile - make/tools/jdwpgen/Makefile - make/tools/makeclasslist/Makefile - make/tools/manifest.mf - make/tools/msys_build_scripts/dospath.sh - make/tools/msys_build_scripts/dospath.vbs - make/tools/reorder/Makefile - make/tools/reorder/tests/Exit.java - make/tools/reorder/tests/Hello.java - make/tools/reorder/tests/IntToString.java - make/tools/reorder/tests/JHello.java - make/tools/reorder/tests/LoadFrame.java - make/tools/reorder/tests/LoadJFrame.java - make/tools/reorder/tests/LoadToolkit.java - make/tools/reorder/tests/Null.java - make/tools/reorder/tests/Sleep.java - make/tools/reorder/tools/Combine.java - make/tools/reorder/tools/MaxTime.java - make/tools/reorder/tools/mcount.c - make/tools/reorder/tools/remove_mcount.c - make/tools/reorder/tools/util-i586.il - make/tools/reorder/tools/util-sparc.il - make/tools/reorder/tools/util-sparcv9.il - make/tools/sharing/README.txt - make/tools/sharing/classlist.linux - make/tools/sharing/classlist.macosx - make/tools/sharing/classlist.solaris - make/tools/sharing/classlist.windows - make/tools/sharing/tests/GHello.java - make/tools/sharing/tests/Hello.java - make/tools/sharing/tests/JHello.java - make/tools/spp/Makefile - make/tools/src/build/tools/addjsum/AddJsum.java - make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java - make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java - make/tools/src/build/tools/charsetmapping/DBCS.java - make/tools/src/build/tools/charsetmapping/EUC_TW.java - make/tools/src/build/tools/charsetmapping/HKSCS.java - make/tools/src/build/tools/charsetmapping/JIS0213.java - make/tools/src/build/tools/charsetmapping/Main.java - make/tools/src/build/tools/charsetmapping/SBCS.java - make/tools/src/build/tools/charsetmapping/Utils.java - make/tools/src/build/tools/classfile/RemoveMethods.java - make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java - make/tools/src/build/tools/cldrconverter/Bundle.java - make/tools/src/build/tools/cldrconverter/BundleGenerator.java - make/tools/src/build/tools/cldrconverter/CLDRConverter.java - make/tools/src/build/tools/cldrconverter/CalendarType.java - make/tools/src/build/tools/cldrconverter/Container.java - make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java - make/tools/src/build/tools/cldrconverter/Entry.java - make/tools/src/build/tools/cldrconverter/IgnoredContainer.java - make/tools/src/build/tools/cldrconverter/KeyContainer.java - make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java - make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java - make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java - make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java - make/tools/src/build/tools/cldrconverter/StringArrayElement.java - make/tools/src/build/tools/cldrconverter/StringArrayEntry.java - make/tools/src/build/tools/cldrconverter/StringEntry.java - make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java - make/tools/src/build/tools/commentchecker/CommentChecker.java - make/tools/src/build/tools/compilefontconfig/CompileFontConfig.java - make/tools/src/build/tools/compileproperties/CompileProperties.java - make/tools/src/build/tools/deps/CheckDeps.java - make/tools/src/build/tools/deps/refs.allowed - make/tools/src/build/tools/dirdiff/DirDiff.java - make/tools/src/build/tools/dtdbuilder/DTDBuilder.java - make/tools/src/build/tools/dtdbuilder/DTDInputStream.java - make/tools/src/build/tools/dtdbuilder/DTDParser.java - make/tools/src/build/tools/dtdbuilder/PublicMapping.java - make/tools/src/build/tools/dtdbuilder/README.txt - make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java - make/tools/src/build/tools/generatebreakiteratordata/CharSet.java - make/tools/src/build/tools/generatebreakiteratordata/CharacterCategory.java - make/tools/src/build/tools/generatebreakiteratordata/DictionaryBasedBreakIteratorBuilder.java - make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java - make/tools/src/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java - make/tools/src/build/tools/generatebreakiteratordata/SupplementaryCharacterData.java - make/tools/src/build/tools/generatecharacter/CharacterName.java - make/tools/src/build/tools/generatecharacter/CharacterScript.java - make/tools/src/build/tools/generatecharacter/GenerateCharacter.java - make/tools/src/build/tools/generatecharacter/PrintCharacterRanges.java - make/tools/src/build/tools/generatecharacter/PropList.java - make/tools/src/build/tools/generatecharacter/SpecialCaseMap.java - make/tools/src/build/tools/generatecharacter/UnicodeSpec.java - make/tools/src/build/tools/generatecharacter/Utility.java - make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java - make/tools/src/build/tools/generatenimbus/AbstractGradient.java - make/tools/src/build/tools/generatenimbus/Border.java - make/tools/src/build/tools/generatenimbus/Canvas.java - make/tools/src/build/tools/generatenimbus/ComponentColor.java - make/tools/src/build/tools/generatenimbus/Dimension.java - make/tools/src/build/tools/generatenimbus/Ellipse.java - make/tools/src/build/tools/generatenimbus/Generator.java - make/tools/src/build/tools/generatenimbus/Gradient.java - make/tools/src/build/tools/generatenimbus/GradientStop.java - make/tools/src/build/tools/generatenimbus/Insets.java - make/tools/src/build/tools/generatenimbus/Layer.java - make/tools/src/build/tools/generatenimbus/Matte.java - make/tools/src/build/tools/generatenimbus/ObjectFactory.java - make/tools/src/build/tools/generatenimbus/Paint.java - make/tools/src/build/tools/generatenimbus/PainterGenerator.java - make/tools/src/build/tools/generatenimbus/Path.java - make/tools/src/build/tools/generatenimbus/Point.java - make/tools/src/build/tools/generatenimbus/RadialGradient.java - make/tools/src/build/tools/generatenimbus/Rectangle.java - make/tools/src/build/tools/generatenimbus/Shape.java - make/tools/src/build/tools/generatenimbus/SynthModel.java - make/tools/src/build/tools/generatenimbus/Typeface.java - make/tools/src/build/tools/generatenimbus/UIColor.java - make/tools/src/build/tools/generatenimbus/UIComponent.java - make/tools/src/build/tools/generatenimbus/UIDefault.java - make/tools/src/build/tools/generatenimbus/UIFont.java - make/tools/src/build/tools/generatenimbus/UIIconRegion.java - make/tools/src/build/tools/generatenimbus/UIProperty.java - make/tools/src/build/tools/generatenimbus/UIRegion.java - make/tools/src/build/tools/generatenimbus/UIState.java - make/tools/src/build/tools/generatenimbus/UIStateType.java - make/tools/src/build/tools/generatenimbus/UIStyle.java - make/tools/src/build/tools/generatenimbus/Utils.java - make/tools/src/build/tools/hasher/Hasher.java - make/tools/src/build/tools/jarreorder/JarReorder.java - make/tools/src/build/tools/jarsplit/JarSplit.java - make/tools/src/build/tools/jdwpgen/AbstractCommandNode.java - make/tools/src/build/tools/jdwpgen/AbstractGroupNode.java - make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java - make/tools/src/build/tools/jdwpgen/AbstractSimpleNode.java - make/tools/src/build/tools/jdwpgen/AbstractSimpleTypeNode.java - make/tools/src/build/tools/jdwpgen/AbstractTypeListNode.java - make/tools/src/build/tools/jdwpgen/AbstractTypeNode.java - make/tools/src/build/tools/jdwpgen/AltNode.java - make/tools/src/build/tools/jdwpgen/ArrayObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java - make/tools/src/build/tools/jdwpgen/ArrayTypeNode.java - make/tools/src/build/tools/jdwpgen/BooleanTypeNode.java - make/tools/src/build/tools/jdwpgen/ByteTypeNode.java - make/tools/src/build/tools/jdwpgen/ClassLoaderObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/ClassObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/ClassTypeNode.java - make/tools/src/build/tools/jdwpgen/CommandNode.java - make/tools/src/build/tools/jdwpgen/CommandSetNode.java - make/tools/src/build/tools/jdwpgen/CommentNode.java - make/tools/src/build/tools/jdwpgen/ConstantNode.java - make/tools/src/build/tools/jdwpgen/ConstantSetNode.java - make/tools/src/build/tools/jdwpgen/Context.java - make/tools/src/build/tools/jdwpgen/ErrorNode.java - make/tools/src/build/tools/jdwpgen/ErrorSetNode.java - make/tools/src/build/tools/jdwpgen/EventNode.java - make/tools/src/build/tools/jdwpgen/FieldTypeNode.java - make/tools/src/build/tools/jdwpgen/FrameTypeNode.java - make/tools/src/build/tools/jdwpgen/GroupNode.java - make/tools/src/build/tools/jdwpgen/IntTypeNode.java - make/tools/src/build/tools/jdwpgen/InterfaceTypeNode.java - make/tools/src/build/tools/jdwpgen/LocationTypeNode.java - make/tools/src/build/tools/jdwpgen/LongTypeNode.java - make/tools/src/build/tools/jdwpgen/Main.java - make/tools/src/build/tools/jdwpgen/MethodTypeNode.java - make/tools/src/build/tools/jdwpgen/NameNode.java - make/tools/src/build/tools/jdwpgen/NameValueNode.java - make/tools/src/build/tools/jdwpgen/Node.java - make/tools/src/build/tools/jdwpgen/ObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/OutNode.java - make/tools/src/build/tools/jdwpgen/Parse.java - make/tools/src/build/tools/jdwpgen/ReferenceIDTypeNode.java - make/tools/src/build/tools/jdwpgen/ReferenceTypeNode.java - make/tools/src/build/tools/jdwpgen/RepeatNode.java - make/tools/src/build/tools/jdwpgen/ReplyNode.java - make/tools/src/build/tools/jdwpgen/RootNode.java - make/tools/src/build/tools/jdwpgen/SelectNode.java - make/tools/src/build/tools/jdwpgen/StringObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/StringTypeNode.java - make/tools/src/build/tools/jdwpgen/TaggedObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/ThreadGroupObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/ThreadObjectTypeNode.java - make/tools/src/build/tools/jdwpgen/TypeNode.java - make/tools/src/build/tools/jdwpgen/UntaggedValueTypeNode.java - make/tools/src/build/tools/jdwpgen/ValueTypeNode.java - make/tools/src/build/tools/makeclasslist/MakeClasslist.java - make/tools/src/build/tools/spp/Spp.java - make/tools/src/build/tools/stripproperties/StripProperties.java - make/tools/src/build/tools/tzdb/ChronoField.java - make/tools/src/build/tools/tzdb/DateTimeException.java - make/tools/src/build/tools/tzdb/LocalDate.java - make/tools/src/build/tools/tzdb/LocalDateTime.java - make/tools/src/build/tools/tzdb/LocalTime.java - make/tools/src/build/tools/tzdb/TimeDefinition.java - make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java - make/tools/src/build/tools/tzdb/Utils.java - make/tools/src/build/tools/tzdb/ZoneOffset.java - make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java - make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java - make/tools/src/build/tools/tzdb/ZoneRules.java - make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java - make/tools/strip_properties/Makefile - make/tools/swing-beans/DocBeanInfo.java - make/tools/swing-beans/GenDocletBeanInfo.java - make/tools/swing-beans/GenSwingBeanInfo.java - make/tools/swing-beans/SwingBeanInfo.template - make/tools/swing-beans/beaninfo/images/AbstractButtonColor16.gif - make/tools/swing-beans/beaninfo/images/BorderColor16.gif - make/tools/swing-beans/beaninfo/images/BoxColor16.gif - make/tools/swing-beans/beaninfo/images/BoxColor32.gif - make/tools/swing-beans/beaninfo/images/BoxMono16.gif - make/tools/swing-beans/beaninfo/images/BoxMono32.gif - make/tools/swing-beans/beaninfo/images/JAppletColor16.gif - make/tools/swing-beans/beaninfo/images/JAppletColor32.gif - make/tools/swing-beans/beaninfo/images/JAppletMono16.gif - make/tools/swing-beans/beaninfo/images/JAppletMono32.gif - make/tools/swing-beans/beaninfo/images/JButtonColor16.gif - make/tools/swing-beans/beaninfo/images/JButtonColor32.gif - make/tools/swing-beans/beaninfo/images/JButtonMono16.gif - make/tools/swing-beans/beaninfo/images/JButtonMono32.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxColor16.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxColor32.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor16.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemColor32.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono16.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxMenuItemMono32.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxMono16.gif - make/tools/swing-beans/beaninfo/images/JCheckBoxMono32.gif - make/tools/swing-beans/beaninfo/images/JColorChooserColor16.gif - make/tools/swing-beans/beaninfo/images/JColorChooserColor32.gif - make/tools/swing-beans/beaninfo/images/JColorChooserMono16.gif - make/tools/swing-beans/beaninfo/images/JColorChooserMono32.gif - make/tools/swing-beans/beaninfo/images/JComboBoxColor16.gif - make/tools/swing-beans/beaninfo/images/JComboBoxColor32.gif - make/tools/swing-beans/beaninfo/images/JComboBoxMono16.gif - make/tools/swing-beans/beaninfo/images/JComboBoxMono32.gif - make/tools/swing-beans/beaninfo/images/JComponentColor16.gif - make/tools/swing-beans/beaninfo/images/JDesktopPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JDesktopPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JDesktopPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JDesktopPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JDialogColor16.gif - make/tools/swing-beans/beaninfo/images/JDialogColor32.gif - make/tools/swing-beans/beaninfo/images/JDialogMono16.gif - make/tools/swing-beans/beaninfo/images/JDialogMono32.gif - make/tools/swing-beans/beaninfo/images/JEditorPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JEditorPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JEditorPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JEditorPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JFileChooserColor16.gif - make/tools/swing-beans/beaninfo/images/JFileChooserColor32.gif - make/tools/swing-beans/beaninfo/images/JFileChooserMono16.gif - make/tools/swing-beans/beaninfo/images/JFileChooserMono32.gif - make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor16.gif - make/tools/swing-beans/beaninfo/images/JFormattedTextFieldColor32.gif - make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono16.gif - make/tools/swing-beans/beaninfo/images/JFormattedTextFieldMono32.gif - make/tools/swing-beans/beaninfo/images/JFrameColor16.gif - make/tools/swing-beans/beaninfo/images/JFrameColor32.gif - make/tools/swing-beans/beaninfo/images/JFrameMono16.gif - make/tools/swing-beans/beaninfo/images/JFrameMono32.gif - make/tools/swing-beans/beaninfo/images/JInternalFrameColor16.gif - make/tools/swing-beans/beaninfo/images/JInternalFrameColor32.gif - make/tools/swing-beans/beaninfo/images/JInternalFrameMono16.gif - make/tools/swing-beans/beaninfo/images/JInternalFrameMono32.gif - make/tools/swing-beans/beaninfo/images/JLabelColor16.gif - make/tools/swing-beans/beaninfo/images/JLabelColor32.gif - make/tools/swing-beans/beaninfo/images/JLabelMono16.gif - make/tools/swing-beans/beaninfo/images/JLabelMono32.gif - make/tools/swing-beans/beaninfo/images/JLayeredPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JLayeredPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JLayeredPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JLayeredPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JListColor16.gif - make/tools/swing-beans/beaninfo/images/JListColor32.gif - make/tools/swing-beans/beaninfo/images/JListMono16.gif - make/tools/swing-beans/beaninfo/images/JListMono32.gif - make/tools/swing-beans/beaninfo/images/JMenuBarColor16.gif - make/tools/swing-beans/beaninfo/images/JMenuBarColor32.gif - make/tools/swing-beans/beaninfo/images/JMenuBarMono16.gif - make/tools/swing-beans/beaninfo/images/JMenuBarMono32.gif - make/tools/swing-beans/beaninfo/images/JMenuColor16.gif - make/tools/swing-beans/beaninfo/images/JMenuColor32.gif - make/tools/swing-beans/beaninfo/images/JMenuItemColor16.gif - make/tools/swing-beans/beaninfo/images/JMenuItemColor32.gif - make/tools/swing-beans/beaninfo/images/JMenuItemMono16.gif - make/tools/swing-beans/beaninfo/images/JMenuItemMono32.gif - make/tools/swing-beans/beaninfo/images/JMenuMono16.gif - make/tools/swing-beans/beaninfo/images/JMenuMono32.gif - make/tools/swing-beans/beaninfo/images/JOptionPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JOptionPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JOptionPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JOptionPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JPanelColor16.gif - make/tools/swing-beans/beaninfo/images/JPanelColor32.gif - make/tools/swing-beans/beaninfo/images/JPanelMono16.gif - make/tools/swing-beans/beaninfo/images/JPanelMono32.gif - make/tools/swing-beans/beaninfo/images/JPasswordFieldColor16.gif - make/tools/swing-beans/beaninfo/images/JPasswordFieldColor32.gif - make/tools/swing-beans/beaninfo/images/JPasswordFieldMono16.gif - make/tools/swing-beans/beaninfo/images/JPasswordFieldMono32.gif - make/tools/swing-beans/beaninfo/images/JPopupMenuColor16.gif - make/tools/swing-beans/beaninfo/images/JPopupMenuColor32.gif - make/tools/swing-beans/beaninfo/images/JPopupMenuMono16.gif - make/tools/swing-beans/beaninfo/images/JPopupMenuMono32.gif - make/tools/swing-beans/beaninfo/images/JProgressBarColor16.gif - make/tools/swing-beans/beaninfo/images/JProgressBarColor32.gif - make/tools/swing-beans/beaninfo/images/JProgressBarMono16.gif - make/tools/swing-beans/beaninfo/images/JProgressBarMono32.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonColor16.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonColor32.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor16.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemColor32.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono16.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonMenuItemMono32.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonMono16.gif - make/tools/swing-beans/beaninfo/images/JRadioButtonMono32.gif - make/tools/swing-beans/beaninfo/images/JRootPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JRootPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JRootPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JRootPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JScrollBarColor16.gif - make/tools/swing-beans/beaninfo/images/JScrollBarColor32.gif - make/tools/swing-beans/beaninfo/images/JScrollBarMono16.gif - make/tools/swing-beans/beaninfo/images/JScrollBarMono32.gif - make/tools/swing-beans/beaninfo/images/JScrollPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JScrollPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JScrollPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JScrollPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JSeparatorColor16.gif - make/tools/swing-beans/beaninfo/images/JSeparatorColor32.gif - make/tools/swing-beans/beaninfo/images/JSeparatorMono16.gif - make/tools/swing-beans/beaninfo/images/JSeparatorMono32.gif - make/tools/swing-beans/beaninfo/images/JSliderColor16.gif - make/tools/swing-beans/beaninfo/images/JSliderColor32.gif - make/tools/swing-beans/beaninfo/images/JSliderMono16.gif - make/tools/swing-beans/beaninfo/images/JSliderMono32.gif - make/tools/swing-beans/beaninfo/images/JSpinnerColor16.gif - make/tools/swing-beans/beaninfo/images/JSpinnerColor32.gif - make/tools/swing-beans/beaninfo/images/JSpinnerMono16.gif - make/tools/swing-beans/beaninfo/images/JSpinnerMono32.gif - make/tools/swing-beans/beaninfo/images/JSplitPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JSplitPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JSplitPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JSplitPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JTabbedPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JTabbedPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JTabbedPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JTabbedPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JTableColor16.gif - make/tools/swing-beans/beaninfo/images/JTableColor32.gif - make/tools/swing-beans/beaninfo/images/JTableMono16.gif - make/tools/swing-beans/beaninfo/images/JTableMono32.gif - make/tools/swing-beans/beaninfo/images/JTextAreaColor16.gif - make/tools/swing-beans/beaninfo/images/JTextAreaColor32.gif - make/tools/swing-beans/beaninfo/images/JTextAreaMono16.gif - make/tools/swing-beans/beaninfo/images/JTextAreaMono32.gif - make/tools/swing-beans/beaninfo/images/JTextFieldColor16.gif - make/tools/swing-beans/beaninfo/images/JTextFieldColor32.gif - make/tools/swing-beans/beaninfo/images/JTextFieldMono16.gif - make/tools/swing-beans/beaninfo/images/JTextFieldMono32.gif - make/tools/swing-beans/beaninfo/images/JTextPaneColor16.gif - make/tools/swing-beans/beaninfo/images/JTextPaneColor32.gif - make/tools/swing-beans/beaninfo/images/JTextPaneMono16.gif - make/tools/swing-beans/beaninfo/images/JTextPaneMono32.gif - make/tools/swing-beans/beaninfo/images/JToggleButtonColor16.gif - make/tools/swing-beans/beaninfo/images/JToggleButtonColor32.gif - make/tools/swing-beans/beaninfo/images/JToggleButtonMono16.gif - make/tools/swing-beans/beaninfo/images/JToggleButtonMono32.gif - make/tools/swing-beans/beaninfo/images/JToolBarColor16.gif - make/tools/swing-beans/beaninfo/images/JToolBarColor32.gif - make/tools/swing-beans/beaninfo/images/JToolBarMono16.gif - make/tools/swing-beans/beaninfo/images/JToolBarMono32.gif - make/tools/swing-beans/beaninfo/images/JTreeColor16.gif - make/tools/swing-beans/beaninfo/images/JTreeColor32.gif - make/tools/swing-beans/beaninfo/images/JTreeMono16.gif - make/tools/swing-beans/beaninfo/images/JTreeMono32.gif - make/tools/swing-beans/beaninfo/images/JViewportColor16.gif - make/tools/swing-beans/beaninfo/images/JViewportColor32.gif - make/tools/swing-beans/beaninfo/images/JViewportMono16.gif - make/tools/swing-beans/beaninfo/images/JViewportMono32.gif - make/tools/swing-beans/beaninfo/images/JWindowColor16.gif - make/tools/swing-beans/beaninfo/images/JWindowColor32.gif - make/tools/swing-beans/beaninfo/images/JWindowMono16.gif - make/tools/swing-beans/beaninfo/images/JWindowMono32.gif - make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java - make/tools/swing-beans/sun/swing/BeanInfoUtils.java - make/tools/tzdb/Makefile - makefiles/BuildJdk.gmk - makefiles/Bundles.gmk - makefiles/CompileDemos.gmk - makefiles/CompileJavaClasses.gmk - makefiles/CompileLaunchers.gmk - makefiles/CompileNativeLibraries.gmk - makefiles/CopyFiles.gmk - makefiles/CopyIntoClasses.gmk - makefiles/CopySamples.gmk - makefiles/CreateJars.gmk - makefiles/CreateSecurityJars.gmk - makefiles/GenerateClasses.gmk - makefiles/GenerateData.gmk - makefiles/GenerateSources.gmk - makefiles/Images.gmk - makefiles/Import.gmk - makefiles/Makefile - makefiles/PatchList.solaris - makefiles/ProfileNames.gmk - makefiles/Profiles.gmk - makefiles/Setup.gmk - makefiles/SignJars.gmk - makefiles/Tools.gmk - makefiles/gendata/GendataBreakIterator.gmk - makefiles/gendata/GendataFontConfig.gmk - makefiles/gendata/GendataHtml32dtd.gmk - makefiles/gendata/GendataTZDB.gmk - makefiles/gendata/GendataTimeZone.gmk - makefiles/gensrc/GensrcBuffer.gmk - makefiles/gensrc/GensrcCLDR.gmk - makefiles/gensrc/GensrcCharacterData.gmk - makefiles/gensrc/GensrcCharsetCoder.gmk - makefiles/gensrc/GensrcCharsetMapping.gmk - makefiles/gensrc/GensrcExceptions.gmk - makefiles/gensrc/GensrcIcons.gmk - makefiles/gensrc/GensrcJDWP.gmk - makefiles/gensrc/GensrcJObjC.gmk - makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk - makefiles/gensrc/GensrcMisc.gmk - makefiles/gensrc/GensrcProperties.gmk - makefiles/gensrc/GensrcSwing.gmk - makefiles/gensrc/GensrcX11Wrappers.gmk - makefiles/jpda/jdwp/jdwp.spec - makefiles/jprt.gmk - makefiles/jprt.properties - makefiles/lib/Awt2dLibraries.gmk - makefiles/lib/CoreLibraries.gmk - makefiles/lib/NetworkingLibraries.gmk - makefiles/lib/NioLibraries.gmk - makefiles/lib/PlatformLibraries.gmk - makefiles/lib/SecurityLibraries.gmk - makefiles/lib/ServiceabilityLibraries.gmk - makefiles/lib/SoundLibraries.gmk - makefiles/mapfiles/launchers/mapfile-sparc - makefiles/mapfiles/launchers/mapfile-sparcv9 - makefiles/mapfiles/launchers/mapfile-x86 - makefiles/mapfiles/launchers/mapfile-x86_64 - makefiles/mapfiles/libattach/mapfile-linux - makefiles/mapfiles/libattach/mapfile-solaris - makefiles/mapfiles/libattach/reorder-windows-x86 - makefiles/mapfiles/libattach/reorder-windows-x86_64 - makefiles/mapfiles/libawt/mapfile-mawt-vers - makefiles/mapfiles/libawt/mapfile-vers - makefiles/mapfiles/libawt/mapfile-vers-linux - makefiles/mapfiles/libawt_headless/mapfile-vers - makefiles/mapfiles/libawt_headless/reorder-sparc - makefiles/mapfiles/libawt_headless/reorder-sparcv9 - makefiles/mapfiles/libawt_headless/reorder-x86 - makefiles/mapfiles/libawt_xawt/mapfile-vers - makefiles/mapfiles/libdcpr/mapfile-vers - makefiles/mapfiles/libdt_socket/mapfile-vers - makefiles/mapfiles/libfontmanager/mapfile-vers - makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk - makefiles/mapfiles/libhprof/mapfile-vers - makefiles/mapfiles/libinstrument/mapfile-vers - makefiles/mapfiles/libj2gss/mapfile-vers - makefiles/mapfiles/libj2pcsc/mapfile-vers - makefiles/mapfiles/libj2pkcs11/mapfile-vers - makefiles/mapfiles/libj2ucrypto/mapfile-vers - makefiles/mapfiles/libjaas/mapfile-vers - makefiles/mapfiles/libjava/mapfile-vers - makefiles/mapfiles/libjava/reorder-sparc - makefiles/mapfiles/libjava/reorder-sparcv9 - makefiles/mapfiles/libjava/reorder-x86 - makefiles/mapfiles/libjava_crw_demo/mapfile-vers - makefiles/mapfiles/libjawt/mapfile-vers - makefiles/mapfiles/libjdga/mapfile-vers - makefiles/mapfiles/libjdwp/mapfile-vers - makefiles/mapfiles/libjfr/mapfile-vers - makefiles/mapfiles/libjli/mapfile-vers - makefiles/mapfiles/libjpeg/mapfile-vers - makefiles/mapfiles/libjpeg/mapfile-vers-closed - makefiles/mapfiles/libjpeg/reorder-sparc - makefiles/mapfiles/libjpeg/reorder-sparcv9 - makefiles/mapfiles/libjpeg/reorder-x86 - makefiles/mapfiles/libjsdt/mapfile-vers - makefiles/mapfiles/libjsound/mapfile-vers - makefiles/mapfiles/libjsoundalsa/mapfile-vers - makefiles/mapfiles/libkcms/mapfile-vers - makefiles/mapfiles/liblcms/mapfile-vers - makefiles/mapfiles/libmanagement/mapfile-vers - makefiles/mapfiles/libmlib_image/mapfile-vers - makefiles/mapfiles/libnet/mapfile-vers - makefiles/mapfiles/libnio/mapfile-linux - makefiles/mapfiles/libnio/mapfile-macosx - makefiles/mapfiles/libnio/mapfile-solaris - makefiles/mapfiles/libnio/reorder-sparc - makefiles/mapfiles/libnio/reorder-sparcv9 - makefiles/mapfiles/libnio/reorder-x86 - makefiles/mapfiles/libnpt/mapfile-vers - makefiles/mapfiles/libsctp/mapfile-vers - makefiles/mapfiles/libsplashscreen/mapfile-vers - makefiles/mapfiles/libsunec/mapfile-vers - makefiles/mapfiles/libt2k/mapfile-vers - makefiles/mapfiles/libunpack/mapfile-vers - makefiles/mapfiles/libunpack/mapfile-vers-unpack200 - makefiles/mapfiles/libverify/mapfile-vers - makefiles/mapfiles/libverify/reorder-sparc - makefiles/mapfiles/libverify/reorder-sparcv9 - makefiles/mapfiles/libverify/reorder-x86 - makefiles/mapfiles/libzip/mapfile-vers - makefiles/mapfiles/libzip/reorder-sparc - makefiles/mapfiles/libzip/reorder-sparcv9 - makefiles/mapfiles/libzip/reorder-x86 - makefiles/profile-includes.txt - makefiles/profile-rtjar-includes.txt - makefiles/scripts/addNotices.sh - makefiles/scripts/genCharsetProvider.sh - makefiles/scripts/genExceptions.sh - makefiles/scripts/localelist.sh - makefiles/sun/awt/ToBin.java - makefiles/sun/osxapp/ToBin.java From magnus.ihse.bursie at oracle.com Mon Nov 18 17:54:44 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:54:44 +0000 Subject: hg: jdk8/tl/jaxws: 8027566: Remove the old build system Message-ID: <20131118175449.7656262670@hg.openjdk.java.net> Changeset: 1d1af4ce8eeb Author: ihse Date: 2013-11-04 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1d1af4ce8eeb 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildJaxws.gmk ! make/Makefile - make/jprt.properties - make/scripts/update_src.sh - makefiles/BuildJaxws.gmk - makefiles/Makefile From magnus.ihse.bursie at oracle.com Mon Nov 18 17:55:28 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:55:28 +0000 Subject: hg: jdk8/tl/nashorn: 8027566: Remove the old build system Message-ID: <20131118175530.C4FAE62672@hg.openjdk.java.net> Changeset: 779e155419b8 Author: ihse Date: 2013-11-04 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/779e155419b8 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildNashorn.gmk ! make/Makefile - makefiles/BuildNashorn.gmk - makefiles/Makefile From magnus.ihse.bursie at oracle.com Mon Nov 18 17:55:19 2013 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Mon, 18 Nov 2013 17:55:19 +0000 Subject: hg: jdk8/tl/langtools: 8027566: Remove the old build system Message-ID: <20131118175531.0687062673@hg.openjdk.java.net> Changeset: 8043b9cf31ab Author: ihse Date: 2013-11-04 11:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8043b9cf31ab 8027566: Remove the old build system Reviewed-by: erikj, tbell + make/BuildLangtools.gmk ! make/Makefile - make/jprt.properties - makefiles/BuildLangtools.gmk - makefiles/Makefile From mandy.chung at oracle.com Mon Nov 18 19:22:12 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 18 Nov 2013 11:22:12 -0800 Subject: CallerSensitive access rights problems In-Reply-To: <528A4222.8070105@gmail.com> References: <528A2B51.1020203@gmx.org> <528A32E7.2080505@oracle.com> <528A4222.8070105@gmail.com> Message-ID: <528A68E4.3030808@oracle.com> On 11/18/13 8:36 AM, Peter Levart wrote: > 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 want to build our runtime structure for >>> this class, and the security manager is not allowing access to >>> sun.reflect, then we get into trouble. >>> https://jira.codehaus.org/browse/GROOVY-6405 is caused by this. >>> >>> What do you suggest people with this problem, if adding >>> accessClassInPackage.sun.reflect is no option? >> Is it sun.reflect.CallerSensitive.class.getDeclaredMethods that is >> failing? >> >> -Alan. > > From GROOVY-6405 discussion I think it is, yes. > > The work-around suggested in GROOVY-6405 does not work, because it has > a bug. It should be written as: > > private static void setAnnotationMetaData(Annotation[] annotations > /*, AnnotatedNode an */) { > for (Annotation annotation : annotations) { > if (annotation*.annotationType()*.getPackage() == null || > !"sun.reflect".equals(annotation*.annotationType()*.getPackage().getName())) > { > System.out.println("Processing: " + > annotation.annotationType().getName()); > } else { > System.out.println("Skipping: " + > annotation.annotationType().getName()); > } > } > } > > > ... i.e. don't call annotation.*getClass()* because what you get is a > dynamic Proxy class implementing the annotation interface and such > Proxy class does not live in the same package as the annotation > interface... > Good catch Peter. > There is another such annotation to watch for, in another protected > package: *sun.misc.Contended* ... sun.reflect.CallerSensitive and sun.misc.Contended are two new annotations added in jdk8 and they are both restricted packages. sun.* is only one of the restricted packages and the entire list is in package.access in java.security property file. Mandy From mandy.chung at oracle.com Tue Nov 19 03:34:25 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 18 Nov 2013 19:34:25 -0800 Subject: Review Request for ProblemList.txt update Message-ID: <528ADC41.1020808@oracle.com> java/lang/management/ThreadMXBean/ThreadStateTest.java has been fixed in [1]. This patch removes it from jdk/test/ProblemList.txt: $ hg diff ProblemList.txt diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -122,9 +122,6 @@ # jdk_lang -# 6944188 -java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all - # 7067973 java/lang/management/MemoryMXBean/CollectionUsageThreshold.java generic-all thanks Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85fd2ae0a845 From srikalyan.chandrashekar at oracle.com Tue Nov 19 06:12:58 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Mon, 18 Nov 2013 22:12:58 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' Message-ID: <528B016A.3080408@oracle.com> Hi all, I am working on bug JDK-6772009 . Root Cause: The timeout value gives too much grace period on faster machines on which the "TO BE INTERRUPTED" threads complete faster before being interrupted at right time. Suggested Fix: a) Decrease the timeout from 100 to 50ms which will ensure that the test will pass even on faster machines , and ensures the threads will be canceled when running and anyways there is a Barrier to ensure the test threads all complete gracefully. Miscellaneous fixes b) Convert result from int to long(possible integer overflow otherwise) c) Catch BrokenBarrierException in more granular fashion in ReentrantLockLoop to update and print the results (which will be missed otherwise) Add more diagnostics d) Assign names to threads e) Print which threads update the 'completed' variable. I have attached the webrev for convenience as the changes are interleaved and is best viewed as sdiff. Please let me know if you have any comments or suggestions. Thank you -- -- Thanks kalyan From martinrb at google.com Tue Nov 19 06:15:08 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 18 Nov 2013 22:15:08 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <528B016A.3080408@oracle.com> References: <528B016A.3080408@oracle.com> Message-ID: Thanks for working on this. There have been some recent upstream changes to this test as well. Please incorporate them. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co The jsr166 maintainers haven't been able to reproduce any failures in this test. Do you have any hints that might help us? On Mon, Nov 18, 2013 at 10:12 PM, srikalyan chandrashekar < srikalyan.chandrashekar at oracle.com> wrote: > Hi all, I am working on bug JDK-6772009 net/browse/JDK-6772009> . > > Root Cause: > The timeout value gives too much grace period on faster machines on which > the "TO BE INTERRUPTED" threads complete faster before being interrupted at > right time. > > Suggested Fix: > a) Decrease the timeout from 100 to 50ms which will ensure that the test > will pass even on faster machines , and ensures the threads will be > canceled when running and anyways there is a Barrier to ensure the test > threads all complete gracefully. > Miscellaneous fixes > b) Convert result from int to long(possible integer overflow otherwise) > c) Catch BrokenBarrierException in more granular fashion in > ReentrantLockLoop to update and print the results (which will be missed > otherwise) > Add more diagnostics > d) Assign names to threads > e) Print which threads update the 'completed' variable. > > I have attached the webrev for convenience as the changes are interleaved > and is best viewed as sdiff. > Please let me know if you have any comments or suggestions. > > > > Thank you > > -- > > -- > Thanks > kalyan > > From weijun.wang at oracle.com Tue Nov 19 06:15:41 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 19 Nov 2013 06:15:41 +0000 Subject: hg: jdk8/tl/jdk: 8028479: runNameEquals still cannot precisely detect if a usable native krb5 is available Message-ID: <20131119061604.35CBD62692@hg.openjdk.java.net> Changeset: 7b71e53c6a2b Author: weijun Date: 2013-11-19 14:14 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b71e53c6a2b 8028479: runNameEquals still cannot precisely detect if a usable native krb5 is available Reviewed-by: xuelei ! test/sun/security/krb5/runNameEquals.sh From staffan.larsen at oracle.com Tue Nov 19 06:47:25 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 19 Nov 2013 07:47:25 +0100 Subject: Review Request for ProblemList.txt update In-Reply-To: <528ADC41.1020808@oracle.com> References: <528ADC41.1020808@oracle.com> Message-ID: <8D0F18B4-3054-4A0F-AE74-10974BF249FD@oracle.com> Looks good! Thanks, /Staffan On 19 Nov 2013, at 04:34, Mandy Chung wrote: > java/lang/management/ThreadMXBean/ThreadStateTest.java has been fixed in [1]. > > This patch removes it from jdk/test/ProblemList.txt: > > $ hg diff ProblemList.txt > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -122,9 +122,6 @@ > > # jdk_lang > > -# 6944188 > -java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all > - > # 7067973 > java/lang/management/MemoryMXBean/CollectionUsageThreshold.java generic-all > > thanks > Mandy > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85fd2ae0a845 > From mcnepp02 at googlemail.com Tue Nov 19 08:22:58 2013 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Tue, 19 Nov 2013 09:22:58 +0100 Subject: Why stream from BufferedReader::lines is not closing the reader? In-Reply-To: <528A34B8.8010908@gmail.com> References: <5289E788.4090504@oracle.com> <528A2409.8030401@oracle.com> <528A34B8.8010908@gmail.com> Message-ID: Another idea to solve the long-standing issue with checked IOExceptions in "close()" calls is to add a method to java.io.Closeable, now possible thanks to default methods: /** * Invokes #close() and wraps IOExceptions with UncheckedIOExceptions. */ default void closeUnchecked() { try { close(); } catch(IOException e) { throw new UncheckedIOException(e); } } This would at least make it possible to pass "closeableInstance::closeUnchecked" to Stream.onClose(Runnable). 2013/11/18 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 br.lines.onClose(br::close); >> } >> ... >> > > ...the only problem with above code is that it doesn't compile, because of > IOException declared on BufferedReader (FileReader actually!) constructor > and BufferedReader.close() method. The solutions to this have already been > discussed on the list some time ago, and one of the propositions was to > create interfaces like: > > > public interface IOFunction extends Function { > default R apply(T t) { > try { > return applyIO(t); > } catch (IOException e) { > throw new UncheckedIOException(e); > } > } > > R applyIO(T t) throws IOException; > } > > > public interface IORunnable extends Runnable { > default void run() { > try { > runIO(); > } catch (IOException e) { > throw new UncheckedIOException(e); > } > } > > void ruinIO() throws IOException; > } > > > ...etc, and use them in code like this: > > > List paths = ... > paths > .stream() > .flatMap((IOFunction>) path -> { > BufferedReader br = new BufferedReader(new FileReader(path)); > return br.lines().onClose((IORunnable) br::close); > }) > .forEach(System.out::println); > > > > Regards, Peter > > > From daniel.fuchs at oracle.com Tue Nov 19 10:23:35 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Nov 2013 11:23:35 +0100 Subject: RFR: 8028185 - XMLFormatter.format emits incorrect year Message-ID: <528B3C27.3000608@oracle.com> Hi, Please find below a webrev for: 8028185: XMLFormatter.format emits incorrect year https://bugs.openjdk.java.net/browse/JDK-8028185 The fix is trivial: http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ best regards, -- daniel From erik.gahlin at oracle.com Tue Nov 19 10:48:43 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Tue, 19 Nov 2013 10:48:43 +0000 Subject: hg: jdk8/tl/jdk: 8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt Message-ID: <20131119104913.3A8DB62699@hg.openjdk.java.net> Changeset: d6195774dd1f Author: egahlin Date: 2013-11-19 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6195774dd1f 8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt From weijun.wang at oracle.com Tue Nov 19 11:48:12 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 Nov 2013 19:48:12 +0800 Subject: "".split(":").length? Message-ID: <528B4FFC.9040700@oracle.com> Is this just changed? jdk8b118 shows 1 and now it's 0. Thanks Max From weijun.wang at oracle.com Tue Nov 19 11:57:51 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 Nov 2013 19:57:51 +0800 Subject: "".split(":").length? In-Reply-To: <528B4FFC.9040700@oracle.com> References: <528B4FFC.9040700@oracle.com> Message-ID: <528B523F.40605@oracle.com> On 11/19/13, 19:48, Weijun Wang wrote: > Is this just changed? jdk8b118 shows 1 and now it's 0. Typo. b114. > > Thanks > Max From Alan.Bateman at oracle.com Tue Nov 19 12:03:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 12:03:45 +0000 Subject: "".split(":").length? In-Reply-To: <528B4FFC.9040700@oracle.com> References: <528B4FFC.9040700@oracle.com> Message-ID: <528B53A1.2070705@oracle.com> On 19/11/2013 11:48, Weijun Wang wrote: > Is this just changed? jdk8b118 shows 1 and now it's 0. b118 or your own build? I wonder if you have 6559590 but not the un-do. -Alan. From weijun.wang at oracle.com Tue Nov 19 12:09:51 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 Nov 2013 20:09:51 +0800 Subject: "".split(":").length? In-Reply-To: <528B53A1.2070705@oracle.com> References: <528B4FFC.9040700@oracle.com> <528B53A1.2070705@oracle.com> Message-ID: <528B550F.2070808@oracle.com> b114: 1 my (previous) own build: 0 I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. So we are keeping this compatibility even if it does not look correct? Thanks Max On 11/19/13, 20:03, Alan Bateman wrote: > On 19/11/2013 11:48, Weijun Wang wrote: >> Is this just changed? jdk8b118 shows 1 and now it's 0. > b118 or your own build? I wonder if you have 6559590 but not the un-do. > > -Alan. From Alan.Bateman at oracle.com Tue Nov 19 12:20:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 12:20:17 +0000 Subject: RFR: 8028185 - XMLFormatter.format emits incorrect year In-Reply-To: <528B3C27.3000608@oracle.com> References: <528B3C27.3000608@oracle.com> Message-ID: <528B5781.1090907@oracle.com> On 19/11/2013 10:23, Daniel Fuchs wrote: > Hi, > > Please find below a webrev for: > > 8028185: XMLFormatter.format emits incorrect year > https://bugs.openjdk.java.net/browse/JDK-8028185 > > The fix is trivial: > http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ This one is a good reminder as to how fixing warnings can break things. The change looks good. The test looks okay too (checking for year rollover during the test seems excessive but harmless). -Alan. From Alan.Bateman at oracle.com Tue Nov 19 12:29:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 12:29:23 +0000 Subject: "".split(":").length? In-Reply-To: <528B550F.2070808@oracle.com> References: <528B4FFC.9040700@oracle.com> <528B53A1.2070705@oracle.com> <528B550F.2070808@oracle.com> Message-ID: <528B59A3.1030903@oracle.com> On 19/11/2013 12:09, Weijun Wang wrote: > b114: 1 > my (previous) own build: 0 > > I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. > So we are keeping this compatibility even if it does not look correct? I think it will require careful analysis to see what is possible (as there were several problems when this was pushed due to a dependency on the long standing behavior). -Alan. From sean.coffey at oracle.com Tue Nov 19 13:31:34 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 19 Nov 2013 13:31:34 +0000 Subject: RFR: 8028583 :Add helper methods to test libraries Message-ID: <528B6836.2070802@oracle.com> Looking to add two helper methods to the OpenJDK test libraries. I'm looking to clean up a closed src test case but these methods should be of use for future testcase development. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/ bug report : https://bugs.openjdk.java.net/browse/JDK-8028583 regards, Sean. From chris.hegarty at oracle.com Tue Nov 19 13:48:42 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 19 Nov 2013 13:48:42 +0000 Subject: hg: jdk8/tl/jdk: 7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled Message-ID: <20131119134856.8CE416269D@hg.openjdk.java.net> Changeset: d5ddde25d107 Author: tyan Date: 2013-11-19 13:46 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5ddde25d107 7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled Reviewed-by: chegar ! test/ProblemList.txt From balchandra.vaidya at oracle.com Tue Nov 19 14:07:10 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Tue, 19 Nov 2013 14:07:10 +0000 Subject: Request to review JDK-8028094 Message-ID: <528B708E.9090404@oracle.com> Hi, Here is one possible solution for the issue JDK-8028094. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ I am not sure pkill is available in all Unix flavor at /usr/bin directory, but it is present in Solaris and OEL 6. I have tested on Solaris and OEL and "sleep 6666" is no longer left over. Thanks Balchandra From alan.bateman at oracle.com Tue Nov 19 14:11:27 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 19 Nov 2013 14:11:27 +0000 Subject: hg: jdk8/tl/jdk: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Message-ID: <20131119141142.E7A146269E@hg.openjdk.java.net> Changeset: 2e574350a2b6 Author: alanb Date: 2013-11-19 14:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e574350a2b6 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! test/Makefile From alan.bateman at oracle.com Tue Nov 19 14:14:04 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 19 Nov 2013 14:14:04 +0000 Subject: hg: jdk8/tl: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Message-ID: <20131119141404.EAF086269F@hg.openjdk.java.net> Changeset: 9937f406e27e Author: alanb Date: 2013-11-19 14:11 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9937f406e27e 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! make/jprt.properties ! test/Makefile From chris.hegarty at oracle.com Tue Nov 19 14:19:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Nov 2013 14:19:35 +0000 Subject: RFR: 8028583 :Add helper methods to test libraries In-Reply-To: <528B6836.2070802@oracle.com> References: <528B6836.2070802@oracle.com> Message-ID: <528B7377.9030103@oracle.com> Looks good to me Sean, thanks for adding deleteFileIfExistsWithRetry. Trivially, you can replace oneLoopRun with a do {} while loop. -Chris. On 11/19/2013 01:31 PM, Se?n Coffey wrote: > Looking to add two helper methods to the OpenJDK test libraries. I'm > looking to clean up a closed src test case but these methods should be > of use for future testcase development. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/ > bug report : https://bugs.openjdk.java.net/browse/JDK-8028583 > > regards, > Sean. From chris.hegarty at oracle.com Tue Nov 19 14:23:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Nov 2013 14:23:19 +0000 Subject: Request to review JDK-8028094 In-Reply-To: <528B708E.9090404@oracle.com> References: <528B708E.9090404@oracle.com> Message-ID: <528B7457.106@oracle.com> Look ok to me Balchandra. I can sponsor this for you. -Chris. On 11/19/2013 02:07 PM, Balchandra Vaidya wrote: > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > I am not sure pkill is available in all Unix flavor at /usr/bin directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra From rob.mckenna at oracle.com Tue Nov 19 14:28:37 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 19 Nov 2013 14:28:37 +0000 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java Message-ID: <528B7595.6090201@oracle.com> Hi folks, Looking for a quick review for a test failure we're encountering. Seemingly no bar is too high for our test infrastructure. Hopefully this will put this particular failure to rest. http://cr.openjdk.java.net/~robm/8022206/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8022206 -Rob From sean.coffey at oracle.com Tue Nov 19 14:42:38 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 19 Nov 2013 14:42:38 +0000 Subject: RFR: 8028583 :Add helper methods to test libraries In-Reply-To: <528B7377.9030103@oracle.com> References: <528B6836.2070802@oracle.com> <528B7377.9030103@oracle.com> Message-ID: <528B78DE.60303@oracle.com> Thanks for review Chris. Will take your do while loop suggestion on board and push changes. regards, Sean. On 19/11/13 14:19, Chris Hegarty wrote: > Looks good to me Sean, thanks for adding deleteFileIfExistsWithRetry. > > Trivially, you can replace oneLoopRun with a do {} while loop. > > -Chris. > > On 11/19/2013 01:31 PM, Se?n Coffey wrote: >> Looking to add two helper methods to the OpenJDK test libraries. I'm >> looking to clean up a closed src test case but these methods should be >> of use for future testcase development. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/ >> bug report : https://bugs.openjdk.java.net/browse/JDK-8028583 >> >> regards, >> Sean. From Alan.Bateman at oracle.com Tue Nov 19 14:43:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 14:43:12 +0000 Subject: 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures Message-ID: <528B7900.4060309@oracle.com> The test tools/jar/JarEntryTime.java has been failing intermittently (but very rarely) for some time. The failure seems to be that the extracted time it out by more than 10 seconds compared to the original file time but it isn't always so (esp. when the test runs in a fraction of a second). I'd like to add instrumentation to the test so that if it fails again (and someone is good enough to report it) then we at least have the timestamps in the logs. The webrev with the proposed change is here: http://cr.openjdk.java.net/~alanb/8028589/webrev/ Thanks, Alan. From chris.hegarty at oracle.com Tue Nov 19 14:47:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Nov 2013 14:47:16 +0000 Subject: 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures In-Reply-To: <528B7900.4060309@oracle.com> References: <528B7900.4060309@oracle.com> Message-ID: <528B79F4.9070803@oracle.com> Looks good to me Alan. It will be nice to see why this test is actually failing. -Chris. On 11/19/2013 02:43 PM, Alan Bateman wrote: > > The test tools/jar/JarEntryTime.java has been failing intermittently > (but very rarely) for some time. The failure seems to be that the > extracted time it out by more than 10 seconds compared to the original > file time but it isn't always so (esp. when the test runs in a fraction > of a second). I'd like to add instrumentation to the test so that if it > fails again (and someone is good enough to report it) then we at least > have the timestamps in the logs. The webrev with the proposed change is > here: > http://cr.openjdk.java.net/~alanb/8028589/webrev/ > > Thanks, > Alan. From sean.coffey at oracle.com Tue Nov 19 14:49:32 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 19 Nov 2013 14:49:32 +0000 Subject: hg: jdk8/tl/jdk: 8028583: Add helper methods to test libraries Message-ID: <20131119144948.38D95626A2@hg.openjdk.java.net> Changeset: d1bb85f0a45a Author: coffeys Date: 2013-11-19 14:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1bb85f0a45a 8028583: Add helper methods to test libraries Reviewed-by: chegar ! test/java/rmi/testlibrary/TestLibrary.java ! test/lib/testlibrary/jdk/testlibrary/FileUtils.java From chris.hegarty at oracle.com Tue Nov 19 14:51:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Nov 2013 14:51:48 +0000 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java In-Reply-To: <528B7595.6090201@oracle.com> References: <528B7595.6090201@oracle.com> Message-ID: <528B7B04.7020906@oracle.com> The change looks ok to me. If for no reason other than to eliminate the timeout if this tests fails again in the future. -Chris. On 11/19/2013 02:28 PM, Rob McKenna wrote: > Hi folks, > > Looking for a quick review for a test failure we're encountering. > Seemingly no bar is too high for our test infrastructure. Hopefully this > will put this particular failure to rest. > > http://cr.openjdk.java.net/~robm/8022206/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8022206 > > -Rob > From balchandra.vaidya at oracle.com Tue Nov 19 15:04:06 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Tue, 19 Nov 2013 15:04:06 +0000 Subject: Request to review JDK-8028094 In-Reply-To: <528B7457.106@oracle.com> References: <528B708E.9090404@oracle.com> <528B7457.106@oracle.com> Message-ID: <528B7DE6.9010104@oracle.com> Thanks Chris. Regards Balchandra On 19/11/2013 14:23, Chris Hegarty wrote: > Look ok to me Balchandra. I can sponsor this for you. > > -Chris. > > On 11/19/2013 02:07 PM, Balchandra Vaidya wrote: >> >> Hi, >> >> Here is one possible solution for the issue JDK-8028094. >> http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ >> >> I am not sure pkill is available in all Unix flavor at /usr/bin >> directory, >> but it is present in Solaris and OEL 6. I have tested on Solaris >> and OEL and "sleep 6666" is no longer left over. >> >> >> Thanks >> Balchandra From daniel.fuchs at oracle.com Tue Nov 19 15:05:27 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Nov 2013 16:05:27 +0100 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java In-Reply-To: <528B7595.6090201@oracle.com> References: <528B7595.6090201@oracle.com> Message-ID: <528B7E37.9030105@oracle.com> Hi Rob, May I suggest changing System.out.println in Basic.fail into System.err.println? Or possibly printing the message on both out and err? This would ensure that the error message appears on System err before the stack trace - which might be better for diagnosis. -- daniel On 11/19/13 3:28 PM, Rob McKenna wrote: > Hi folks, > > Looking for a quick review for a test failure we're encountering. > Seemingly no bar is too high for our test infrastructure. Hopefully this > will put this particular failure to rest. > > http://cr.openjdk.java.net/~robm/8022206/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8022206 > > -Rob > From Alan.Bateman at oracle.com Tue Nov 19 15:05:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 15:05:23 +0000 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java In-Reply-To: <528B7595.6090201@oracle.com> References: <528B7595.6090201@oracle.com> Message-ID: <528B7E33.9080203@oracle.com> On 19/11/2013 14:28, Rob McKenna wrote: > Hi folks, > > Looking for a quick review for a test failure we're encountering. > Seemingly no bar is too high for our test infrastructure. Hopefully > this will put this particular failure to rest. > > http://cr.openjdk.java.net/~robm/8022206/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8022206 It's hard to believe that the 10s is exceeded but the change is harmless (and hence okay). -Alan From kumar.x.srinivasan at oracle.com Tue Nov 19 15:18:48 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 19 Nov 2013 15:18:48 +0000 Subject: hg: jdk8/tl/jdk: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm Message-ID: <20131119151900.74DC2626A6@hg.openjdk.java.net> Changeset: 40462a41b41b Author: ksrini Date: 2013-11-19 07:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40462a41b41b 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm Reviewed-by: dholmes, mchung ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java From chris.hegarty at oracle.com Tue Nov 19 15:32:22 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 19 Nov 2013 15:32:22 +0000 Subject: hg: jdk8/tl/jdk: 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves "sleep 6666" processes behind Message-ID: <20131119153235.07A90626A8@hg.openjdk.java.net> Changeset: cfbee8ee71bf Author: bvaidya Date: 2013-11-19 15:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfbee8ee71bf 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves "sleep 6666" processes behind Reviewed-by: chegar ! test/java/lang/ProcessBuilder/Basic.java From vincent.x.ryan at oracle.com Tue Nov 19 15:43:44 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 19 Nov 2013 15:43:44 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131119154408.4933E626A9@hg.openjdk.java.net> Changeset: e8daf5a83e42 Author: vinnie Date: 2013-11-19 15:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8daf5a83e42 8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to ${test.src} Reviewed-by: alanb, weijun ! test/sun/security/provider/KeyStore/DKSTest.java ! test/sun/security/provider/KeyStore/domains.cfg Changeset: bfd4e632eeda Author: vinnie Date: 2013-11-19 15:42 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd4e632eeda Merge From lowasser at google.com Tue Nov 19 15:50:46 2013 From: lowasser at google.com (Louis Wasserman) Date: Tue, 19 Nov 2013 07:50:46 -0800 Subject: Building sorted Spliterators for library authors Message-ID: Is there a convenient way of building a Spliterator SORTED by a given Comparator, from, say, an array? From what I can tell, SortedSet's default implementation uses a private IteratorSpliterator API. -- Louis Wasserman From sean.coffey at oracle.com Tue Nov 19 15:58:43 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 19 Nov 2013 15:58:43 +0000 Subject: RFR : 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently with "Address already in use" Message-ID: <528B8AB3.50803@oracle.com> Hope this is a simple one. This issue is a rare intermittent one : > - port 48250 is free > - exported registry: RegistryImpl[UnicastServerRef [liveRef: > [endpoint:[10.169.79.100:48250](local),objID:[0:0:0, 0]]]] > - port 48250 is in use > - unexported registry > java.net.BindException: Address already in use > at java.net.PlainSocketImpl.socketBind(Native Method) Even though we've just unexported the registry, the socket is still in use. I believe 1ms is too short a time to sleep to handle any environment issues. Let's try 1 second. bug report : https://bugs.openjdk.java.net/browse/JDK-8016728 proposed change : > t4 $hg diff > test/java/rmi/transport/closeServerSocket/CloseServerSocket.java > diff --git > a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java > b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java > --- a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java > +++ b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java > @@ -58,7 +58,7 @@ > verifyPortInUse(PORT); > UnicastRemoteObject.unexportObject(registry, true); > System.err.println("- unexported registry"); > - Thread.sleep(1); // work around BindException (bug?) > + Thread.sleep(1000); // work around BindException (bug?) > verifyPortFree(PORT); regards, Sean. From rob.mckenna at oracle.com Tue Nov 19 16:06:07 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 19 Nov 2013 16:06:07 +0000 Subject: hg: jdk8/tl/jdk: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java Message-ID: <20131119160620.363B5626AB@hg.openjdk.java.net> Changeset: 63b696dafc8a Author: robm Date: 2013-11-19 15:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63b696dafc8a 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java Reviewed-by: chegar, alanb ! test/java/lang/ProcessBuilder/Basic.java From xueming.shen at oracle.com Tue Nov 19 16:15:43 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 19 Nov 2013 08:15:43 -0800 Subject: "".split(":").length? In-Reply-To: <528B550F.2070808@oracle.com> References: <528B4FFC.9040700@oracle.com> <528B53A1.2070705@oracle.com> <528B550F.2070808@oracle.com> Message-ID: <528B8EAF.9060500@oracle.com> Yes, I have to pull it back due to the compatibility concern. It appears the jdk source code itself has couple places depending on this "incorrect" behavior. The typical usage is "".split(...)[0], in which the code tries to access the 0th element without even checking the return length. I may re-visit this in jdk9, and may have to provide some mechanism for any possible compatibility complain, if we decide to "fix" it. -Sherman On 11/19/13 4:09 AM, Weijun Wang wrote: > b114: 1 > my (previous) own build: 0 > > I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. > So we are keeping this compatibility even if it does not look correct? > > Thanks > Max > > On 11/19/13, 20:03, Alan Bateman wrote: >> On 19/11/2013 11:48, Weijun Wang wrote: >>> Is this just changed? jdk8b118 shows 1 and now it's 0. >> b118 or your own build? I wonder if you have 6559590 but not the un-do. >> >> -Alan. From chris.hegarty at oracle.com Tue Nov 19 16:12:23 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Nov 2013 16:12:23 +0000 Subject: RFR : 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently with "Address already in use" In-Reply-To: <528B8AB3.50803@oracle.com> References: <528B8AB3.50803@oracle.com> Message-ID: <528B8DE7.3020405@oracle.com> Looks ok to me. -Chris. On 11/19/2013 03:58 PM, Se?n Coffey wrote: > Hope this is a simple one. This issue is a rare intermittent one : >> - port 48250 is free >> - exported registry: RegistryImpl[UnicastServerRef [liveRef: >> [endpoint:[10.169.79.100:48250](local),objID:[0:0:0, 0]]]] >> - port 48250 is in use >> - unexported registry >> java.net.BindException: Address already in use >> at java.net.PlainSocketImpl.socketBind(Native Method) > > Even though we've just unexported the registry, the socket is still in > use. I believe 1ms is too short a time to sleep to handle any > environment issues. Let's try 1 second. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8016728 > proposed change : > >> t4 $hg diff >> test/java/rmi/transport/closeServerSocket/CloseServerSocket.java >> diff --git >> a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java >> b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java >> --- a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java >> +++ b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java >> @@ -58,7 +58,7 @@ >> verifyPortInUse(PORT); >> UnicastRemoteObject.unexportObject(registry, true); >> System.err.println("- unexported registry"); >> - Thread.sleep(1); // work around BindException (bug?) >> + Thread.sleep(1000); // work around BindException (bug?) >> verifyPortFree(PORT); > > regards, > Sean. > > From sean.coffey at oracle.com Tue Nov 19 16:30:26 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 19 Nov 2013 16:30:26 +0000 Subject: hg: jdk8/tl/jdk: 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently Message-ID: <20131119163041.0246A626AD@hg.openjdk.java.net> Changeset: f2ccd3530476 Author: coffeys Date: 2013-11-19 16:22 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2ccd3530476 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently Reviewed-by: chegar ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java From paul.sandoz at oracle.com Tue Nov 19 16:44:40 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 19 Nov 2013 17:44:40 +0100 Subject: Building sorted Spliterators for library authors In-Reply-To: References: Message-ID: On Nov 19, 2013, at 4:50 PM, Louis Wasserman wrote: > Is there a convenient way of building a Spliterator SORTED by a given > Comparator, from, say, an array? Unfortunately not. There are no factory methods in j.u.Splitrerators that accept Comparator as a parameter, and as you note below we do not expose the Spliterator impls. You could wrap/proxy a Spliterator instance, but i suspect you will find that ugly, so you probably need to roll your own implementation and duplicate as appropriate from the JDK impls. > From what I can tell, SortedSet's default > implementation uses a private IteratorSpliterator API. > Yes, and that is a poorly splitting Spliterator since the default implementation can only obtain elements from the Iterator. If your Spliterator covers an array you will probably want to implement better splitting. Hth, Paul. From rob.mckenna at oracle.com Tue Nov 19 16:46:21 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 19 Nov 2013 16:46:21 +0000 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug Message-ID: <528B95DD.5090500@oracle.com> Hi folks, Running this test with fastdebug binaries results in a few warning messages getting lumped into the commandOutput. I've decided to filter these test wide. https://bugs.openjdk.java.net/browse/JDK-6703075 http://cr.openjdk.java.net/~robm/6703075/webrev.01/ -Rob From alan.bateman at oracle.com Tue Nov 19 15:12:37 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 19 Nov 2013 15:12:37 +0000 Subject: hg: jdk8/tl/jdk: 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures Message-ID: <20131119151253.8563A626A4@hg.openjdk.java.net> Changeset: 36821ee241a2 Author: alanb Date: 2013-11-19 15:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36821ee241a2 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures Reviewed-by: chegar ! test/tools/jar/JarEntryTime.java From mandy.chung at oracle.com Tue Nov 19 17:40:20 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Nov 2013 09:40:20 -0800 Subject: RFR: 8028185 - XMLFormatter.format emits incorrect year In-Reply-To: <528B3C27.3000608@oracle.com> References: <528B3C27.3000608@oracle.com> Message-ID: <528BA284.5010100@oracle.com> On 11/19/13 2:23 AM, Daniel Fuchs wrote: > Hi, > > Please find below a webrev for: > > 8028185: XMLFormatter.format emits incorrect year > https://bugs.openjdk.java.net/browse/JDK-8028185 > > The fix is trivial: > http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ Looks good. Nit: the test can use StringBuilder which is generally in preference to StringBuffer unless synchronization is required. The kind of warning fix [1] causing this regression should probably have a regression test to go with it to verify the change. thanks Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36 From michael.x.mcmahon at oracle.com Tue Nov 19 17:51:03 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 19 Nov 2013 17:51:03 +0000 Subject: hg: jdk8/tl/jdk: 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing Message-ID: <20131119175115.950A1626B3@hg.openjdk.java.net> Changeset: 79e975dfeb8a Author: michaelm Date: 2013-11-19 17:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79e975dfeb8a 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing Reviewed-by: alanb ! test/java/net/Socket/LingerTest.java From ivan.gerasimov at oracle.com Tue Nov 19 17:58:28 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Nov 2013 21:58:28 +0400 Subject: RFR [6968459] JNDI timeout fails before timeout is reached Message-ID: <528BA6C4.6000702@oracle.com> Hello all! Would you please help review a fix for the bug? https://bugs.openjdk.java.net/browse/JDK-6968459 It was reported that creating new InitialLdapContext() can fail with "javax.naming.NamingException: LDAP response read timed out, timeout used:30000ms", even though the specified timeout hadn't been elapsed. The fix was provided by the filer of the bug some time ago. Here's the webrev with this fix: http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ Sincerely yours, Ivan Gerasimov From alexander.zuev at oracle.com Tue Nov 19 18:06:03 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 19 Nov 2013 18:06:03 +0000 Subject: hg: jdk8/tl/jdk: 8027900: pack200 option is broken due to the incorrect makefile definition for its driver Message-ID: <20131119180616.795F1626B9@hg.openjdk.java.net> Changeset: 5aa853ca08a8 Author: kizune Date: 2013-11-19 22:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aa853ca08a8 8027900: pack200 option is broken due to the incorrect makefile definition for its driver Reviewed-by: ksrini, ihse ! make/CompileLaunchers.gmk From ivan.gerasimov at oracle.com Tue Nov 19 18:07:42 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 19 Nov 2013 22:07:42 +0400 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <528BA6C4.6000702@oracle.com> References: <528BA6C4.6000702@oracle.com> Message-ID: <528BA8EE.9000301@oracle.com> > Hello all! > > Would you please help review a fix for the bug? > https://bugs.openjdk.java.net/browse/JDK-6968459 > > It was reported that creating new InitialLdapContext() can fail with > "javax.naming.NamingException: LDAP response read timed out, timeout > used:30000ms", even though the specified timeout hadn't been elapsed. > > The fix was provided by the filer of the bug some time ago. A correction: the fix was recently provided by IBM. > Here's the webrev with this fix: > http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ > > Sincerely yours, > Ivan Gerasimov > > > From daniel.fuchs at oracle.com Tue Nov 19 18:17:13 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Nov 2013 19:17:13 +0100 Subject: RFR: 8028185 - XMLFormatter.format emits incorrect year In-Reply-To: <528BA284.5010100@oracle.com> References: <528B3C27.3000608@oracle.com> <528BA284.5010100@oracle.com> Message-ID: <528BAB29.1020802@oracle.com> On 11/19/13 6:40 PM, Mandy Chung wrote: > On 11/19/13 2:23 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a webrev for: >> >> 8028185: XMLFormatter.format emits incorrect year >> https://bugs.openjdk.java.net/browse/JDK-8028185 >> >> The fix is trivial: >> http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ > Thanks for the review Mandy! > Looks good. Nit: the test can use StringBuilder which is generally in > preference to StringBuffer unless synchronization is required. Oh yes good catch - I will change it before pushing... > > The kind of warning fix [1] causing this regression should probably have > a regression test to go with it to verify the change. > > thanks > Mandy > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36 From vincent.x.ryan at oracle.com Tue Nov 19 17:56:25 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 19 Nov 2013 17:56:25 +0000 Subject: hg: jdk8/tl/jdk: 8015571: OCSP validation fails if ocsp.responderCertSubjectName is set Message-ID: <20131119175637.7FF9F626B4@hg.openjdk.java.net> Changeset: f8b24e1a609e Author: vinnie Date: 2013-11-19 17:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b24e1a609e 8015571: OCSP validation fails if ocsp.responderCertSubjectName is set Reviewed-by: mullan, xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/x509/X509CertImpl.java From mandy.chung at oracle.com Tue Nov 19 18:21:34 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 19 Nov 2013 18:21:34 +0000 Subject: hg: jdk8/tl/jdk: 8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt Message-ID: <20131119182147.C2F65626BC@hg.openjdk.java.net> Changeset: 48c61808374f Author: mchung Date: 2013-11-19 10:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48c61808374f 8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt Reviewed-by: sla ! test/ProblemList.txt From roger.riggs at oracle.com Tue Nov 19 18:29:28 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 19 Nov 2013 18:29:28 +0000 Subject: hg: jdk8/tl/jdk: 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again Message-ID: <20131119182942.7F43E626BE@hg.openjdk.java.net> Changeset: 3f47e393e1dd Author: rriggs Date: 2013-11-19 13:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f47e393e1dd 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again Summary: Correct to use the test.class.path instead of test.classes Reviewed-by: alanb, chegar ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java From alexander.zuev at oracle.com Tue Nov 19 18:15:02 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 19 Nov 2013 18:15:02 +0000 Subject: hg: jdk8/tl/langtools: 6726154: javadoc generated with incorrect version in comment Message-ID: <20131119181507.11E2C626BA@hg.openjdk.java.net> Changeset: f42a22e2b2cd Author: kizune Date: 2013-11-19 22:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f42a22e2b2cd 6726154: javadoc generated with incorrect version in comment Reviewed-by: jjg, bpatel, erikj, tbell ! make/BuildLangtools.gmk ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java From david.holmes at oracle.com Tue Nov 19 19:03:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Nov 2013 05:03:03 +1000 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <528B016A.3080408@oracle.com> References: <528B016A.3080408@oracle.com> Message-ID: <528BB5E7.4050605@oracle.com> Hi, Attachments are stripped. Please post on cr.openjdk.java.net (get a colleague to host this if you don't have an account yet.) Thanks, David On 19/11/2013 4:12 PM, srikalyan chandrashekar wrote: > Hi all, I am working on bug JDK-6772009 > . > > Root Cause: > The timeout value gives too much grace period on faster machines on > which the "TO BE INTERRUPTED" threads complete faster before being > interrupted at right time. > > Suggested Fix: > a) Decrease the timeout from 100 to 50ms which will ensure that the test > will pass even on faster machines , and ensures the threads will be > canceled when running and anyways there is a Barrier to ensure the test > threads all complete gracefully. > Miscellaneous fixes > b) Convert result from int to long(possible integer overflow otherwise) > c) Catch BrokenBarrierException in more granular fashion in > ReentrantLockLoop to update and print the results (which will be missed > otherwise) > Add more diagnostics > d) Assign names to threads > e) Print which threads update the 'completed' variable. > > I have attached the webrev for convenience as the changes are > interleaved and is best viewed as sdiff. > Please let me know if you have any comments or suggestions. > > > > Thank you > From dan.xu at oracle.com Tue Nov 19 19:08:34 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 19 Nov 2013 11:08:34 -0800 Subject: RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms Message-ID: <528BB732.3010306@oracle.com> Hi All, We have java/io/pathNames/GeneralWin32.java testcase to do the general exhaustive test of pathname handling on windows. I am adding a new test GeneralSolaris.java to test the pathname handling in unix-like platforms. In the changes, I also make sure the test can run successfully in concurrency mode. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028631 Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/ -Dan From daniel.fuchs at oracle.com Tue Nov 19 19:11:47 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 19 Nov 2013 19:11:47 +0000 Subject: hg: jdk8/tl/jdk: 8028185: XMLFormatter.format emits incorrect year Message-ID: <20131119191201.11AAF626C0@hg.openjdk.java.net> Changeset: 67d742c75971 Author: dfuchs Date: 2013-11-19 20:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67d742c75971 8028185: XMLFormatter.format emits incorrect year Summary: Fixes a regression where the year in the date was increased by 1900. Reviewed-by: alanb, mchung ! src/share/classes/java/util/logging/XMLFormatter.java + test/java/util/logging/XMLFormatterDate.java From Lance.Andersen at oracle.com Tue Nov 19 19:23:50 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 19 Nov 2013 14:23:50 -0500 Subject: RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms In-Reply-To: <528BB732.3010306@oracle.com> References: <528BB732.3010306@oracle.com> Message-ID: <615A360B-42A8-4A77-8F2D-15909A4DB265@oracle.com> The changes seem OK. I did not run the tests though On Nov 19, 2013, at 2:08 PM, Dan Xu wrote: > Hi All, > > We have java/io/pathNames/GeneralWin32.java testcase to do the general exhaustive test of pathname handling on windows. I am adding a new test GeneralSolaris.java to test the pathname handling in unix-like platforms. In the changes, I also make sure the test can run successfully in concurrency mode. Please help review it. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028631 > Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/ > > -Dan -------------- next part -------------- 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 yumin.qi at oracle.com Mon Nov 11 19:21:25 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 11 Nov 2013 11:21:25 -0800 Subject: Bug 8027734 In-Reply-To: <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> Message-ID: <52812E35.605@oracle.com> Hi, Joel This bug is a SQE testing bug, see https://bugs.openjdk.java.net/browse/JDK-8027734 I have commented with the exception stacktrace. It only fails when defmeth set call through reflection and passed with other two modes: -mode invoke and -mode direct The problem I got is from this part: Reflection.java:118 (verifyMemberAccess) if (!Modifier.isPublic(getClassAccessFlags(memberClass))) { // here memberClass is p1.I which is not a public isSameClassPackage = isSameClassPackage(currentClass, memberClass); // Not in same class gotIsSameClassPackage = true; if (!isSameClassPackage) { return false; // so we return false. } } // At this point we know that currentClass can access memberClass. if (Modifier.isPublic(modifiers)) { return true; } memberClass is p1.I is a private interface, but its sub p1.J is a public interface. The default method is in I: /* In package1: * package p1; * interface I { * default int m() { return 10; }; * } * public interface J extends I {}; * * In package2: * class A implements p1.J {} * A myA = new A; * myA.m(); // should return 10, not throw IllegalAccessError * B myB = new B; // not related */ Now defmeth caller is TestContext, which is not in same package with interface I, this leads verify failed. 'modifiers' is public, but we check if the caller class and calee class in same package first and returned false, since they do not exist in same package. If we check the following statement first, we will return true. I am not familiar with this code, can you or some other people on the list give comments? Thanks Yumin On 10/10/2013 6:02 AM, Joel Borggren-Franck wrote: > Hi Karen, > > I agree with the others, the code looks good though I like Paul's > suggestion. > > Silly question perhaps, do you know if we have good test coverage on > actually reflectively invoking a Method more than 15 times? > > cheers > /Joel > > On 2013-10-09, Karen Kinnear wrote: >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026213 >> >> Summary: >> Reflection generates code dynamically to speed up reflection processing after startup. The first >> 15 runs of a reflection call use the vm code path, after that we use the generated code path, which >> needs to use invokespecial on private methods in interfaces. >> >> Tested: >> Test attached to the bug >> >> Also - all the 8011311 private method testing was run with this in the build: >> Robert Field's TypeTest >> 8025475 test >> defmeth privatemethodstest with reflection >> John Rose's intfbug >> jtreg: java.util, java.lang >> jck vm, lang >> >> thanks, >> Karen >> >> From yumin.qi at oracle.com Tue Nov 12 16:19:57 2013 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 12 Nov 2013 08:19:57 -0800 Subject: declaring class of a default method Was: Bug 8027734 In-Reply-To: <20131112142507.GK17332@oracle.com> References: <0C8B209D-C1B6-4E48-A3A4-5F9AC9EC8217@oracle.com> <20131010130254.GT1969@jfranck-desktop.jrpg.bea.com> <52812E35.605@oracle.com> <20131112142507.GK17332@oracle.com> Message-ID: <5282552D.1070804@oracle.com> Thanks. I will look back in hotspot. Yumin On 11/12/2013 6:25 AM, Joel Borggren-Franck wrote: > Hi Yumin, > > Basically this is due to a difference in declaring class for a Method > representing a default method vs a normal Method. > > On 2013-11-11, Yumin Qi wrote: >> Hi, Joel >> >> This bug is a SQE testing bug, see >> https://bugs.openjdk.java.net/browse/JDK-8027734 >> >> >> I have commented with the exception stacktrace. >> > This is easy to reproduce without VM sqe frameworks: > > p1/I.java: > > package p1; > interface I { > default void m() { > System.out.println("Foo!"); > } > } > > p2/J.java: > > package p1; > public interface J extends I {} > > p2/C.java: > > package p2; > import p1.J; > import java.lang.reflect.*; > public class C { > public static void main(String[] args) throws Exception { > Method m = J.class.getMethod("m", (Class[])null); > System.out.println(m + " declaring class: " + m.getDeclaringClass()); > m.invoke(new J() {}); > } > } > > Compiling and running this will print: > > $ java p2.C > public default void p1.I.m() declaring class: interface p1.I > Exception in thread "main" java.lang.IllegalAccessException: Class p2.C > can not access a member of class p1.I with modifiers "public" > at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101) > at java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295) > at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287) > at java.lang.reflect.Method.invoke(Method.java:476) > at p2.C.main(C.java:8) > > Note that the delcaring class of m is "interface p1.I". > > Changing this to classes instead: > > package p3; > class A { > public void m() { > System.out.println("Foo!"); > } > } > > package p3; > public class B extends A {} > > package p4; > import p3.B; > import java.lang.reflect.*; > public class C2 { > public static void main(String[] args) throws Exception { > Method m = B.class.getMethod("m", (Class[])null); > System.out.println(m + " declaring class: " + m.getDeclaringClass()); > m.invoke(new B() {}); > } > } > > And running this gives: > > java p4.C2 > public void p3.B.m() declaring class: class p3.B > Foo! > > Note that even though m is lexically declared in class A > m.getDeclaringClass() outputs _p3.B_ as it's declaring class. > > I'm not sure how we should fix this, but my first impression is that the > VM is wrong here when creating the default method Method in the > interface example. > > cheers > /Joel From yuri.nesterenko at oracle.com Mon Nov 18 13:01:09 2013 From: yuri.nesterenko at oracle.com (yuri.nesterenko at oracle.com) Date: Mon, 18 Nov 2013 13:01:09 +0000 Subject: hg: jdk8/tl/jdk: 8028049: Tidy warnings cleanup for packages java.nio/java.io Message-ID: <20131118130121.9329A62663@hg.openjdk.java.net> Changeset: 19ff80da8283 Author: yan Date: 2013-11-18 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19ff80da8283 8028049: Tidy warnings cleanup for packages java.nio/java.io Reviewed-by: alanb, darcy Contributed-by: Sergey Lugovoy ! src/share/classes/java/io/EOFException.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/package.html From balchandra.vaidya at oracle.com Tue Nov 19 12:21:14 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Tue, 19 Nov 2013 12:21:14 +0000 Subject: Request to review JDK-8028094 Message-ID: <528B57BA.3060102@oracle.com> Hi, Here is one possible solution for the issue JDK-8028094. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ I am not sure pkill is available in all Unix flavor at /usr/bin directory, but it is present in Solaris and OEL 6. I have tested on Solaris and OEL and "sleep 6666" is no longer left over. Thanks Balchandra From Alan.Bateman at oracle.com Tue Nov 19 19:27:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 19:27:09 +0000 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug In-Reply-To: <528B95DD.5090500@oracle.com> References: <528B95DD.5090500@oracle.com> Message-ID: <528BBB8D.9040500@oracle.com> On 19/11/2013 16:46, Rob McKenna wrote: > Hi folks, > > Running this test with fastdebug binaries results in a few warning > messages getting lumped into the commandOutput. I've decided to filter > these test wide. > > https://bugs.openjdk.java.net/browse/JDK-6703075 > http://cr.openjdk.java.net/~robm/6703075/webrev.01/ > > -Rob > Having warning messages emitted by the VM and interfering with application or test output is annoying. What you have is okay for now but perhaps there is an option to redirect them to elsewhere. -Alan From martinrb at google.com Tue Nov 19 19:29:59 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 11:29:59 -0800 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug In-Reply-To: <528BBB8D.9040500@oracle.com> References: <528B95DD.5090500@oracle.com> <528BBB8D.9040500@oracle.com> Message-ID: Hold on - I'll try to get you alternate fix. On Tue, Nov 19, 2013 at 11:27 AM, Alan Bateman wrote: > On 19/11/2013 16:46, Rob McKenna wrote: > >> Hi folks, >> >> Running this test with fastdebug binaries results in a few warning >> messages getting lumped into the commandOutput. I've decided to filter >> these test wide. >> >> https://bugs.openjdk.java.net/browse/JDK-6703075 >> http://cr.openjdk.java.net/~robm/6703075/webrev.01/ >> >> -Rob >> >> Having warning messages emitted by the VM and interfering with > application or test output is annoying. What you have is okay for now but > perhaps there is an option to redirect them to elsewhere. > > -Alan > From daniel.fuchs at oracle.com Tue Nov 19 19:35:37 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Nov 2013 20:35:37 +0100 Subject: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 Message-ID: <528BBD89.1070107@oracle.com> Hi, Please find below a fix for: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 This bug complains that java/util/logging/CheckLockLocationTest.java has been seen failing on a solaris 10 machine, with message: java.lang.RuntimeException: Test failed: should not have been able to create FileHandler for %t/non-writable-dir/log.log in non-writable directory. at CheckLockLocationTest.runTests(CheckLockLocationTest.java:84) at CheckLockLocationTest.main(CheckLockLocationTest.java:57) ... I have no idea why this test failed as I have never seen it failing myself. I suspect however that for some reason the 'non-writable-dir' that the test attempted to create was in fact writable. I am therefore proposing to add an additional check in the test's setUp() method, in order to verify that the directory is indeed not writable. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ caveat: I haven't tested my changes on Solaris yet, but I will do so before pushing :-) -- daniel From Alan.Bateman at oracle.com Tue Nov 19 19:37:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 19:37:30 +0000 Subject: RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms In-Reply-To: <528BB732.3010306@oracle.com> References: <528BB732.3010306@oracle.com> Message-ID: <528BBDFA.9070800@oracle.com> On 19/11/2013 19:08, Dan Xu wrote: > Hi All, > > We have java/io/pathNames/GeneralWin32.java testcase to do the general > exhaustive test of pathname handling on windows. I am adding a new > test GeneralSolaris.java to test the pathname handling in unix-like > platforms. In the changes, I also make sure the test can run > successfully in concurrency mode. Please help review it. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028631 > Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/ This looks okay to me and I'm happy to see this test fixed to no longer walk into other directories when running tests concurrently. -Alan. From martinrb at google.com Tue Nov 19 19:42:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 11:42:40 -0800 Subject: Request to review JDK-8028094 In-Reply-To: <528B708E.9090404@oracle.com> References: <528B708E.9090404@oracle.com> Message-ID: It would be nice if every request for review included URLs for the bug report (in addition to the webrev). The existing test has a check for the existence of /bin/sleep before running it. We should do the same for any other Unix command like pkill. But we should also try to think of better solutions than having to use pkill. On Tue, Nov 19, 2013 at 6:07 AM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > I am not sure pkill is available in all Unix flavor at /usr/bin directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra > From martinrb at google.com Tue Nov 19 19:44:13 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 11:44:13 -0800 Subject: Request to review JDK-8028094 In-Reply-To: <528B708E.9090404@oracle.com> References: <528B708E.9090404@oracle.com> Message-ID: Is there an actual problem caused by all those sleep processes, or are you just trying to be tidy? On Tue, Nov 19, 2013 at 6:07 AM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > I am not sure pkill is available in all Unix flavor at /usr/bin directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra > From martinrb at google.com Tue Nov 19 19:58:46 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 11:58:46 -0800 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug In-Reply-To: References: <528B95DD.5090500@oracle.com> <528BBB8D.9040500@oracle.com> Message-ID: I propose a fix like the diff below, that asks the VM to separate regular output and JVM output into stdout and stderr, so that we can do matching on each independently, and so that we can rely on stdout not being corrupted by JVM output. @@ -555,9 +555,10 @@ System.getProperty("java.class.path"); private static final List javaChildArgs = - Arrays.asList(new String[] - { javaExe, "-classpath", absolutifyPath(classpath), - "Basic$JavaChild"}); + Arrays.asList(javaExe, + "-XX:+DisplayVMOutputToStderr", + "-classpath", absolutifyPath(classpath), + "Basic$JavaChild"); private static void testEncoding(String encoding, String tested) { try { @@ -1593,8 +1594,8 @@ javaExe)); list.add("ArrayOOME"); ProcessResults r = run(new ProcessBuilder(list)); - check(r.out().contains("java.lang.OutOfMemoryError:")); - check(r.out().contains(javaExe)); + check(r.err().contains("java.lang.OutOfMemoryError:")); + check(r.err().contains(javaExe)); check(r.err().contains(System.getProperty("java.version"))); equal(r.exitValue(), 1); } catch (Throwable t) { unexpected(t); } On Tue, Nov 19, 2013 at 11:29 AM, Martin Buchholz wrote: > Hold on - I'll try to get you alternate fix. > > > On Tue, Nov 19, 2013 at 11:27 AM, Alan Bateman wrote: > >> On 19/11/2013 16:46, Rob McKenna wrote: >> >>> Hi folks, >>> >>> Running this test with fastdebug binaries results in a few warning >>> messages getting lumped into the commandOutput. I've decided to filter >>> these test wide. >>> >>> https://bugs.openjdk.java.net/browse/JDK-6703075 >>> http://cr.openjdk.java.net/~robm/6703075/webrev.01/ >>> >>> -Rob >>> >>> Having warning messages emitted by the VM and interfering with >> application or test output is annoying. What you have is okay for now but >> perhaps there is an option to redirect them to elsewhere. >> >> -Alan >> > > From mandy.chung at oracle.com Tue Nov 19 20:04:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Nov 2013 12:04:24 -0800 Subject: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 In-Reply-To: <528BBD89.1070107@oracle.com> References: <528BBD89.1070107@oracle.com> Message-ID: <528BC448.4070603@oracle.com> On 11/19/2013 11:35 AM, Daniel Fuchs wrote: > > I am therefore proposing to add an additional check in the test's > setUp() method, in order to verify that the directory is indeed > not writable. > It may be useful to print the owner of the directory in case if it's running with root permission. > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ > 175 final boolean nonWritable = nonWritableDir.setWritable(false); 176 final boolean isWritable = Files.isWritable(path); 177 if (nonWritable && !isWritable) { Perhaps it should assert isWriteable if File.setWriteable returns true. Mandy From daniel.fuchs at oracle.com Tue Nov 19 20:12:55 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Nov 2013 21:12:55 +0100 Subject: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 In-Reply-To: <528BC448.4070603@oracle.com> References: <528BBD89.1070107@oracle.com> <528BC448.4070603@oracle.com> Message-ID: <528BC647.1020508@oracle.com> On 11/19/13 9:04 PM, Mandy Chung wrote: > > On 11/19/2013 11:35 AM, Daniel Fuchs wrote: >> >> I am therefore proposing to add an additional check in the test's >> setUp() method, in order to verify that the directory is indeed >> not writable. >> > > It may be useful to print the owner of the directory in case if it's > running with root permission. OK - I assume I can find that by foraging into the nio Files API? >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ >> > > 175 final boolean nonWritable = > nonWritableDir.setWritable(false); > 176 final boolean isWritable = Files.isWritable(path); > 177 if (nonWritable && !isWritable) { > > Perhaps it should assert isWriteable if File.setWriteable returns true. I'm not sure we want to fail in that case. I mean - the bug is complaining that the test fails in the first place ;-) I would be inclined to have the test simply skip the non-writable test in both cases where it detects that it didn't manage to create a non-writable dir. -- daniel > > Mandy From martinrb at google.com Tue Nov 19 20:14:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 12:14:45 -0800 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java In-Reply-To: <528B7E33.9080203@oracle.com> References: <528B7595.6090201@oracle.com> <528B7E33.9080203@oracle.com> Message-ID: In jsr166 tests we have mostly switched to 10 second timeouts to mean "forever". But in ProcessBuilder tests we are starting up new java processes with their well-known startup problems, so using a much larger value of "forever" seems reasonable. I vote for 1 minute. You can write waitFor(1, TimeUnit.MINUTES); On Tue, Nov 19, 2013 at 7:05 AM, Alan Bateman wrote: > On 19/11/2013 14:28, Rob McKenna wrote: > >> Hi folks, >> >> Looking for a quick review for a test failure we're encountering. >> Seemingly no bar is too high for our test infrastructure. Hopefully this >> will put this particular failure to rest. >> >> http://cr.openjdk.java.net/~robm/8022206/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8022206 >> > It's hard to believe that the 10s is exceeded but the change is harmless > (and hence okay). > > -Alan > From mandy.chung at oracle.com Tue Nov 19 20:26:52 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Nov 2013 12:26:52 -0800 Subject: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 In-Reply-To: <528BC647.1020508@oracle.com> References: <528BBD89.1070107@oracle.com> <528BC448.4070603@oracle.com> <528BC647.1020508@oracle.com> Message-ID: <528BC98C.5090609@oracle.com> On 11/19/2013 12:12 PM, Daniel Fuchs wrote: > On 11/19/13 9:04 PM, Mandy Chung wrote: >> >> On 11/19/2013 11:35 AM, Daniel Fuchs wrote: >>> >>> I am therefore proposing to add an additional check in the test's >>> setUp() method, in order to verify that the directory is indeed >>> not writable. >>> >> >> It may be useful to print the owner of the directory in case if it's >> running with root permission. > > OK - I assume I can find that by foraging into the nio Files API? > I think you could use java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may need to deal with "acl" vs "posix". >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ >>> >> >> 175 final boolean nonWritable = >> nonWritableDir.setWritable(false); >> 176 final boolean isWritable = Files.isWritable(path); >> 177 if (nonWritable && !isWritable) { >> >> Perhaps it should assert isWriteable if File.setWriteable returns true. > > I'm not sure we want to fail in that case. I mean - the bug > is complaining that the test fails in the first place ;-) > I would be inclined to have the test simply skip the non-writable > test in both cases where it detects that it didn't manage to create > a non-writable dir. If File.setWriteable returns true and isWriteable is false, it'd be a bug that we want to know about. Perhaps you want to log if the directory is writeable or not instead of adding it to the check. Mandy From ivan.gerasimov at oracle.com Tue Nov 19 20:42:22 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 20 Nov 2013 00:42:22 +0400 Subject: RFR [8027348] (process) Enhancement of handling async close of ProcessInputStream Message-ID: <528BCD2E.5090209@oracle.com> Hello all! May I have a review for the improvement contributed by Martin Buchholz? https://bugs.openjdk.java.net/browse/JDK-8027348 First, it the change performs the code cleanup, and second it makes the test much faster. This should also help to resolve the issue with the current version of the test, which was reported to fail intermittently by timeout. https://bugs.openjdk.java.net/browse/JDK-8028574 Here's the webrev with the change: http://cr.openjdk.java.net/~igerasim/8027348/0/webrev/ Sincerely yours, Ivan Gerasimov From joe.darcy at oracle.com Tue Nov 19 20:52:12 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 Nov 2013 12:52:12 -0800 Subject: RFR: JDK-8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType In-Reply-To: <20131115122636.GB7721@oracle.com> References: <20131115122636.GB7721@oracle.com> Message-ID: <528BCF7C.6030301@oracle.com> Hi Joel, The change looks good; approved to go back. Thanks, -Joe On 11/15/2013 04:26 AM, Joel Borggren-Franck wrote: > Hi > > Please review this javadoc clarification for j.l.annnotation.Target and > j.l.annotation.ElementType as part of the type annotations work. > > Webrev: http://cr.openjdk.java.net/~jfranck/8027413/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8027413 > > This is based on the update to JLS from Alex: > http://cr.openjdk.java.net/~abuckley/308.pdf (section 1.6). > > cheers > /Joel From martinrb at google.com Tue Nov 19 20:56:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 12:56:45 -0800 Subject: RFR [8027348] (process) Enhancement of handling async close of ProcessInputStream In-Reply-To: <528BCD2E.5090209@oracle.com> References: <528BCD2E.5090209@oracle.com> Message-ID: Ivan, Thanks for taking ownership of my proposed change. Looks good to me! (I can't actually push changes like this myself because I only do Linux these days) On Tue, Nov 19, 2013 at 12:42 PM, Ivan Gerasimov wrote: > Hello all! > > May I have a review for the improvement contributed by Martin Buchholz? > https://bugs.openjdk.java.net/browse/JDK-8027348 > > First, it the change performs the code cleanup, and second it makes the > test much faster. > This should also help to resolve the issue with the current version of the > test, which was reported to fail intermittently by timeout. > https://bugs.openjdk.java.net/browse/JDK-8028574 > > Here's the webrev with the change: > http://cr.openjdk.java.net/~igerasim/8027348/0/webrev/ > > Sincerely yours, > Ivan Gerasimov > > From daniel.fuchs at oracle.com Tue Nov 19 20:58:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 19 Nov 2013 21:58:08 +0100 Subject: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 In-Reply-To: <528BC98C.5090609@oracle.com> References: <528BBD89.1070107@oracle.com> <528BC448.4070603@oracle.com> <528BC647.1020508@oracle.com> <528BC98C.5090609@oracle.com> Message-ID: <528BD0E0.9070008@oracle.com> Hi, I have modified the test to print the user name as well: http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.01/ -- daniel On 11/19/13 9:26 PM, Mandy Chung wrote: > > On 11/19/2013 12:12 PM, Daniel Fuchs wrote: >> On 11/19/13 9:04 PM, Mandy Chung wrote: >>> >>> On 11/19/2013 11:35 AM, Daniel Fuchs wrote: >>>> >>>> I am therefore proposing to add an additional check in the test's >>>> setUp() method, in order to verify that the directory is indeed >>>> not writable. >>>> >>> >>> It may be useful to print the owner of the directory in case if it's >>> running with root permission. >> >> OK - I assume I can find that by foraging into the nio Files API? >> > > I think you could use > java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may > need to deal with "acl" vs "posix". > > >>>> webrev: >>>> http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ >>>> >>> >>> 175 final boolean nonWritable = >>> nonWritableDir.setWritable(false); >>> 176 final boolean isWritable = Files.isWritable(path); >>> 177 if (nonWritable && !isWritable) { >>> >>> Perhaps it should assert isWriteable if File.setWriteable returns true. >> >> I'm not sure we want to fail in that case. I mean - the bug >> is complaining that the test fails in the first place ;-) >> I would be inclined to have the test simply skip the non-writable >> test in both cases where it detects that it didn't manage to create >> a non-writable dir. > > If File.setWriteable returns true and isWriteable is false, it'd be a > bug that we want to know about. Perhaps you want to log if the > directory is writeable or not instead of adding it to the check. > > Mandy From mandy.chung at oracle.com Tue Nov 19 21:13:15 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Nov 2013 13:13:15 -0800 Subject: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 In-Reply-To: <528BD0E0.9070008@oracle.com> References: <528BBD89.1070107@oracle.com> <528BC448.4070603@oracle.com> <528BC647.1020508@oracle.com> <528BC98C.5090609@oracle.com> <528BD0E0.9070008@oracle.com> Message-ID: <528BD46B.3050902@oracle.com> On 11/19/2013 12:58 PM, Daniel Fuchs wrote: > Hi, > > I have modified the test to print the user name as well: > > http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.01/ > Looks good to me. As we discussed offline, Files.isWritable may return true on a non-writable directory if running with root permission. The check you added was fine. thanks Mandy > -- daniel > > On 11/19/13 9:26 PM, Mandy Chung wrote: >> >> On 11/19/2013 12:12 PM, Daniel Fuchs wrote: >>> On 11/19/13 9:04 PM, Mandy Chung wrote: >>>> >>>> On 11/19/2013 11:35 AM, Daniel Fuchs wrote: >>>>> >>>>> I am therefore proposing to add an additional check in the test's >>>>> setUp() method, in order to verify that the directory is indeed >>>>> not writable. >>>>> >>>> >>>> It may be useful to print the owner of the directory in case if it's >>>> running with root permission. >>> >>> OK - I assume I can find that by foraging into the nio Files API? >>> >> >> I think you could use >> java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may >> need to deal with "acl" vs "posix". >> >> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ >>>>> >>>> >>>> 175 final boolean nonWritable = >>>> nonWritableDir.setWritable(false); >>>> 176 final boolean isWritable = Files.isWritable(path); >>>> 177 if (nonWritable && !isWritable) { >>>> >>>> Perhaps it should assert isWriteable if File.setWriteable returns >>>> true. >>> >>> I'm not sure we want to fail in that case. I mean - the bug >>> is complaining that the test fails in the first place ;-) >>> I would be inclined to have the test simply skip the non-writable >>> test in both cases where it detects that it didn't manage to create >>> a non-writable dir. >> >> If File.setWriteable returns true and isWriteable is false, it'd be a >> bug that we want to know about. Perhaps you want to log if the >> directory is writeable or not instead of adding it to the check. >> >> Mandy > From daniel.fuchs at oracle.com Tue Nov 19 21:29:06 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 19 Nov 2013 21:29:06 +0000 Subject: hg: jdk8/tl/jdk: 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10 Message-ID: <20131119212918.8D7EB626C9@hg.openjdk.java.net> Changeset: 059530c5ae9a Author: dfuchs Date: 2013-11-19 22:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/059530c5ae9a 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10 Summary: this test has been seen failing on Solaris 10, presumably because it was run as root. The fix will skip the non-writable case if it can't make a non-writable dir. Reviewed-by: mchung ! test/java/util/logging/CheckLockLocationTest.java From Alan.Bateman at oracle.com Tue Nov 19 21:41:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 21:41:19 +0000 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java In-Reply-To: References: <528B7595.6090201@oracle.com> <528B7E33.9080203@oracle.com> Message-ID: <528BDAFF.80108@oracle.com> On 19/11/2013 20:14, Martin Buchholz wrote: > In jsr166 tests we have mostly switched to 10 second timeouts to mean > "forever". > But in ProcessBuilder tests we are starting up new java processes with > their well-known startup problems, so using a much larger value of > "forever" seems reasonable. I vote for 1 minute. You can write > > waitFor(1, TimeUnit.MINUTES); > I agree that a timeout on that order might be needed when starting process. However I think this one is just starting a thread that exercises the new waitFor method. -Alan. From rob.mckenna at oracle.com Tue Nov 19 21:41:55 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 19 Nov 2013 21:41:55 +0000 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug In-Reply-To: References: <528B95DD.5090500@oracle.com> <528BBB8D.9040500@oracle.com> Message-ID: <528BDB23.90001@oracle.com> Great, thanks Martin. I totally overlooked that flag while hunting around globals.hpp. I've added your contribution here: http://cr.openjdk.java.net/~robm/6703075/webrev.02/ -Rob On 19/11/13 19:58, Martin Buchholz wrote: > I propose a fix like the diff below, that asks the VM to separate > regular output and JVM output into stdout and stderr, so that we can > do matching on each independently, and so that we can rely on stdout > not being corrupted by JVM output. > > @@ -555,9 +555,10 @@ > System.getProperty("java.class.path"); > private static final List javaChildArgs = > - Arrays.asList(new String[] > - { javaExe, "-classpath", absolutifyPath(classpath), > - "Basic$JavaChild"}); > + Arrays.asList(javaExe, > + "-XX:+DisplayVMOutputToStderr", > + "-classpath", absolutifyPath(classpath), > + "Basic$JavaChild"); > private static void testEncoding(String encoding, String tested) { > try { > @@ -1593,8 +1594,8 @@ > javaExe)); > list.add("ArrayOOME"); > ProcessResults r = run(new ProcessBuilder(list)); > - check(r.out().contains("java.lang.OutOfMemoryError:")); > - check(r.out().contains(javaExe)); > + check(r.err().contains("java.lang.OutOfMemoryError:")); > + check(r.err().contains(javaExe)); > check(r.err().contains(System.getProperty("java.version"))); > equal(r.exitValue(), 1); > } catch (Throwable t) { unexpected(t); } > > > > On Tue, Nov 19, 2013 at 11:29 AM, Martin Buchholz > wrote: > > Hold on - I'll try to get you alternate fix. > > > On Tue, Nov 19, 2013 at 11:27 AM, Alan Bateman > > wrote: > > On 19/11/2013 16:46, Rob McKenna wrote: > > Hi folks, > > Running this test with fastdebug binaries results in a few > warning messages getting lumped into the commandOutput. > I've decided to filter these test wide. > > https://bugs.openjdk.java.net/browse/JDK-6703075 > http://cr.openjdk.java.net/~robm/6703075/webrev.01/ > > > -Rob > > Having warning messages emitted by the VM and interfering with > application or test output is annoying. What you have is okay > for now but perhaps there is an option to redirect them to > elsewhere. > > -Alan > > > From Alan.Bateman at oracle.com Tue Nov 19 21:43:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Nov 2013 21:43:53 +0000 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug In-Reply-To: References: <528B95DD.5090500@oracle.com> <528BBB8D.9040500@oracle.com> Message-ID: <528BDB99.8020705@oracle.com> On 19/11/2013 19:58, Martin Buchholz wrote: > I propose a fix like the diff below, that asks the VM to separate > regular output and JVM output into stdout and stderr, so that we can > do matching on each independently, and so that we can rely on stdout > not being corrupted by JVM output. Good, it's DisplayVMOutputToStderr or an option to redirect the warnings that I was wondering about. So do you want to take this one? -Alan. From dan.xu at oracle.com Tue Nov 19 21:23:22 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Tue, 19 Nov 2013 21:23:22 +0000 Subject: hg: jdk8/tl/jdk: 8028631: Improve the test coverage to the pathname handling on unix-like platforms Message-ID: <20131119212335.5AA70626C7@hg.openjdk.java.net> Changeset: f496565c4eec Author: dxu Date: 2013-11-19 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f496565c4eec 8028631: Improve the test coverage to the pathname handling on unix-like platforms Summary: Add GeneralSolaris.java testcase and fix the concurrency issue Reviewed-by: lancea, chegar, alanb ! test/java/io/pathNames/General.java + test/java/io/pathNames/GeneralSolaris.java ! test/java/io/pathNames/GeneralWin32.java From martinrb at google.com Tue Nov 19 22:09:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 14:09:33 -0800 Subject: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug In-Reply-To: <528BDB99.8020705@oracle.com> References: <528B95DD.5090500@oracle.com> <528BBB8D.9040500@oracle.com> <528BDB99.8020705@oracle.com> Message-ID: On Tue, Nov 19, 2013 at 1:43 PM, Alan Bateman wrote: > On 19/11/2013 19:58, Martin Buchholz wrote: > >> I propose a fix like the diff below, that asks the VM to separate regular >> output and JVM output into stdout and stderr, so that we can do matching on >> each independently, and so that we can rely on stdout not being corrupted >> by JVM output. >> > Good, it's DisplayVMOutputToStderr or an option to redirect the warnings > that I was wondering about. So do you want to take this one? Especially for the Process code, because I can't test it on multiple platforms, I'm happy to continue having Oracle folk do change submission, while I play Friendly Neighborhood Persnickety Reviewer. Rob, I'm happy with your latest webrev. From stuart.marks at oracle.com Tue Nov 19 22:24:50 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 19 Nov 2013 14:24:50 -0800 Subject: RFR: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Message-ID: <528BE532.3050803@oracle.com> Hi all, Please review this small fix for an intermittent timeout. Nothing seems to be going wrong except that if the machine running the test is exceptionally slow, spurious timeouts will occur. The solution is to raise the timeout in the RMI test infrastructure. Bug: https://bugs.openjdk.java.net/browse/JDK-8028638 Diff: (appended below) Thanks, s'marks # HG changeset patch # User smarks # Date 1384899795 28800 # Node ID ebbfb1b45a4e6b37d339942568a662268dcb18fe # Parent 67d742c759717ca17518aaadb17725cac85c5897 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: XXX diff -r 67d742c75971 -r ebbfb1b45a4e test/java/rmi/testlibrary/RMID.java --- a/test/java/rmi/testlibrary/RMID.java Tue Nov 19 20:10:58 2013 +0100 +++ b/test/java/rmi/testlibrary/RMID.java Tue Nov 19 14:23:15 2013 -0800 @@ -74,6 +74,10 @@ // + // " -Djava.security.debug=all "; + // Set execTimeout to 60 sec (default is 30 sec) + // to avoid spurious timeouts on slow machines. + options += " -Dsun.rmi.activation.execTimeout=60000"; + return options; } From Lance.Andersen at oracle.com Tue Nov 19 22:38:58 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 19 Nov 2013 17:38:58 -0500 Subject: RFR: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails In-Reply-To: <528BE532.3050803@oracle.com> References: <528BE532.3050803@oracle.com> Message-ID: <41576FC5-7606-4821-BF04-BB425B733E92@oracle.com> looks fine On Nov 19, 2013, at 5:24 PM, Stuart Marks wrote: > Hi all, > > Please review this small fix for an intermittent timeout. Nothing seems to be going wrong except that if the machine running the test is exceptionally slow, spurious timeouts will occur. The solution is to raise the timeout in the RMI test infrastructure. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8028638 > > Diff: > (appended below) > > Thanks, > > s'marks > > > # HG changeset patch > # User smarks > # Date 1384899795 28800 > # Node ID ebbfb1b45a4e6b37d339942568a662268dcb18fe > # Parent 67d742c759717ca17518aaadb17725cac85c5897 > 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails > Reviewed-by: XXX > > diff -r 67d742c75971 -r ebbfb1b45a4e test/java/rmi/testlibrary/RMID.java > --- a/test/java/rmi/testlibrary/RMID.java Tue Nov 19 20:10:58 2013 +0100 > +++ b/test/java/rmi/testlibrary/RMID.java Tue Nov 19 14:23:15 2013 -0800 > @@ -74,6 +74,10 @@ > // + > // " -Djava.security.debug=all "; > > + // Set execTimeout to 60 sec (default is 30 sec) > + // to avoid spurious timeouts on slow machines. > + options += " -Dsun.rmi.activation.execTimeout=60000"; > + > return options; > } > -------------- next part -------------- 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 martinrb at google.com Tue Nov 19 22:53:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 14:53:30 -0800 Subject: Request to review JDK-8028094 In-Reply-To: <528B57BA.3060102@oracle.com> References: <528B57BA.3060102@oracle.com> Message-ID: I see this is already submitted. I thought I could do better than using pkill, but no - there is no convenient communication from the java process to the grandchild. This is a hairy test! Nevertheless, I would like you to incorporate the following improvements: - invoke pkill directly - do some extra checking - join with reader thread - don't fail if pkill is not available --- a/test/java/lang/ProcessBuilder/Basic.java +++ b/test/java/lang/ProcessBuilder/Basic.java @@ -2016,7 +2016,7 @@ && new File("/bin/bash").exists() && new File("/bin/sleep").exists()) { final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep 6666)" }; - final String[] cmdkill = { "/bin/bash", "-c", "(/usr/bin/pkill -f \"sleep 6666\")" }; + final String[] cmdkill = { "/usr/bin/pkill", "-f", "sleep 6666" }; final ProcessBuilder pb = new ProcessBuilder(cmd); final Process p = pb.start(); final InputStream stdout = p.getInputStream(); @@ -2044,7 +2044,9 @@ stdout.close(); stderr.close(); stdin.close(); - new ProcessBuilder(cmdkill).start(); + // Try to clean up the sleep process, but don't fret about it. + try { new ProcessBuilder(cmdkill).start(); } + catch (IOException noPkillCommandInstalled) { } //---------------------------------------------------------- // There remain unsolved issues with asynchronous close. // Here's a highly non-portable experiment to demonstrate: @@ -2063,8 +2065,14 @@ }; new ProcessBuilder(wakeupJeff).start().waitFor(); // If wakeupJeff worked, reader probably got EBADF. - reader.join(); } + long startTime = System.nanoTime(); + long timeout = 60L * 1000L; + reader.join(timeout); + long elapsedTimeMillis = + (System.nanoTime() - startTime) / (1024L * 1024L); + check(elapsedTimeMillis < timeout); + check(!reader.isAlive()); } } catch (Throwable t) { unexpected(t); } On Tue, Nov 19, 2013 at 4:21 AM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > I am not sure pkill is available in all Unix flavor at /usr/bin directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra > > > From martinrb at google.com Tue Nov 19 22:56:46 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 14:56:46 -0800 Subject: Request to review JDK-8028094 In-Reply-To: References: <528B57BA.3060102@oracle.com> Message-ID: When my son Tristan turned 6, he decided completely on his own to adopt the name "6666", which he uses in various places as a second identity. I'm not making this up. From stuart.marks at oracle.com Tue Nov 19 23:23:40 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 19 Nov 2013 23:23:40 +0000 Subject: hg: jdk8/tl/jdk: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Message-ID: <20131119232352.AC246626D8@hg.openjdk.java.net> Changeset: 19d2e9649138 Author: smarks Date: 2013-11-19 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: lancea ! test/java/rmi/testlibrary/RMID.java From dan.xu at oracle.com Tue Nov 19 23:57:48 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 19 Nov 2013 15:57:48 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run Message-ID: <528BFAFC.9010804@oracle.com> Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ -Dan From vicente.romero at oracle.com Tue Nov 19 23:36:44 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 19 Nov 2013 23:36:44 +0000 Subject: hg: jdk8/tl/langtools: 8028504: javac generates LocalVariableTable even with -g:none Message-ID: <20131119233647.AF78F626D9@hg.openjdk.java.net> Changeset: 66bcd5d4b3d1 Author: vromero Date: 2013-11-19 23:35 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/66bcd5d4b3d1 8028504: javac generates LocalVariableTable even with -g:none Reviewed-by: jjg, jlahoda ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/T8028504/DontGenerateLVTForGNoneOpTest.java From tristan.yan at oracle.com Wed Nov 20 02:27:40 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 19 Nov 2013 18:27:40 -0800 (PST) Subject: =?gb2312?B?tPC4tDogUkZSIGZvciBKREstNzE5MDEwNiBSTUkgYmVuY2htYXJrIGZhaWxz?= =?gb2312?B?IGludGVybWl0dGVudGx5IGJlY2F1c2Ugb2YgdXNlIG9mIGZpeGVkIHBvcnQ=?= In-Reply-To: <09ed5de7-e061-45b3-9f09-936a624dce1b@default> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> <09ed5de7-e061-45b3-9f09-936a624dce1b@default> Message-ID: Hi Stuart Did you get chance to review it again. Let me know if you have any new comments or suggestions. Thanks Tristan -----????----- ???: Tristan Yan ????: Thursday, November 14, 2013 11:09 PM ???: Stuart Marks ??: core-libs-dev at openjdk.java.net ??: ??: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Thank you Stuart It took me a little time to correct the code. sorry be late. This is new webrev for the code change. Please help to review it again. Description: 1. Convert shell script test to Java program test. 2. Using random server port by reusing Darryl Mocek's work(TestLibrary.getUnusedRandomPort) to replace fixed server port. 3. Because TestLibrary doesn't have package. Here is using reflection to call TestLibrary.getUnusedRandomPort. This is going to change when TestLibrary moves to named package. 4. Using java Process class to start client process. Client and server are sharing IO. 5. Also convert other shell script test runSerialBench.sh to java program test also. 6. ProblemList has been changed to get back java/rmi/reliability/benchmark/runRmiBench.sh test. http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ Thank you so much Tristan -----????----- ???: Stuart Marks ????: Tuesday, November 12, 2013 11:38 PM ???: Tristan Yan ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" port range that's used by some RMI tests that have to used fixed ports. s'marks On 11/11/13 2:39 PM, Tristan Yan wrote: > Hi Stuart > Also there is one more solution, which is there is one > jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same > function as > TestLibrary.getUnusedRandomPort() and it has named package. Do you > mind I use this one? > Since these two functions provide same functionality. Maybe we should > think about to merge them at the same time. > Thank you > Tristan > > On 11/10/2013 11:19 AM, Tristan Yan wrote: >> Hi Stuart >> I tried your suggestion but unfortunately all the benchmarks have >> dependencies to Main class because they need get stub from server. I >> suggest we move the benchmark tests to unnamed package unless we do >> want to put TestLibrary into a named package right now. >> Please let me know if you have objection on this. >> Thank you >> Tristan >> >> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>> Hi Tristan, >>> >>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>> unnamed package. Classes in a named package cannot import classes >>> from the unnamed package. We've run into problems with this before. >>> Eventually, we should move TestLibrary a named package. >>> >>> I think it's possible to work around this without too much >>> difficulty. Note that classes in the unnamed package can import classes from named packages. >>> So, perhaps you can put the RmiBench main class in the unnamed >>> package so it has access to TestLibrary. Then have the benchmarks >>> themselves in the bench.rmi package. The config file already >>> references the benchmarks by fully qualified class name (e.g., >>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able to get this to work. >>> >>> s'marks >>> >>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>> Thank you, Stuart >>>> There is one review point I want to ask you opinion. Which is the >>>> reason that I moved from >>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>> class, I couldn't find a way to let a class which has Package to access the class without package. Do you have suggestion on that? >>>> Thank you so much. >>>> Tristan >>>> >>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>> >>>>> >>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>> Hi Everyone >>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>> >>>>>> Description: >>>>>> 1. Convert shell script test to Java program test. >>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>> replace fixed server port. >>>>>> 3. Using java Process class to start client process. >>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>> program test also >>>>> >>>>> Hi Tristan, >>>>> >>>>> Several comments on this webrev. >>>>> >>>>> >>>>> ** The original arrangement within the >>>>> test/java/rmi/reliability/benchmark >>>>> directory had the main benchmark files (scripts) at the top, some >>>>> benchmark framework files in the "bench" subdirectory, and the >>>>> actual RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>> >>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>> directory but leaves the serial benchmarks in bench/serial. The >>>>> RMI benchmarks are now all cluttering the top directory, but the >>>>> main serial benchmark test is now buried in the bench/serial >>>>> directory. The nice organization that was there before is now >>>>> spoiled. Is this rearrangement necessary in order to convert the scripts to Java? I would prefer the original arrangement be left in place. >>>>> >>>>> >>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>> >>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>>> -c config >>>>> >>>>> There is a subtle but serious problem here: the -server option is >>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>> The main() method gets neither a -server nor a -client argument, >>>>> so its default "run mode" as defined by the benchmark itself is >>>>> SAMEVM. This runs the client and server in the same JVM, which is >>>>> different from the shell script, which ran separate client and server JVMs. >>>>> >>>>> >>>>> ** The logic to process the -server argument still expects to take >>>>> a port, even though the port is assigned automatically. So the >>>>> obvious fix to the above, >>>>> >>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>>> -c config >>>>> >>>>> doesn't work, since a port is missing. The logic to increment the >>>>> argument index to collect the port argument should be removed. >>>>> Also, the -server line should be restored to the usage message, but without the port argument. >>>>> >>>>> >>>>> ** After this is done, the client's command line is constructed improperly. >>>>> The command line ends up looking something like this: >>>>> >>>>> java client -cp Main client localhost:58583 -c >>>>> config >>>>> >>>>> The word "client" appears twice, but what's really required is >>>>> "-client" to appear as an argument after Main. >>>>> >>>>> >>>>> ** The client is run using ProcessBuilder, which by default sends >>>>> stdout and stderr to pipes to be read by the parent. But the >>>>> parent never reads them, thus any messages from the client are >>>>> never seen. The client is the one that emits the benchmark report, >>>>> so its output needs to be seen. It might be sufficient to have the >>>>> client inherit the parent's stdout and stderr. This might intermix >>>>> the client's and server's output, but it's better than nothing. >>>>> >>>>> >>>>> ** The config file is checked with the following code: >>>>> >>>>> try { >>>>> confFile = args[i]; >>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>> + System.getProperty("file.separator") + confFile); >>>>> } catch (IOException e) { >>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>> } >>>>> >>>>> This is potentially misleading, as the message doesn't print the >>>>> actual filename that was attempted to be opened. >>>>> >>>>> This is important, as the test.src property doesn't exist in the client JVM. >>>>> >>>>> Note that the original shell script passed full pathnames for the >>>>> config file to both the client and the server. The new @run tag >>>>> merely says "-c config" which redefines the config filename to be >>>>> relative to the test.src directory. You could pass -Dtest.src=... >>>>> to the client, but it seems like there should be something better than can be done. >>>>> >>>>> >>>>> ** The client needs to have its security policy set up. This is >>>>> missing from the construction of the client's command line. >>>>> >>>>> >>>>> ** ProcessBuilder takes a List for its command; there is >>>>> no need to turn the list into an array. >>>>> >>>>> >>>>> ** In the benchmark main methods, code of the form, >>>>> >>>>> while (true) { >>>>> runBenchmarks(); >>>>> if (exitRequested) { >>>>> System.exit(); >>>>> } >>>>> } >>>>> >>>>> was replaced with >>>>> >>>>> while (!exitRequested) { >>>>> runBenchmarks(); >>>>> } >>>>> >>>>> This is a subtle logic change, in that the former code always >>>>> executed the loop at least once. It seems unlikely, but it's >>>>> possible that a timer could set exitRequested before loop entry, >>>>> resulting in the benchmark running zero times. I guess, if you >>>>> really want to clean this up (we do need to avoid System.exit in jtreg tests), use a do-while loop instead. >>>>> >>>>> >>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>> ProblemList.txt. >>>>> >>>>> >>>>> ** Remove the references to RMISecurityManager and just use >>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>> RMISecurityManager last week.) :-) >>>>> >>>>> >>>>> It would be good if you could fix up these issues and post another webrev. >>>>> >>>>> Thanks. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> >>>>> >>>>>> Thank you >>>>>> Tristan >>>>>> >>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>> I am working on bug >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my >>>>>>>> research, it looks like the issue of fixed port was already >>>>>>>> addressed by Stuart Marks in other RMI tests which are Java based. I would like to reuse his solution, however it does not work for shell based tests. >>>>>>> >>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>> >>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>> through. Most OpenJDK mailing lists strip off attachments before >>>>>>> forwarding Hi Stuart Also there is one more solution, which is >>>>>>> there is one >>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>>> same function as TestLibrary.getUnusedRandomPort() and it has named package. >>>>>>> Do you mind I use this one? >>>>>>> Since these two function provide same functionality. Maybe we >>>>>>> should think about to merge them. >>>>>>> Thank you >>>>>>> Tristan >>>>>>> >>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>> Hi Stuart >>>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>>> have dependencies to Main class because they need get stub from >>>>>>>> server. I suggest we move the benchmark tests to unnamed >>>>>>>> package unless we do want to put TestLibrary into a named package right now. >>>>>>>> Please let me know if you have objection on this. >>>>>>>> Thank you >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>> Hi Tristan, >>>>>>>>> >>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>>> this before. Eventually, we should move TestLibrary a named package. >>>>>>>>> >>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>> Note that classes in the unnamed package can import classes >>>>>>>>> from named packages. So, perhaps you can put the RmiBench main >>>>>>>>> class in the unnamed package so it has access to TestLibrary. >>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>> qualified class name (e.g., >>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>>> be able to get this to work. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>>> >>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>> Thank you, Stuart >>>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>>> the reason that I moved from >>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way to >>>>>>>>>> let a class which has Package to access the class without package. Do you have suggestion on that? >>>>>>>>>> Thank you so much. >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>> Hi Everyone >>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Description: >>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>>> to replace fixed server port. >>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh >>>>>>>>>>>> to java program test also >>>>>>>>>>> >>>>>>>>>>> Hi Tristan, >>>>>>>>>>> >>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>>> RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>>>>>>>> >>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>>> but the main serial benchmark test is now buried in the bench/serial directory. >>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>> scripts to Java? I would prefer the original arrangement be left in place. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>>>> form, >>>>>>>>>>> >>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>>>> Main -c config >>>>>>>>>>> >>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>> option is passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>> argument, so its default "run mode" as defined by the benchmark itself is SAMEVM. >>>>>>>>>>> This runs the client and server in the same JVM, which is >>>>>>>>>>> different from the shell script, which ran separate client and server JVMs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The logic to process the -server argument still expects >>>>>>>>>>> to take a port, even though the port is assigned >>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>> >>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>>> -server -c config >>>>>>>>>>> >>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>> increment the argument index to collect the port argument >>>>>>>>>>> should be removed. Also, the -server line should be restored >>>>>>>>>>> to the usage message, but without the port argument. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>> constructed improperly. The command line ends up looking something like this: >>>>>>>>>>> >>>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>>> -c config >>>>>>>>>>> >>>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>> But the parent never reads them, thus any messages from the client are never seen. >>>>>>>>>>> The client is the one that emits the benchmark report, so >>>>>>>>>>> its output needs to be seen. It might be sufficient to have >>>>>>>>>>> the client inherit the parent's stdout and stderr. This >>>>>>>>>>> might intermix the client's and server's output, but it's better than nothing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>> >>>>>>>>>>> try { >>>>>>>>>>> confFile = args[i]; >>>>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>>> >>>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>>> the client JVM. >>>>>>>>>>> >>>>>>>>>>> Note that the original shell script passed full pathnames >>>>>>>>>>> for the config file to both the client and the server. The >>>>>>>>>>> new @run tag merely says "-c config" which redefines the >>>>>>>>>>> config filename to be relative to the test.src directory. >>>>>>>>>>> You could pass -Dtest.src=... to the client, but it seems >>>>>>>>>>> like there should be something better than can be done. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>> >>>>>>>>>>> while (true) { >>>>>>>>>>> runBenchmarks(); >>>>>>>>>>> if (exitRequested) { >>>>>>>>>>> System.exit(); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> was replaced with >>>>>>>>>>> >>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>> runBenchmarks(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>> always executed the loop at least once. It seems unlikely, >>>>>>>>>>> but it's possible that a timer could set exitRequested >>>>>>>>>>> before loop entry, resulting in the benchmark running zero >>>>>>>>>>> times. I guess, if you really want to clean this up (we do >>>>>>>>>>> need to avoid System.exit in jtreg tests), use a do-while loop instead. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>>> from ProblemList.txt. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>>> another webrev. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> s'marks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thank you >>>>>>>>>>>> Tristan >>>>>>>>>>>> >>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests >>>>>>>>>>>>>> which are Java based. I would like to reuse his solution, >>>>>>>>>>>>>> however it does not work for shell based tests. >>>>>>>>>>>>> >>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>> >>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>>> get through. Most OpenJDK mailing lists strip off >>>>>>>>>>>>> attachments before forwarding the message to the >>>>>>>>>>>>> recipients. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>> script test into Java based test and re-use the dynamic >>>>>>>>>>>>>> port allocation solution by Stuart Marks to address the >>>>>>>>>>>>>> issue >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>>> shell script. In the past there have been sync issues >>>>>>>>>>>>>> between server/client which caused the test to fail. If >>>>>>>>>>>>>> we convert the shell script into Java based test, it >>>>>>>>>>>>>> would avoid using "sleep 10" mechanism to allow for >>>>>>>>>>>>>> server and client to start up and also give us better >>>>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>>>> >>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>>> quite difficult to make reliable shell tests, especially >>>>>>>>>>>>> for multi-process tests like this one. >>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>> issue of how long for the client to wait until the server >>>>>>>>>>>>> is ready. Error handling is also a problem, for example, >>>>>>>>>>>>> if one of the JVMs gets an unexpected exception, it's easy >>>>>>>>>>>>> for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>> erroneously report success. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) >>>>>>>>>>>>> and then post a link to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> s'marks >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> the message to >>>>>>> the recipients. >>>>>>> >>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>> into Java based test and re-use the dynamic port allocation >>>>>>>> solution by Stuart Marks to address the issue >>>>>>>> >>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>> In the >>>>>>>> past there have been sync issues between server/client which >>>>>>>> caused the test to fail. If we convert the shell script into >>>>>>>> Java based test, it would avoid using "sleep 10" mechanism to >>>>>>>> allow for server and client to start up and also give us better >>>>>>>> control in synchronizing server and client. >>>>>>> >>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>> difficult to make reliable shell tests, especially for >>>>>>> multi-process tests like this one. >>>>>>> There is the unique port issue, and there is also the issue of >>>>>>> how long for the client to wait until the server is ready. Error >>>>>>> handling is also a problem, for example, if one of the JVMs gets >>>>>>> an unexpected exception, it's easy for shell tests to mishandle >>>>>>> this case. They might hang or erroneously report success. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>> upload it somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> s'marks >>>>>> >>>> >>> >> > From srikalyan.chandrashekar at oracle.com Wed Nov 20 02:39:54 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan chandrashekar) Date: Tue, 19 Nov 2013 18:39:54 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: References: <528B016A.3080408@oracle.com> Message-ID: <528C20FA.9090303@oracle.com> Hi Martin, i incorporated the recent changes from the pointer as well. I have reproduced the failure, the logs of which are attached to the bug JDK-6772009 . The failed log is especially interesting . -- Thanks kalyan On 11/18/13 10:15 PM, Martin Buchholz wrote: > Thanks for working on this. > There have been some recent upstream changes to this test as well. > Please incorporate them. > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co > The jsr166 maintainers haven't been able to reproduce any failures in > this test. Do you have any hints that might help us? > > > > On Mon, Nov 18, 2013 at 10:12 PM, srikalyan chandrashekar > > wrote: > > Hi all, I am working on bug JDK-6772009 > . > > Root Cause: > The timeout value gives too much grace period on faster machines > on which the "TO BE INTERRUPTED" threads complete faster before > being interrupted at right time. > > Suggested Fix: > a) Decrease the timeout from 100 to 50ms which will ensure that > the test will pass even on faster machines , and ensures the > threads will be canceled when running and anyways there is a > Barrier to ensure the test threads all complete gracefully. > Miscellaneous fixes > b) Convert result from int to long(possible integer overflow > otherwise) > c) Catch BrokenBarrierException in more granular fashion in > ReentrantLockLoop to update and print the results (which will be > missed otherwise) > Add more diagnostics > d) Assign names to threads > e) Print which threads update the 'completed' variable. > > I have attached the webrev for convenience as the changes are > interleaved and is best viewed as sdiff. > Please let me know if you have any comments or suggestions. > > > > Thank you > > -- > > -- > Thanks > kalyan > > From lance.andersen at oracle.com Wed Nov 20 02:39:29 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 19 Nov 2013 21:39:29 -0500 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528BFAFC.9010804@oracle.com> References: <528BFAFC.9010804@oracle.com> Message-ID: Looks ok 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 Sent from my iPad On Nov 19, 2013, at 6:57 PM, Dan Xu wrote: > Hi All, > > Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. > > In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! > > Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 > Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ > > -Dan From mandy.chung at oracle.com Wed Nov 20 03:08:29 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Nov 2013 19:08:29 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528BFAFC.9010804@oracle.com> References: <528BFAFC.9010804@oracle.com> Message-ID: <528C27AD.1020008@oracle.com> On 11/19/2013 3:57 PM, Dan Xu wrote: > Hi All, > > Please review the simple fix towards Size.java testcase. It failed > once on windows platform in the recent same binary run, which is > mostly due to some interferences and the special delete handling on > windows. > > In the fix, I remove the delete operation in initTestFile() method > because FileOutputStream will truncate the file content and it is not > necessary to delete it first. Thanks! > > Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 > Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ > The patch itself is okay. Would you think if writing to a file in the current directory rather than temp is less prone to the interference? Mandy From dan.xu at oracle.com Wed Nov 20 04:13:44 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 19 Nov 2013 20:13:44 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528C27AD.1020008@oracle.com> References: <528BFAFC.9010804@oracle.com> <528C27AD.1020008@oracle.com> Message-ID: <528C36F8.2020203@oracle.com> Hi Mandy, I think that writing to the current directory and writing to the temp directory will get the same interference in this testcase. Because the interference is mostly coming from the anti-virus software or some windows system services. Any file changes in the file system may trigger them. Due to the interference, if a test deletes a file and then immediately create a file with the same name, the create operation may fail with access denied exception. I have described it in detail when discussing Chris's webrev, http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html. Thanks! -Dan On 11/19/2013 07:08 PM, Mandy Chung wrote: > > On 11/19/2013 3:57 PM, Dan Xu wrote: >> Hi All, >> >> Please review the simple fix towards Size.java testcase. It failed >> once on windows platform in the recent same binary run, which is >> mostly due to some interferences and the special delete handling on >> windows. >> >> In the fix, I remove the delete operation in initTestFile() method >> because FileOutputStream will truncate the file content and it is not >> necessary to delete it first. Thanks! >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 >> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ >> > > The patch itself is okay. Would you think if writing to a file in > the current directory rather than temp is less prone to the interference? > > Mandy From tristan.yan at oracle.com Wed Nov 20 04:45:37 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 19 Nov 2013 20:45:37 -0800 (PST) Subject: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Message-ID: <96fe0ea6-4c0b-4e90-9c58-24e244a8cc15@default> Hi Everyone We have a test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that was put into ProblemList because of bug JDK-6933803, this test has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/diff/cb3ecb5e4ce5/test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java. We have run a 1000 times loop test for making sure there is no issue in this test anymore and we don't see any failure . I think it's good time to bring this test back from ProblemList. http://cr.openjdk.java.net/~ewang/tristan/JDK-6933803/webrev.00/test/ProblemList.txt.sdiff.html Please let me know if you have comment on this. Thank you. Tristan Yan(Haibo Yan) From mandy.chung at oracle.com Wed Nov 20 05:00:29 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 19 Nov 2013 21:00:29 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528C36F8.2020203@oracle.com> References: <528BFAFC.9010804@oracle.com> <528C27AD.1020008@oracle.com> <528C36F8.2020203@oracle.com> Message-ID: <528C41ED.7040700@oracle.com> Thanks for the details Dan [1]. It is useful. The reason why I was wondering the difference with temp dir is that the test workdir might be excluded from the anti-virus scanner on that test machine. Now you have explained it. thanks Mandy [1] http://mail.openjdk.java.net/pipermail/net-dev/2013-November/007783.html On 11/19/2013 8:13 PM, Dan Xu wrote: > Hi Mandy, > > I think that writing to the current directory and writing to the temp > directory will get the same interference in this testcase. Because the > interference is mostly coming from the anti-virus software or some > windows system services. Any file changes in the file system may > trigger them. Due to the interference, if a test deletes a file and > then immediately create a file with the same name, the create > operation may fail with access denied exception. I have described it > in detail when discussing Chris's webrev, > http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html. > Thanks! > > -Dan > > On 11/19/2013 07:08 PM, Mandy Chung wrote: >> >> On 11/19/2013 3:57 PM, Dan Xu wrote: >>> Hi All, >>> >>> Please review the simple fix towards Size.java testcase. It failed >>> once on windows platform in the recent same binary run, which is >>> mostly due to some interferences and the special delete handling on >>> windows. >>> >>> In the fix, I remove the delete operation in initTestFile() method >>> because FileOutputStream will truncate the file content and it is >>> not necessary to delete it first. Thanks! >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 >>> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ >>> >> >> The patch itself is okay. Would you think if writing to a file in >> the current directory rather than temp is less prone to the >> interference? >> >> Mandy > From martinrb at google.com Wed Nov 20 06:35:24 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 19 Nov 2013 22:35:24 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <528C20FA.9090303@oracle.com> References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> Message-ID: Hi Kalyan, None of us can review your changes yet because you haven't given us a URL of your webrev. I've tried to make the jsr166 copy of CancelledLockLoops fail by adjusting ITERS and TIMEOUT radically up and down, but the test just keeps on passing for me. Hints appreciated. On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar < srikalyan.chandrashekar at oracle.com> wrote: > Suggested Fix: >> a) Decrease the timeout from 100 to 50ms which will ensure that the test >> will pass even on faster machines >> > This doesn't look like a permanent fix - it just makes the failing case rarer. From weijun.wang at oracle.com Wed Nov 20 07:37:07 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 Nov 2013 15:37:07 +0800 Subject: jar command shows "bit length overflow" Message-ID: <528C66A3.5090408@oracle.com> I just rebuild jdk8/tl on Windows and calling "jar uvf" shows a lot of bit length overflow code ?? bits ?->? A little grep shows jdk/src/share/native/java/util/zip/zlib-1.2.5/trees.c could print this. Something goes wrong or is it just me? Said that, it looks like the jar file is fine. Thanks Max From joe.darcy at oracle.com Wed Nov 20 08:21:35 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 20 Nov 2013 00:21:35 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> Message-ID: <528C710F.4070909@oracle.com> Hi Paul, On 11/18/2013 07:38 AM, Paul Sandoz wrote: > Hi Joe, > > You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: > > public final OptionalDouble average() { > double[] avg = collect(() -> new double[2], > (ll, i) -> { > ll[0]++; > ll[1] += i; > }, > (ll, rr) -> { > ll[0] += rr[0]; > ll[1] += rr[1]; > }); > return avg[0] > 0 > ? OptionalDouble.of(avg[1] / avg[0]) > : OptionalDouble.empty(); > } > > That would be the most expedient way. Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: http://cr.openjdk.java.net/~darcy/8006572.3/ This allows one of the kernels of the compensated summation logic to be shared in two of the use-sites. For the test, all 6 scenarios fail on a JDK *without* the compensated summation code and all 6 pass with it; all the other java/util/streams regression tests pass with the new code too. Off-list, I've asked a numerically inclined colleague to look over the summation logic and how the compensated summation states are combined. Thanks, -Joe > However, for sum() it is somewhat unfortunate to have to create a double[1] box for each leaf. If you are willing to write a little more more code you can create your own double sum ReducingSink implementation as Brian suggests. > > > Testing wise you don't need to implement an Iterator, you can do the following: > > DoubleStream.iterate(base, e -> increment).limit(count) > > It might be more convenient to test as follows: > > Stream s = Stream.iterate(false, e -> true).limit(count); // [*] > DoubleSummaryStatistics stats = s.collect(Collectors.summarizingDouble(e -> e ? increment : base)); // Cross fingers that compiles! > > Stream s = Stream.iterate(false, e -> true).limit(count); > Double d = s.iterate(false, e -> true).limit(count)..collect(Collectors.summingDouble(e ? increment : base)); > > Thereby covering both Collector implementations. > > I guess it might be harder to test the combining step using parallel streams since combining will be platform dependent (depends on #cores) unless you track how things are combined. Perhaps the Collector instance could be tested directly with combination? > > Paul. > > [*] Another way is to use stream concatenation: > > Stream.concat(Stream.of(false), IntStream.range(1, count).mapToObj(e -> true)) > Stream.concat(Stream.of(false), Stream.generate(() -> true)).limit(count) > > > On Nov 14, 2013, at 9:08 AM, Joe Darcy wrote: > >> Hello, >> >> Please take an initial look over a fix for >> >> JDK-8006572 DoubleStream.sum() & DoubleSummaryStats implementations that reduce numerical errors >> http://cr.openjdk.java.net/~darcy/8006572.0/ >> >> The basic approach is to use compensated summation >> >> http://en.wikipedia.org/wiki/Kahan_summation_algorithm >> >> to computed streams-related sum and average statistics in the various locations that this can be done. >> >> All existing streams tests pass and new newly-written test passes too. >> >> I believe the DoubleSummaryStatistics.java portion, including the test, is fully review-worthy. In the test, for the sample computation in question, the naive summation implementation had a error of 500,000 ulps compared to 2 ups with the new implementation. >> >> Two other locations I've found where this summation technique should be used are in >> >> java.util.stream.Collectors.{summingDouble, averagingDouble} >> >> and >> >> java.util.stream.DoublePipeline.{sum, average} >> >> DoublePipeline is the primary implementation class of DoubleStream. >> >> For Collectors, the proposed code is a fairly clear adaptation of how the current code passes state around; there is not currently a dedicated test for the new summation technique in this location. >> >> I'm new to the streams API so for DoublePipeline I don't know the idiomatic way to phrase the collect I want to perform over the code. (Based on my current understanding, I believe I want to perform a collect rather than a reduce since for the compensated summation I need to maintain some additional state.) Guidance here welcome. >> >> Thanks, >> >> -Joe From paul.sandoz at oracle.com Wed Nov 20 09:49:46 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 20 Nov 2013 10:49:46 +0100 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <528C710F.4070909@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> Message-ID: <5DCB8174-2F6D-4D9C-AF32-28E940A4D79E@oracle.com> Hi Joe, On Nov 20, 2013, at 9:21 AM, Joe Darcy wrote: > Hi Paul, > > On 11/18/2013 07:38 AM, Paul Sandoz wrote: >> Hi Joe, >> >> You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: >> >> public final OptionalDouble average() { >> double[] avg = collect(() -> new double[2], >> (ll, i) -> { >> ll[0]++; >> ll[1] += i; >> }, >> (ll, rr) -> { >> ll[0] += rr[0]; >> ll[1] += rr[1]; >> }); >> return avg[0] > 0 >> ? OptionalDouble.of(avg[1] / avg[0]) >> : OptionalDouble.empty(); >> } >> >> That would be the most expedient way. > > Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: > > http://cr.openjdk.java.net/~darcy/8006572.3/ > . In DoublePipeline: 378 @Override 379 public final double sum() { 380 double[] summation = collect(() -> new double[2], 381 (ll, d) -> { 382 Collectors.sumWithCompensation(ll, d); 383 }, 384 (ll, rr) -> { 385 Collectors.sumWithCompensation(ll, rr[0]); 386 Collectors.sumWithCompensation(ll, rr[1]); 387 }); 388 return summation[0]; 389 } I think you can replace the lambda expression at #381 with a method reference. 410 @Override 411 public final OptionalDouble average() { 412 double[] avg = collect(() -> new double[3], 413 (ll, d) -> { 414 ll[2]++; 415 Collectors.sumWithCompensation(ll, d); 416 }, 417 (ll, rr) -> { 418 Collectors.sumWithCompensation(ll, rr[0]); 419 Collectors.sumWithCompensation(ll, rr[1]); 420 ll[2] += rr[2]; 421 }); 422 return avg[0] > 0 423 ? OptionalDouble.of(avg[0] / avg[2]) 424 : OptionalDouble.empty(); 425 } #422 needs to be "avg[2] > 0" since you changed the location of the count. It suggests we don't have tests for a non-empty stream whose sum is zero :-) Other non-test code looks good. > This allows one of the kernels of the compensated summation logic to be shared in two of the use-sites. > > For the test, all 6 scenarios fail on a JDK *without* the compensated summation code and all 6 pass with it; all the other java/util/streams regression tests pass with the new code too. > I still strongly encourage you to remove the Iterator and replace with Stream.iterate. You can probably half the number of lines of test code. The following: 80 private static Stream testBoxedStream(double base, double increment, int count) { 81 TestDoubleIterator tdi = new TestDoubleIterator(base, increment, count); 82 Double[] tmp = new Double[count]; 83 int i = 0; 84 while(tdi.hasNext()) { 85 tmp[i] = tdi.next(); 86 i++; 87 } 88 return Stream.of(tmp); 89 } can be replaced with a one liner: DoubleStream.iterate(base, e -> increment).limit(count).boxed(); You can abstract the creation of DoubleStream with a Suppiler: // Factory for double a stream of [base, increment, ..., increment] limited to a size of count Supplier ds = () -> DoubleStream.iterate(base, e -> increment).limit(count); so you don't have to keep repeating the passing of the base/increment/count arguments each time: failures += compareUlpDifference(expectedSum, ds.get().sum(), 3); failures += compareUlpDifference(expectedSum, ds.get().average() getAsDouble(), 3); double collectorSum = ds.get().boxed().collect(Collectors.summingDouble(Function.identity()); ... double collectorAvg = ds.get().boxed().collect(Collectors. averagingDouble(Function.identity())); -- You can even abstract out the compareUlpDifference for the expected and threshold: Function comp = d -> compareUlpDifference(expected, d, threshold); .. failures += comp.apply(ds.get().boxed().collect(Collectors. averagingDouble(Function.identity()))) Anyway... not suggesting you do that, just wanted to point out a simple partial function trick that i have found useful that can, when used appropriately, be an effective way to reduce code boilerplate. -- My preference is to use TestNG and have separate test methods rather than explicitly managing failures and when a failure occurs having to dig into the logs rather than looking at the test report itself (which if really good will have a link back to the source code of the failing test). I don't seem to be getting much traction when i have previously suggested this :-) i doubt i will now! > Off-list, I've asked a numerically inclined colleague to look over the summation logic and how the compensated summation states are combined. > OK. Paul. From chris.hegarty at oracle.com Wed Nov 20 11:29:52 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 Nov 2013 11:29:52 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528C41ED.7040700@oracle.com> References: <528BFAFC.9010804@oracle.com> <528C27AD.1020008@oracle.com> <528C36F8.2020203@oracle.com> <528C41ED.7040700@oracle.com> Message-ID: <528C9D30.6040606@oracle.com> On 20/11/13 05:00, Mandy Chung wrote: > Thanks for the details Dan [1]. It is useful. The reason why I was > wondering the difference with temp dir is that the test workdir might be > excluded from the anti-virus scanner on that test machine. Now you have > explained it. Right, this would be my preference too. There is more control if tests write to the current working directory. The changes look fine to me, but there is still a ' blah.delete();' on L63 of the new file. I think this should use FileUtils.deleteFileWithRetry() [1], as it could still fail, right? Thanks, -Chris. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/19d2e9649138/test/lib/testlibrary/jdk/testlibrary/FileUtils.java > > thanks > Mandy > [1] > http://mail.openjdk.java.net/pipermail/net-dev/2013-November/007783.html > > On 11/19/2013 8:13 PM, Dan Xu wrote: >> Hi Mandy, >> >> I think that writing to the current directory and writing to the temp >> directory will get the same interference in this testcase. Because the >> interference is mostly coming from the anti-virus software or some >> windows system services. Any file changes in the file system may >> trigger them. Due to the interference, if a test deletes a file and >> then immediately create a file with the same name, the create >> operation may fail with access denied exception. I have described it >> in detail when discussing Chris's webrev, >> http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html. >> Thanks! >> >> -Dan >> >> On 11/19/2013 07:08 PM, Mandy Chung wrote: >>> >>> On 11/19/2013 3:57 PM, Dan Xu wrote: >>>> Hi All, >>>> >>>> Please review the simple fix towards Size.java testcase. It failed >>>> once on windows platform in the recent same binary run, which is >>>> mostly due to some interferences and the special delete handling on >>>> windows. >>>> >>>> In the fix, I remove the delete operation in initTestFile() method >>>> because FileOutputStream will truncate the file content and it is >>>> not necessary to delete it first. Thanks! >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 >>>> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ >>>> >>> >>> The patch itself is okay. Would you think if writing to a file in >>> the current directory rather than temp is less prone to the >>> interference? >>> >>> Mandy >> > From erik.gahlin at oracle.com Wed Nov 20 11:31:41 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Wed, 20 Nov 2013 11:31:41 +0000 Subject: hg: jdk8/tl/jdk: 7141544: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails Message-ID: <20131120113219.D2F4A626F7@hg.openjdk.java.net> Changeset: 894a4bae9e33 Author: egahlin Date: 2013-11-20 12:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/894a4bae9e33 7141544: TEST_BUG: com/sun/jdi/BreakpointWithFullGC.sh fails Reviewed-by: sla ! test/com/sun/jdi/BreakpointWithFullGC.sh From Alan.Bateman at oracle.com Wed Nov 20 12:08:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Nov 2013 12:08:07 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528BFAFC.9010804@oracle.com> References: <528BFAFC.9010804@oracle.com> Message-ID: <528CA627.9000108@oracle.com> On 19/11/2013 23:57, Dan Xu wrote: > Hi All, > > Please review the simple fix towards Size.java testcase. It failed > once on windows platform in the recent same binary run, which is > mostly due to some interferences and the special delete handling on > windows. > > In the fix, I remove the delete operation in initTestFile() method > because FileOutputStream will truncate the file content and it is not > necessary to delete it first. Thanks! > > Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 > Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ > This does look like a case where the test is needlessly deleting and re-creating the file (although still annoying to have interference from virus checkers or other background services). As you point out, FileOutputStream will truncate an existing file so it's not needed. So I think your changes to remove the exist/delete from the init method is good. If you have the cycles then there are probably a few clean-ups that could be done on this test. I don't think blah needs to be static, it could use try-with-resources and delete blah in the finally block. Also test2 looks historical, it may be that this can be enabled on Linux and Windows now (the bug/comments seem to date from JDK 1.4). -Alan From jan.lahoda at oracle.com Wed Nov 20 13:01:24 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 20 Nov 2013 13:01:24 +0000 Subject: hg: jdk8/tl/langtools: 6557966: Multiple upper bounds of the TypeVariable Message-ID: <20131120130134.99358626FC@hg.openjdk.java.net> Changeset: 7c89d200781b Author: jlahoda Date: 2013-11-20 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7c89d200781b 6557966: Multiple upper bounds of the TypeVariable Summary: Adjusting javax.lang.model javadoc regarding IntersectionType, IntersectionType.accept now calls visitIntersection for all kinds of IntersectionTypes. Reviewed-by: darcy, vromero Contributed-by: joe.darcy at oracle.com, jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/javax/lang/model/type/DeclaredType.java ! src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeVariable.java ! test/tools/javac/processing/model/type/IntersectionPropertiesTest.java From joel.franck at oracle.com Wed Nov 20 12:24:58 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 20 Nov 2013 12:24:58 +0000 Subject: hg: jdk8/tl/jdk: 8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType Message-ID: <20131120122511.7F611626F9@hg.openjdk.java.net> Changeset: f39be11835ff Author: jfranck Date: 2013-11-20 13:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f39be11835ff 8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType Reviewed-by: darcy ! src/share/classes/java/lang/annotation/ElementType.java ! src/share/classes/java/lang/annotation/Target.java From balchandra.vaidya at oracle.com Wed Nov 20 15:05:48 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Wed, 20 Nov 2013 15:05:48 +0000 Subject: Request to review JDK-8028094 In-Reply-To: References: <528B708E.9090404@oracle.com> Message-ID: <528CCFCC.7060205@oracle.com> On 19/11/2013 19:42, Martin Buchholz wrote: > It would be nice if every request for review included URLs for the bug > report (in addition to the webrev). > Here is the bug id: https://bugs.openjdk.java.net/browse/JDK-8028094 > The existing test has a check for the existence of /bin/sleep before > running it. We should do the same for any other Unix command like pkill. Agree. I will work it. Thanks Balchandra > But we should also try to think of better solutions than having to > use pkill. > > > On Tue, Nov 19, 2013 at 6:07 AM, Balchandra Vaidya > > > wrote: > > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > > I am not sure pkill is available in all Unix flavor at /usr/bin > directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra > > From balchandra.vaidya at oracle.com Wed Nov 20 15:06:33 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Wed, 20 Nov 2013 15:06:33 +0000 Subject: Request to review JDK-8028094 In-Reply-To: References: <528B708E.9090404@oracle.com> Message-ID: <528CCFF9.1080206@oracle.com> Hi Martin, It is just an effort try to cleanup the leftover sleep process before the test terminates. Thanks Balchandra On 19/11/2013 19:44, Martin Buchholz wrote: > Is there an actual problem caused by all those sleep processes, or are > you just trying to be tidy? > > > On Tue, Nov 19, 2013 at 6:07 AM, Balchandra Vaidya > > > wrote: > > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > > I am not sure pkill is available in all Unix flavor at /usr/bin > directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra > > From balchandra.vaidya at oracle.com Wed Nov 20 15:11:28 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Wed, 20 Nov 2013 15:11:28 +0000 Subject: Request to review JDK-8028094 In-Reply-To: References: <528B57BA.3060102@oracle.com> Message-ID: <528CD120.3050101@oracle.com> Thanks Martin. I will incorporate your suggested improvements, and will send out another webrev. Regards Balchandra On 19/11/2013 22:53, Martin Buchholz wrote: > I see this is already submitted. > > I thought I could do better than using pkill, but no - there is no > convenient communication from the java process to the grandchild. > This is a hairy test! > > Nevertheless, I would like you to incorporate the following improvements: > - invoke pkill directly > - do some extra checking > - join with reader thread > - don't fail if pkill is not available > > --- a/test/java/lang/ProcessBuilder/Basic.java > +++ b/test/java/lang/ProcessBuilder/Basic.java > @@ -2016,7 +2016,7 @@ > && new File("/bin/bash").exists() > && new File("/bin/sleep").exists()) { > final String[] cmd = { "/bin/bash", "-c", > "(/bin/sleep 6666)" }; > - final String[] cmdkill = { "/bin/bash", "-c", > "(/usr/bin/pkill -f \"sleep 6666\")" }; > + final String[] cmdkill = { "/usr/bin/pkill", "-f", > "sleep 6666" }; > final ProcessBuilder pb = new ProcessBuilder(cmd); > final Process p = pb.start(); > final InputStream stdout = p.getInputStream(); > @@ -2044,7 +2044,9 @@ > stdout.close(); > stderr.close(); > stdin.close(); > - new ProcessBuilder(cmdkill).start(); > + // Try to clean up the sleep process, but don't fret > about it. > + try { new ProcessBuilder(cmdkill).start(); } > + catch (IOException noPkillCommandInstalled) { } > //---------------------------------------------------------- > // There remain unsolved issues with asynchronous close. > // Here's a highly non-portable experiment to > demonstrate: > @@ -2063,8 +2065,14 @@ > }; > new ProcessBuilder(wakeupJeff).start().waitFor(); > // If wakeupJeff worked, reader probably got EBADF. > - reader.join(); > } > + long startTime = System.nanoTime(); > + long timeout = 60L * 1000L; > + reader.join(timeout); > + long elapsedTimeMillis = > + (System.nanoTime() - startTime) / (1024L * 1024L); > + check(elapsedTimeMillis < timeout); > + check(!reader.isAlive()); > } > } catch (Throwable t) { unexpected(t); } > > > > On Tue, Nov 19, 2013 at 4:21 AM, Balchandra Vaidya > > > wrote: > > > Hi, > > Here is one possible solution for the issue JDK-8028094. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ > > > I am not sure pkill is available in all Unix flavor at /usr/bin > directory, > but it is present in Solaris and OEL 6. I have tested on Solaris > and OEL and "sleep 6666" is no longer left over. > > > Thanks > Balchandra > > > From martinrb at google.com Wed Nov 20 15:23:26 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 20 Nov 2013 07:23:26 -0800 Subject: Request to review JDK-8028094 In-Reply-To: <528CCFCC.7060205@oracle.com> References: <528B708E.9090404@oracle.com> <528CCFCC.7060205@oracle.com> Message-ID: On Wed, Nov 20, 2013 at 7:05 AM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > On 19/11/2013 19:42, Martin Buchholz wrote: > > The existing test has a check for the existence of /bin/sleep before > running it. We should do the same for any other Unix command like pkill. > > Agree. I will work it. > > Since killing the sleep process is only for being tidy, I now think the better way is to try to run it without checking for its existence, but ignore any exception we get when trying, as in my latest suggested patch. From mandy.chung at oracle.com Wed Nov 20 18:02:35 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 20 Nov 2013 18:02:35 +0000 Subject: hg: jdk8/tl/jdk: 8028647: Add instrumentation in GetSafepointSyncTime.java and remove it from ProblemList.txt Message-ID: <20131120180250.5B94562711@hg.openjdk.java.net> Changeset: 90e27a47ff28 Author: mchung Date: 2013-11-20 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90e27a47ff28 8028647: Add instrumentation in GetSafepointSyncTime.java and remove it from ProblemList.txt Reviewed-by: sla, chegar ! test/ProblemList.txt ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java From volker.simonis at gmail.com Wed Nov 20 18:26:35 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Nov 2013 19:26:35 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX Message-ID: Hi, this is the second review round for "8024854: Basic changes and files to build the class library on AIX". The previous reviews can be found at the end of this mail in the references section. I've tried to address all the comments and suggestions from the first round and to further streamline the patch (it perfectly builds on Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change compared to the first review round is the new "aix/" subdirectory which I've now created under "jdk/src" and which contains AIX-only code. The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master: http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ Below (and in the webrev) you can find some comments which explain the changes to each file. In order to be able to push this big change, I need the approval of reviewers from the lib, net, svc, 2d, awt and sec groups. So please don't hesitate to jump at it - there are enough changes for everybody:) Thank you and best regards, Volker *References:* The following reviews have been posted so far (thanks Iris for collecting them :) - Alan Bateman (lib): Initial comments (16 Sep [2]) - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) - Michael McMahon (net): Initial comments (20 Sept [4]) - Steffan Larsen (svc): APPROVED (20 Sept [5]) - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments (15 Oct [7]) - Sean Mullan (sec): Initial comments (26 Sept [8]) [2]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html [3]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html [4]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html [5]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html [6]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html [8]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html *Detailed change description:* The new "jdk/src/aix" subdirectory contains the following new and AIX-specific files for now: src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java src/aix/classes/sun/nio/ch/AixPollPort.java src/aix/classes/sun/nio/fs/AixFileStore.java src/aix/classes/sun/nio/fs/AixFileSystem.java src/aix/classes/sun/nio/fs/AixFileSystemProvider.java src/aix/classes/sun/nio/fs/AixNativeDispatcher.java src/aix/classes/sun/tools/attach/AixAttachProvider.java src/aix/classes/sun/tools/attach/AixVirtualMachine.java src/aix/native/java/net/aix_close.c src/aix/native/sun/nio/ch/AixPollPort.c src/aix/native/sun/nio/fs/AixNativeDispatcher.c src/aix/native/sun/tools/attach/AixVirtualMachine.c src/aix/porting/porting_aix.c src/aix/porting/porting_aix.h src/aix/porting/porting_aix.c src/aix/porting/porting_aix.h - Added these two files for AIX relevant utility code. - Currently these files only contain an implementation of dladdr which is not available on AIX. - In the first review round the existing dladdr users in the code either called the version from the HotSpot on AIX ( src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). This is now not necessary any more. The new file layout required some small changes to the makefiles to make them aware of the new directory locations: makefiles/CompileDemos.gmk - Add an extra argument to SetupJVMTIDemo which can be used to pass additional source locations. - Currently this is only used on AIX for the AIX porting utilities which are required by hprof. makefiles/lib/Awt2dLibraries.gmk makefiles/lib/ServiceabilityLibraries.gmk - On AIX add the sources of the AIX porting utilities to the build. They are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not available on AIX. makefiles/lib/NioLibraries.gmk - Make the AIX-build aware of the new NIO source locations under src/aix/native/sun/nio/. makefiles/lib/NetworkingLibraries.gmk - Make the AIX-build aware of the new aix_close.c source location under src/aix/native/java/net/. src/share/bin/jli_util.h - Define JLI_Lseek on AIX. src/share/lib/security/java.security-aix - Provide default java.security-aix for AIX based on the latest Linux version as suggested by Sean Mullan. src/share/native/common/check_code.c - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is legal, but the code in check_code.c does not handles this properly. So we wrap the two methods on AIX and return a non-NULL pointer even if we allocate 0 bytes. src/share/native/sun/awt/medialib/mlib_sys.c - malloc always returns 8-byte aligned pointers on AIX as well. src/share/native/sun/awt/medialib/mlib_types.h - Add AIX to the list of known platforms. src/share/native/sun/font/layout/KernTable.cpp - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common and may be defined in other headers as well as on the command line and xlc bails out on macro redefinitions with a different value. src/share/native/sun/security/ec/impl/ecc_impl.h - Define required types and macros on AIX. src/solaris/back/exec_md.c - AIX behaves like Linux in this case so check for it in the Linux branch. src/solaris/bin/java_md_solinux.c, src/solaris/bin/java_md_solinux.h - On AIX LD_LIBRARY_PATH is called LIBPATH - Always use LD_LIBRARY_PATH macro instead of using the string " LD_LIBRARY_PATH" directly to cope with different library path names. - Add jre/lib//jli to the standard library search path on AIX because the AIX linker doesn't support the -rpath option. - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case, AIX behaves like Linux. - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from java_md_solinux.h because the macros are redefined in the corresponding .c files anyway. src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties - Provide basic fontconfig.propertiesfor AIX. src/solaris/classes/java/lang/UNIXProcess.java.aix, src/aix/classes/sun/tools/attach/AixAttachProvider.java, src/aix/classes/sun/tools/attach/AixVirtualMachine.java, src/aix/native/sun/tools/attach/AixVirtualMachine.c - Provide AIX specific Java versions, mostly based on the corresponding Linux versions. src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java - Detect AIX operating system and return the corresponding channel and file system providers. src/solaris/classes/sun/nio/ch/Port.java - Add a callback function unregisterImpl(int fd) for implementations that need special handling when fd is removed and call it from unregister(int fd). By default the implementation of unregisterImpl(int fd) is empty except for the derived AixPollPort class on AIX. src/solaris/demo/jvmti/hprof/hprof_md.c - Add AIX support. AIX mostly behaves like Linux, with the one exception that it has no dladdr functionality. - Use the dladdr implementation from porting_aix.{c,h} on AIX. src/solaris/native/com/sun/management/UnixOperatingSystem_md.c - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory). src/solaris/native/common/jdk_util_md.h - Add AIX definitions of the ISNANF and ISNAND macros. src/solaris/native/java/io/io_util_md.c - AIX behaves like Linux in this case so check for it in the Linux branch. src/solaris/native/java/lang/UNIXProcess_md.c - AIX behaves mostly like Solraris in this case so adjust the ifdefs accordingly. src/solaris/native/java/lang/childproc.c - AIX does not understand '/proc/self' - it requires the real process ID to query the proc file system for the current process. src/solaris/native/java/net/NetworkInterface.c - Add AIX support into the Linux branch because AIX mostly behaves like AIX for IPv4. - AIX needs a special function to enumerate IPv6 interfaces and to query the MAC address. - Moved the declaration of siocgifconfRequest to the beginning a the function (as recommend by Michael McMahon) to remain C89 compatible. src/solaris/native/java/net/PlainSocketImpl.c - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the socket is closed. The default error message is then confusing. src/aix/native/java/net/aix_close.c, src/share/native/java/net/net_util.c - As recommended by Michael McMahon and Alan Bateman I've move an adapted version of linux_close.c to src/aix/native/java/net/aix_close.cbecause we also need the file and socket wrappers on AIX. - Compared to the Linux version, we've added the initialization of some previously uninitialized data structures. - Also, on AIX we don't have __attribute((constructor)) so we need to initialize manually (from JNI_OnLoad() in src/share/native/java/net/net_util.c. src/solaris/native/java/net/net_util_md.h - AIX needs the same workaround for I/O cancellation like Linux and MacOSX. src/solaris/native/java/net/net_util_md.c - SO_REUSEADDR is called SO_REUSEPORT on AIX. - On AIX we have to ignore failures due to ENOBUFS when setting the SO_SNDBUF/SO_RCVBUF socket options. src/solaris/native/java/util/TimeZone_md.c - Currently on AIX the only way to get the platform time zone is to read it from the TZ environment variable. src/solaris/native/sun/awt/awt_LoadLibrary.c - Use the dladdr from porting_aix.{c,h} on AIX. src/solaris/native/sun/awt/fontpath.c - Changed some macros from if !defined(__linux__) to if defined(__solaris__) because that's their real meaning. - Add AIX specific fontpath settings and library search paths for libfontconfig.so. src/solaris/native/sun/java2d/x11/X11SurfaceData.c - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name clashes (MIN and MAX are much too common and thexy are already defined in some AIX system headers). src/solaris/native/sun/java2d/x11/XRBackendNative.c - Handle AIX like Solaris. src/solaris/native/sun/nio/ch/Net.c - Add AIX-specific includes and constant definitions. - On AIX "socket extensions for multicast source filters" support depends on the OS version. Check for this and throw appropriate exceptions if it is requested but not supported. This is needed to pass JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c - On AIX strerror() is not thread-safe so we have to use strerror_r()instead. - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL for the directory stream end. Otherwise, 'errno' will contain the error code. - Handle some AIX corner cases for the results of the statvfs64() call. - On AIX getgrgid_r() returns ESRCH if group does not exist. src/solaris/native/sun/security/pkcs11/j2secmod_md.c - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX. test/java/lang/ProcessBuilder/Basic.java test/java/lang/ProcessBuilder/DestroyTest.java - Port this test to AIX and make it more robust (i.e. recognize the "C" locale as isEnglish(), ignore VM-warnings in the output, make sure the "grandchild" processes created by the test don't run too long (60s vs. 6666s) because in the case of test problems these processes will pollute the process space, make sure the test fails with an error and doesn't hang indefinitley in the case of a problem). *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this intended? Well, _AIX is defined in some system headers while AIX is defined by the build system. This is already used inconsistently (i.e. __linux__ vs. LINUX) and in general I try to be consistent with the style of the file where I the changes are. That said, I changes most of the occurences of AIX to _AIX. *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are they supposed to be there? We currently don't support OS/400 (later renamed into i5/OS and currently called IBM i) in our OpenJDK port but we do support it in our internel, SAP JVM build. We stripped out all the extra OS/400 functionality from the port but in some places where there is common functionality needd by both, AIX and OS/400 the OS/400 support may still be visible in the OpenJDK port. I don't think this is a real problem and it helps us to keep our internel sources in sync with the OpenJDK port. That said, I think I've removed all the references to OS/400 now. From mike.duigou at oracle.com Wed Nov 20 18:31:34 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 20 Nov 2013 10:31:34 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <528C710F.4070909@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> Message-ID: <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> - Collectors averagingDouble could use the same @implNote as in DoublePipeline. - DoublePipeline implementation could document the usage of the double array indices. - @summary in test. - I agree with Paul that refactoring as a testNG test would be nice. - I wondered at the mechanism for combining compensation values. Do you have a reference which explains the correctness? I thought perhaps directly adding the compensations together before doing compensated addition of the two sums might be better. Mike On Nov 20 2013, at 00:21 , Joe Darcy wrote: > Hi Paul, > > On 11/18/2013 07:38 AM, Paul Sandoz wrote: >> Hi Joe, >> >> You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: >> >> public final OptionalDouble average() { >> double[] avg = collect(() -> new double[2], >> (ll, i) -> { >> ll[0]++; >> ll[1] += i; >> }, >> (ll, rr) -> { >> ll[0] += rr[0]; >> ll[1] += rr[1]; >> }); >> return avg[0] > 0 >> ? OptionalDouble.of(avg[1] / avg[0]) >> : OptionalDouble.empty(); >> } >> >> That would be the most expedient way. > > Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: > > http://cr.openjdk.java.net/~darcy/8006572.3/ From bhavesh.x.patel at oracle.com Wed Nov 20 18:54:26 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Wed, 20 Nov 2013 18:54:26 +0000 Subject: hg: jdk8/tl/langtools: 8027977: javadoc dies on NumberFormat/DateFormat subclass Message-ID: <20131120185429.D7D4462717@hg.openjdk.java.net> Changeset: ef44a2971cb1 Author: bpatel Date: 2013-11-20 10:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ef44a2971cb1 8027977: javadoc dies on NumberFormat/DateFormat subclass Reviewed-by: jjg ! src/share/classes/com/sun/tools/javadoc/DocEnv.java + test/com/sun/javadoc/testCompletionFailure/TestCompletionFailure.java + test/com/sun/javadoc/testCompletionFailure/pkg1/NumberFormatTest.java From joe.darcy at oracle.com Wed Nov 20 19:37:36 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 20 Nov 2013 11:37:36 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> Message-ID: <528D0F80.5010905@oracle.com> Hi Mike, On 11/20/2013 10:31 AM, Mike Duigou wrote: > - Collectors averagingDouble could use the same @implNote as in DoublePipeline. > > - DoublePipeline implementation could document the usage of the double array indices. > > - @summary in test. I'll reflect these in the next iteration. > > - I agree with Paul that refactoring as a testNG test would be nice. While learning about testNG would be useful, I don't want to take that on right at the moment ;-) > > - I wondered at the mechanism for combining compensation values. Do you have a reference which explains the correctness? I thought perhaps directly adding the compensations together before doing compensated addition of the two sums might be better. One of the inquiries I have out to my numerical reviewer is how to best combine two compensations. In the code as written, from the perspective of one compensation, the two doubles in the other other compensation are just two more double values. So I think this is correct, if not ideal. The compensation portion of one running sum could be of vastly different magnitude than the compensation portion (or the high-order sum bits) of the other sum. Therefore, I believe a direct combination of either (sum1 + sum2) or (comp1 + comp2) would lose the numerical properties of interest here. Thanks for the feedback, -Joe > > Mike > > > On Nov 20 2013, at 00:21 , Joe Darcy wrote: > >> Hi Paul, >> >> On 11/18/2013 07:38 AM, Paul Sandoz wrote: >>> Hi Joe, >>> >>> You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: >>> >>> public final OptionalDouble average() { >>> double[] avg = collect(() -> new double[2], >>> (ll, i) -> { >>> ll[0]++; >>> ll[1] += i; >>> }, >>> (ll, rr) -> { >>> ll[0] += rr[0]; >>> ll[1] += rr[1]; >>> }); >>> return avg[0] > 0 >>> ? OptionalDouble.of(avg[1] / avg[0]) >>> : OptionalDouble.empty(); >>> } >>> >>> That would be the most expedient way. >> Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: >> >> http://cr.openjdk.java.net/~darcy/8006572.3/ > From srikalyan.chandrashekar at oracle.com Wed Nov 20 19:52:20 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Wed, 20 Nov 2013 11:52:20 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> Message-ID: <528D12F4.2070300@oracle.com> Hi Martin , apologies for the delay , was trying to get help for hosting my webrev. . Please see inline text. On 11/19/13, 10:35 PM, Martin Buchholz wrote: > Hi Kalyan, > > None of us can review your changes yet because you haven't given us a > URL of your webrev. It is located here http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ > > I've tried to make the jsr166 copy of CancelledLockLoops fail by > adjusting ITERS and TIMEOUT radically up and down, but the test just > keeps on passing for me. Hints appreciated. Bump up the timeout to 500ms and you will see a failure (i can see it consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8 latest any promoted build). > > > On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar > > wrote: > >> Suggested Fix: >> a) Decrease the timeout from 100 to 50ms which will ensure >> that the test will pass even on faster machines >> > > This doesn't look like a permanent fix - it just makes the failing > case rarer. Thats true , the other way is to make the main thread wait on TIMEOUT after firing the interrupts instead of other way round, but that would be over-optimization which probably is not desirable as well. The 50 ms was arrived at empirically after running several 100 times on multiple configurations and did not cause failures. -- Thanks kalyan Ph: (408)-585-8040 From srikalyan.chandrashekar at oracle.com Wed Nov 20 19:54:04 2013 From: srikalyan.chandrashekar at oracle.com (srikalyan) Date: Wed, 20 Nov 2013 11:54:04 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <528BB5E7.4050605@oracle.com> References: <528B016A.3080408@oracle.com> <528BB5E7.4050605@oracle.com> Message-ID: <528D135C.9000803@oracle.com> Hi David , webrev is hosted here http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ . -- Thanks kalyan Ph: (408)-585-8040 On 11/19/13, 11:03 AM, David Holmes wrote: > Hi, > > Attachments are stripped. Please post on cr.openjdk.java.net (get a > colleague to host this if you don't have an account yet.) > > Thanks, > David > > On 19/11/2013 4:12 PM, srikalyan chandrashekar wrote: >> Hi all, I am working on bug JDK-6772009 >> . >> >> Root Cause: >> The timeout value gives too much grace period on faster machines on >> which the "TO BE INTERRUPTED" threads complete faster before being >> interrupted at right time. >> >> Suggested Fix: >> a) Decrease the timeout from 100 to 50ms which will ensure that the test >> will pass even on faster machines , and ensures the threads will be >> canceled when running and anyways there is a Barrier to ensure the test >> threads all complete gracefully. >> Miscellaneous fixes >> b) Convert result from int to long(possible integer overflow otherwise) >> c) Catch BrokenBarrierException in more granular fashion in >> ReentrantLockLoop to update and print the results (which will be missed >> otherwise) >> Add more diagnostics >> d) Assign names to threads >> e) Print which threads update the 'completed' variable. >> >> I have attached the webrev for convenience as the changes are >> interleaved and is best viewed as sdiff. >> Please let me know if you have any comments or suggestions. >> >> >> >> Thank you >> From joel.franck at oracle.com Wed Nov 20 21:11:17 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 20 Nov 2013 22:11:17 +0100 Subject: RFR: JDK-8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType In-Reply-To: <528BCF7C.6030301@oracle.com> References: <20131115122636.GB7721@oracle.com> <528BCF7C.6030301@oracle.com> Message-ID: <5561D050-705C-4E38-AE02-257EB80A19A0@oracle.com> Thanks for the review, change has been pushed. cheers /Joel On 19 Nov 2013, at 21:52, Joe Darcy wrote: > Hi Joel, > > The change looks good; approved to go back. > > Thanks, > > -Joe > > On 11/15/2013 04:26 AM, Joel Borggren-Franck wrote: >> Hi >> >> Please review this javadoc clarification for j.l.annnotation.Target and >> j.l.annotation.ElementType as part of the type annotations work. >> >> Webrev: http://cr.openjdk.java.net/~jfranck/8027413/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8027413 >> >> This is based on the update to JLS from Alex: >> http://cr.openjdk.java.net/~abuckley/308.pdf (section 1.6). >> >> cheers >> /Joel > From stuart.marks at oracle.com Wed Nov 20 21:49:11 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Nov 2013 13:49:11 -0800 Subject: =?UTF-8?B?562U5aSNOiBSRlIgZm9yIEpESy03MTkwMTA2IFJNSSBiZW5jaG0=?= =?UTF-8?B?YXJrIGZhaWxzIGludGVybWl0dGVudGx5IGJlY2F1c2Ugb2YgdXNlIG9mIGZpeGU=?= =?UTF-8?B?ZCBwb3J0?= In-Reply-To: References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> <09ed5de7-e061-45b3-9f09-936a624dce1b@default> Message-ID: <528D2E57.1070001@oracle.com> Hi, sorry about the delay, I'm still backlogged from traveling. I'll get to this soon. s'marks On 11/19/13 6:27 PM, Tristan Yan wrote: > Hi Stuart > Did you get chance to review it again. > Let me know if you have any new comments or suggestions. > Thanks > Tristan > > -----????----- > ???: Tristan Yan > ????: Thursday, November 14, 2013 11:09 PM > ???: Stuart Marks > ??: core-libs-dev at openjdk.java.net > ??: ??: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port > > Thank you Stuart > It took me a little time to correct the code. sorry be late. This is new webrev for the code change. Please help to review it again. > > Description: > 1. Convert shell script test to Java program test. > 2. Using random server port by reusing Darryl Mocek's work(TestLibrary.getUnusedRandomPort) to replace fixed server port. > 3. Because TestLibrary doesn't have package. Here is using reflection to call TestLibrary.getUnusedRandomPort. This is going to change when TestLibrary moves to named package. > 4. Using java Process class to start client process. Client and server are sharing IO. > 5. Also convert other shell script test runSerialBench.sh to java program test also. > 6. ProblemList has been changed to get back java/rmi/reliability/benchmark/runRmiBench.sh test. > > http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ > > Thank you so much > Tristan > > > -----????----- > ???: Stuart Marks > ????: Tuesday, November 12, 2013 11:38 PM > ???: Tristan Yan > ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline > ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port > > Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" port range that's used by some RMI tests that have to used fixed ports. > > s'marks > > On 11/11/13 2:39 PM, Tristan Yan wrote: >> Hi Stuart >> Also there is one more solution, which is there is one >> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same >> function as >> TestLibrary.getUnusedRandomPort() and it has named package. Do you >> mind I use this one? >> Since these two functions provide same functionality. Maybe we should >> think about to merge them at the same time. >> Thank you >> Tristan >> >> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>> Hi Stuart >>> I tried your suggestion but unfortunately all the benchmarks have >>> dependencies to Main class because they need get stub from server. I >>> suggest we move the benchmark tests to unnamed package unless we do >>> want to put TestLibrary into a named package right now. >>> Please let me know if you have objection on this. >>> Thank you >>> Tristan >>> >>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>> Hi Tristan, >>>> >>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>> unnamed package. Classes in a named package cannot import classes >>>> from the unnamed package. We've run into problems with this before. >>>> Eventually, we should move TestLibrary a named package. >>>> >>>> I think it's possible to work around this without too much >>>> difficulty. Note that classes in the unnamed package can import classes from named packages. >>>> So, perhaps you can put the RmiBench main class in the unnamed >>>> package so it has access to TestLibrary. Then have the benchmarks >>>> themselves in the bench.rmi package. The config file already >>>> references the benchmarks by fully qualified class name (e.g., >>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able to get this to work. >>>> >>>> s'marks >>>> >>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>> Thank you, Stuart >>>>> There is one review point I want to ask you opinion. Which is the >>>>> reason that I moved from >>>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>>> class, I couldn't find a way to let a class which has Package to access the class without package. Do you have suggestion on that? >>>>> Thank you so much. >>>>> Tristan >>>>> >>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>> >>>>>> >>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>> Hi Everyone >>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>> >>>>>>> Description: >>>>>>> 1. Convert shell script test to Java program test. >>>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>>> replace fixed server port. >>>>>>> 3. Using java Process class to start client process. >>>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>>> program test also >>>>>> >>>>>> Hi Tristan, >>>>>> >>>>>> Several comments on this webrev. >>>>>> >>>>>> >>>>>> ** The original arrangement within the >>>>>> test/java/rmi/reliability/benchmark >>>>>> directory had the main benchmark files (scripts) at the top, some >>>>>> benchmark framework files in the "bench" subdirectory, and the >>>>>> actual RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>>> >>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>> directory but leaves the serial benchmarks in bench/serial. The >>>>>> RMI benchmarks are now all cluttering the top directory, but the >>>>>> main serial benchmark test is now buried in the bench/serial >>>>>> directory. The nice organization that was there before is now >>>>>> spoiled. Is this rearrangement necessary in order to convert the scripts to Java? I would prefer the original arrangement be left in place. >>>>>> >>>>>> >>>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>>> >>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>>>> -c config >>>>>> >>>>>> There is a subtle but serious problem here: the -server option is >>>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>>> The main() method gets neither a -server nor a -client argument, >>>>>> so its default "run mode" as defined by the benchmark itself is >>>>>> SAMEVM. This runs the client and server in the same JVM, which is >>>>>> different from the shell script, which ran separate client and server JVMs. >>>>>> >>>>>> >>>>>> ** The logic to process the -server argument still expects to take >>>>>> a port, even though the port is assigned automatically. So the >>>>>> obvious fix to the above, >>>>>> >>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>>>> -c config >>>>>> >>>>>> doesn't work, since a port is missing. The logic to increment the >>>>>> argument index to collect the port argument should be removed. >>>>>> Also, the -server line should be restored to the usage message, but without the port argument. >>>>>> >>>>>> >>>>>> ** After this is done, the client's command line is constructed improperly. >>>>>> The command line ends up looking something like this: >>>>>> >>>>>> java client -cp Main client localhost:58583 -c >>>>>> config >>>>>> >>>>>> The word "client" appears twice, but what's really required is >>>>>> "-client" to appear as an argument after Main. >>>>>> >>>>>> >>>>>> ** The client is run using ProcessBuilder, which by default sends >>>>>> stdout and stderr to pipes to be read by the parent. But the >>>>>> parent never reads them, thus any messages from the client are >>>>>> never seen. The client is the one that emits the benchmark report, >>>>>> so its output needs to be seen. It might be sufficient to have the >>>>>> client inherit the parent's stdout and stderr. This might intermix >>>>>> the client's and server's output, but it's better than nothing. >>>>>> >>>>>> >>>>>> ** The config file is checked with the following code: >>>>>> >>>>>> try { >>>>>> confFile = args[i]; >>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>> + System.getProperty("file.separator") + confFile); >>>>>> } catch (IOException e) { >>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>> } >>>>>> >>>>>> This is potentially misleading, as the message doesn't print the >>>>>> actual filename that was attempted to be opened. >>>>>> >>>>>> This is important, as the test.src property doesn't exist in the client JVM. >>>>>> >>>>>> Note that the original shell script passed full pathnames for the >>>>>> config file to both the client and the server. The new @run tag >>>>>> merely says "-c config" which redefines the config filename to be >>>>>> relative to the test.src directory. You could pass -Dtest.src=... >>>>>> to the client, but it seems like there should be something better than can be done. >>>>>> >>>>>> >>>>>> ** The client needs to have its security policy set up. This is >>>>>> missing from the construction of the client's command line. >>>>>> >>>>>> >>>>>> ** ProcessBuilder takes a List for its command; there is >>>>>> no need to turn the list into an array. >>>>>> >>>>>> >>>>>> ** In the benchmark main methods, code of the form, >>>>>> >>>>>> while (true) { >>>>>> runBenchmarks(); >>>>>> if (exitRequested) { >>>>>> System.exit(); >>>>>> } >>>>>> } >>>>>> >>>>>> was replaced with >>>>>> >>>>>> while (!exitRequested) { >>>>>> runBenchmarks(); >>>>>> } >>>>>> >>>>>> This is a subtle logic change, in that the former code always >>>>>> executed the loop at least once. It seems unlikely, but it's >>>>>> possible that a timer could set exitRequested before loop entry, >>>>>> resulting in the benchmark running zero times. I guess, if you >>>>>> really want to clean this up (we do need to avoid System.exit in jtreg tests), use a do-while loop instead. >>>>>> >>>>>> >>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>>> ProblemList.txt. >>>>>> >>>>>> >>>>>> ** Remove the references to RMISecurityManager and just use >>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>> RMISecurityManager last week.) :-) >>>>>> >>>>>> >>>>>> It would be good if you could fix up these issues and post another webrev. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> s'marks >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Thank you >>>>>>> Tristan >>>>>>> >>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>> I am working on bug >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my >>>>>>>>> research, it looks like the issue of fixed port was already >>>>>>>>> addressed by Stuart Marks in other RMI tests which are Java based. I would like to reuse his solution, however it does not work for shell based tests. >>>>>>>> >>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>> >>>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>>> through. Most OpenJDK mailing lists strip off attachments before >>>>>>>> forwarding Hi Stuart Also there is one more solution, which is >>>>>>>> there is one >>>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>>>> same function as TestLibrary.getUnusedRandomPort() and it has named package. >>>>>>>> Do you mind I use this one? >>>>>>>> Since these two function provide same functionality. Maybe we >>>>>>>> should think about to merge them. >>>>>>>> Thank you >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>>> Hi Stuart >>>>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>>>> have dependencies to Main class because they need get stub from >>>>>>>>> server. I suggest we move the benchmark tests to unnamed >>>>>>>>> package unless we do want to put TestLibrary into a named package right now. >>>>>>>>> Please let me know if you have objection on this. >>>>>>>>> Thank you >>>>>>>>> Tristan >>>>>>>>> >>>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>>> Hi Tristan, >>>>>>>>>> >>>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>>>> this before. Eventually, we should move TestLibrary a named package. >>>>>>>>>> >>>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>>> Note that classes in the unnamed package can import classes >>>>>>>>>> from named packages. So, perhaps you can put the RmiBench main >>>>>>>>>> class in the unnamed package so it has access to TestLibrary. >>>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>>> qualified class name (e.g., >>>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>>>> be able to get this to work. >>>>>>>>>> >>>>>>>>>> s'marks >>>>>>>>>> >>>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>>> Thank you, Stuart >>>>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>>>> the reason that I moved from >>>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way to >>>>>>>>>>> let a class which has Package to access the class without package. Do you have suggestion on that? >>>>>>>>>>> Thank you so much. >>>>>>>>>>> Tristan >>>>>>>>>>> >>>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>>> Hi Everyone >>>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Description: >>>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>>>> to replace fixed server port. >>>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh >>>>>>>>>>>>> to java program test also >>>>>>>>>>>> >>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>> >>>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>>>> RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. >>>>>>>>>>>> >>>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>>>> but the main serial benchmark test is now buried in the bench/serial directory. >>>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>>> scripts to Java? I would prefer the original arrangement be left in place. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>>>>> form, >>>>>>>>>>>> >>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>>>>> Main -c config >>>>>>>>>>>> >>>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>>> option is passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>>> argument, so its default "run mode" as defined by the benchmark itself is SAMEVM. >>>>>>>>>>>> This runs the client and server in the same JVM, which is >>>>>>>>>>>> different from the shell script, which ran separate client and server JVMs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** The logic to process the -server argument still expects >>>>>>>>>>>> to take a port, even though the port is assigned >>>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>>> >>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>>>> -server -c config >>>>>>>>>>>> >>>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>>> increment the argument index to collect the port argument >>>>>>>>>>>> should be removed. Also, the -server line should be restored >>>>>>>>>>>> to the usage message, but without the port argument. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>>> constructed improperly. The command line ends up looking something like this: >>>>>>>>>>>> >>>>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>>>> -c config >>>>>>>>>>>> >>>>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>>> But the parent never reads them, thus any messages from the client are never seen. >>>>>>>>>>>> The client is the one that emits the benchmark report, so >>>>>>>>>>>> its output needs to be seen. It might be sufficient to have >>>>>>>>>>>> the client inherit the parent's stdout and stderr. This >>>>>>>>>>>> might intermix the client's and server's output, but it's better than nothing. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>>> >>>>>>>>>>>> try { >>>>>>>>>>>> confFile = args[i]; >>>>>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>>>> >>>>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>>>> the client JVM. >>>>>>>>>>>> >>>>>>>>>>>> Note that the original shell script passed full pathnames >>>>>>>>>>>> for the config file to both the client and the server. The >>>>>>>>>>>> new @run tag merely says "-c config" which redefines the >>>>>>>>>>>> config filename to be relative to the test.src directory. >>>>>>>>>>>> You could pass -Dtest.src=... to the client, but it seems >>>>>>>>>>>> like there should be something better than can be done. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>>> >>>>>>>>>>>> while (true) { >>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>> if (exitRequested) { >>>>>>>>>>>> System.exit(); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> was replaced with >>>>>>>>>>>> >>>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>>> always executed the loop at least once. It seems unlikely, >>>>>>>>>>>> but it's possible that a timer could set exitRequested >>>>>>>>>>>> before loop entry, resulting in the benchmark running zero >>>>>>>>>>>> times. I guess, if you really want to clean this up (we do >>>>>>>>>>>> need to avoid System.exit in jtreg tests), use a do-while loop instead. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>>>> from ProblemList.txt. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>>>> another webrev. >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> s'marks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thank you >>>>>>>>>>>>> Tristan >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests >>>>>>>>>>>>>>> which are Java based. I would like to reuse his solution, >>>>>>>>>>>>>>> however it does not work for shell based tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>>>> get through. Most OpenJDK mailing lists strip off >>>>>>>>>>>>>> attachments before forwarding the message to the >>>>>>>>>>>>>> recipients. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>>> script test into Java based test and re-use the dynamic >>>>>>>>>>>>>>> port allocation solution by Stuart Marks to address the >>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>>>> shell script. In the past there have been sync issues >>>>>>>>>>>>>>> between server/client which caused the test to fail. If >>>>>>>>>>>>>>> we convert the shell script into Java based test, it >>>>>>>>>>>>>>> would avoid using "sleep 10" mechanism to allow for >>>>>>>>>>>>>>> server and client to start up and also give us better >>>>>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>>>>> >>>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>>>> quite difficult to make reliable shell tests, especially >>>>>>>>>>>>>> for multi-process tests like this one. >>>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>>> issue of how long for the client to wait until the server >>>>>>>>>>>>>> is ready. Error handling is also a problem, for example, >>>>>>>>>>>>>> if one of the JVMs gets an unexpected exception, it's easy >>>>>>>>>>>>>> for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>>> erroneously report success. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) >>>>>>>>>>>>>> and then post a link to it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> s'marks >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> the message to >>>>>>>> the recipients. >>>>>>>> >>>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>>> into Java based test and re-use the dynamic port allocation >>>>>>>>> solution by Stuart Marks to address the issue >>>>>>>>> >>>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>>> In the >>>>>>>>> past there have been sync issues between server/client which >>>>>>>>> caused the test to fail. If we convert the shell script into >>>>>>>>> Java based test, it would avoid using "sleep 10" mechanism to >>>>>>>>> allow for server and client to start up and also give us better >>>>>>>>> control in synchronizing server and client. >>>>>>>> >>>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>>> difficult to make reliable shell tests, especially for >>>>>>>> multi-process tests like this one. >>>>>>>> There is the unique port issue, and there is also the issue of >>>>>>>> how long for the client to wait until the server is ready. Error >>>>>>>> handling is also a problem, for example, if one of the JVMs gets >>>>>>>> an unexpected exception, it's easy for shell tests to mishandle >>>>>>>> this case. They might hang or erroneously report success. >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>>> upload it somewhere (e.g., cr.openjdk.java.net) and then post a link to it. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> s'marks >>>>>>> >>>>> >>>> >>> >> From alan.bateman at oracle.com Wed Nov 20 21:36:54 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 20 Nov 2013 21:36:54 +0000 Subject: hg: jdk8/tl/jdk: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone Message-ID: <20131120213710.E21EF6271F@hg.openjdk.java.net> Changeset: ecd6c25b54ce Author: alanb Date: 2013-11-20 21:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecd6c25b54ce 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone Reviewed-by: naoto ! test/java/util/Locale/InternationalBAT.java From forax at univ-mlv.fr Wed Nov 20 22:54:56 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 20 Nov 2013 23:54:56 +0100 Subject: Map.Entry.setValue as a default method Message-ID: <528D3DC0.4000508@univ-mlv.fr> A good question of one of my student, why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics. regards, R?mi From mike.duigou at oracle.com Wed Nov 20 23:07:51 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 20 Nov 2013 15:07:51 -0800 Subject: Map.Entry.setValue as a default method In-Reply-To: <528D3DC0.4000508@univ-mlv.fr> References: <528D3DC0.4000508@univ-mlv.fr> Message-ID: <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> It could still be added in a future rev. setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate. We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit. Mike On Nov 20 2013, at 14:54 , Remi Forax wrote: > A good question of one of my student, > why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics. > > regards, > R?mi > From martinrb at google.com Thu Nov 21 00:28:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 20 Nov 2013 16:28:58 -0800 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <528D12F4.2070300@oracle.com> References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> <528D12F4.2070300@oracle.com> Message-ID: I again tried and failed to reproduce a failure. Even if I go whole hog and multiply TIMEOUT by 100 and divide ITERS by 100, the test continues to PASS. Is it just me?! I don't think there's any reason to make result long. It's not even used except to inhibit hotspot optimizations. + private volatile long result = 17;//Can get int overflow,so using long need to fix spelling and spacing below. + barrier.await();//If a BrokeBarrierException happens here(due to On Wed, Nov 20, 2013 at 11:52 AM, srikalyan < srikalyan.chandrashekar at oracle.com> wrote: > Hi Martin , apologies for the delay , was trying to get help for hosting > my webrev. . Please see inline text. > > > On 11/19/13, 10:35 PM, Martin Buchholz wrote: > > Hi Kalyan, > > None of us can review your changes yet because you haven't given us a > URL of your webrev. > > It is located here > http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ > > > I've tried to make the jsr166 copy of CancelledLockLoops fail by > adjusting ITERS and TIMEOUT radically up and down, but the test just keeps > on passing for me. Hints appreciated. > > Bump up the timeout to 500ms and you will see a failure (i can see it > consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8 > latest any promoted build). > > > > On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar < > srikalyan.chandrashekar at oracle.com> wrote: > >> Suggested Fix: >>> a) Decrease the timeout from 100 to 50ms which will ensure that the test >>> will pass even on faster machines >>> >> > This doesn't look like a permanent fix - it just makes the failing case > rarer. > > Thats true , the other way is to make the main thread wait on TIMEOUT > after firing the interrupts instead of other way round, but that would be > over-optimization which probably is not desirable as well. The 50 ms was > arrived at empirically after running several 100 times on multiple > configurations and did not cause failures. > > -- > Thanks > kalyan > Ph: (408)-585-8040 > > > From forax at univ-mlv.fr Thu Nov 21 00:31:22 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 21 Nov 2013 01:31:22 +0100 Subject: Map.Entry.setValue as a default method In-Reply-To: <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> References: <528D3DC0.4000508@univ-mlv.fr> <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> Message-ID: <528D545A.8020109@univ-mlv.fr> Hi mike, On 11/21/2013 12:07 AM, Mike Duigou wrote: > It could still be added in a future rev. yes, I've post that here as a remainder for the future generation :) > setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate. Totally appropriate because a lot of people forget to implement them when implementing Map.Entry, 3 or 4 years back, hibernate collections had that issue, by example. But while you can declare a default hashCode and equals, it will not work because the implementation of Object.hashCode and Object.equals will always be preferred to the default methods by the VM, this is how default methods are specified. Not something I'm very proud. > We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit. > > Mike R?mi > > On Nov 20 2013, at 14:54 , Remi Forax wrote: > >> A good question of one of my student, >> why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics. >> >> regards, >> R?mi >> From mike.duigou at oracle.com Thu Nov 21 00:38:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 20 Nov 2013 16:38:35 -0800 Subject: Map.Entry.setValue as a default method In-Reply-To: <528D545A.8020109@univ-mlv.fr> References: <528D3DC0.4000508@univ-mlv.fr> <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> <528D545A.8020109@univ-mlv.fr> Message-ID: On Nov 20 2013, at 16:31 , Remi Forax wrote: > Hi mike, > > On 11/21/2013 12:07 AM, Mike Duigou wrote: >> It could still be added in a future rev. > > yes, I've post that here as a remainder for the future generation :) > >> setValue was less compelling and obviously correct than Iterator.remove(). I had a version of Map.Entry earlier on which provided provided setValue() along defaults for the required implementations of hashCode() and equals(). The spec for these later two methods is part of the API so defaults seemed appropriate. > > Totally appropriate because a lot of people forget to implement them when implementing Map.Entry, > 3 or 4 years back, hibernate collections had that issue, by example. > > But while you can declare a default hashCode and equals, it will not work because the implementation of Object.hashCode and Object.equals will always be preferred to the default methods by the VM, this is how default methods are specified. Not something I'm very proud. Ah, yes. It had worked for a while but then that decision was made. > >> We essentially didn't implement them to avoid scope creep--none of these were strictly necessary for our other goals. For Iterator.remove() we could get immediate benefit. >> >> Mike > > R?mi > > >> >> On Nov 20 2013, at 14:54 , Remi Forax wrote: >> >>> A good question of one of my student, >>> why Iterator.remove() is a default method that throws UOE in 8 but Map.Entry.setValue() is not a default method with the same semantics. >>> >>> regards, >>> R?mi >>> > From john.r.rose at oracle.com Thu Nov 21 01:08:50 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 20 Nov 2013 17:08:50 -0800 Subject: Map.Entry.setValue as a default method In-Reply-To: <528D545A.8020109@univ-mlv.fr> References: <528D3DC0.4000508@univ-mlv.fr> <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> <528D545A.8020109@univ-mlv.fr> Message-ID: On Nov 20, 2013, at 4:31 PM, Remi Forax wrote: > But while you can declare a default hashCode and equals, it will not work because the implementation of Object.hashCode and Object.equals will always be preferred to the default methods by the VM, this is how default methods are specified. Not something I'm very proud. Next question: What's the best practice for declaring reusable code for exactly those restricted methods (hashCode/equals, toString)? Because of the irregularity with Object, the opt-in isn't by default, but there should still be a convention for supplying the code as a "would-be default method". Maybe one of: interface KoolReusablePair { default boolean defaultEquals(Object x) { ... } static int hashCode(KoolReusablePair self) { ... } ... } class KoolImpl implements KoolReusablePair { @Override //manual opt-in: public boolean equals(Object x) { return KoolReusablePair.super.defaultEquals(x); } @Override //manual opt-in: public int hashCode() { return KoolReusablePair.hashCode(this); } ... } ? John From dan.xu at oracle.com Thu Nov 21 01:09:02 2013 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 20 Nov 2013 17:09:02 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528CA627.9000108@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> Message-ID: <528D5D2E.9080307@oracle.com> Hi All, I have updated my fix based on your suggestions. I have changed to create testing files in the working directory, moved those static member variables into local method variables, and used try-with-resources to read and write the testing files. After the change, the file delete is no longer important. So I just do the clean-up with deleteOnExit() for simplicity. If the test fails, it is better to keep the test file to give more clue. Therefore, I don't put the file clean-up into finally block. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ -Dan On 11/20/2013 04:08 AM, Alan Bateman wrote: > On 19/11/2013 23:57, Dan Xu wrote: >> Hi All, >> >> Please review the simple fix towards Size.java testcase. It failed >> once on windows platform in the recent same binary run, which is >> mostly due to some interferences and the special delete handling on >> windows. >> >> In the fix, I remove the delete operation in initTestFile() method >> because FileOutputStream will truncate the file content and it is not >> necessary to delete it first. Thanks! >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 >> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ >> > This does look like a case where the test is needlessly deleting and > re-creating the file (although still annoying to have interference > from virus checkers or other background services). As you point out, > FileOutputStream will truncate an existing file so it's not needed. So > I think your changes to remove the exist/delete from the init method > is good. > > If you have the cycles then there are probably a few clean-ups that > could be done on this test. I don't think blah needs to be static, it > could use try-with-resources and delete blah in the finally block. > Also test2 looks historical, it may be that this can be enabled on > Linux and Windows now (the bug/comments seem to date from JDK 1.4). > > -Alan > From david.holmes at oracle.com Thu Nov 21 02:35:24 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Nov 2013 12:35:24 +1000 Subject: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: References: <528B016A.3080408@oracle.com> <528C20FA.9090303@oracle.com> <528D12F4.2070300@oracle.com> Message-ID: <528D716C.3030502@oracle.com> On 21/11/2013 10:28 AM, Martin Buchholz wrote: > I again tried and failed to reproduce a failure. Even if I go whole hog > and multiply TIMEOUT by 100 and divide ITERS by 100, the test continues to > PASS. Is it just me?! I think you are going the wrong way Martin - you want the timeout to be smaller than the time it takes to execute ITERS. > I don't think there's any reason to make result long. It's not even used > except to inhibit hotspot optimizations. > > + private volatile long result = 17;//Can get int overflow,so using long Further the subsequent use of += is incorrect as it is not an atomic operation. Even if we don't care about the value, it looks bad. I'm not sure result must be updated if we get a BrokenBarrierException either. Probably harmless, but necessary? > need to fix spelling and spacing below. > > + barrier.await();//If a BrokeBarrierException happens > here(due to There are a number of style issues with spacing around comments. And I don't think this change is sufficient to claim co-author status with Doug either ;-) The additional tracing may be useful but seems stylistically different from the rest of the code. Overall I'm suspicious that the changed timeout actually fixes anything - normally we need to add longer timeouts not shorter ones. Does this fail on a range of machines or only specific ones? Have we verified that the clocks/timers are behaving properly on those systems? Thanks, David > > > > On Wed, Nov 20, 2013 at 11:52 AM, srikalyan < > srikalyan.chandrashekar at oracle.com> wrote: > >> Hi Martin , apologies for the delay , was trying to get help for hosting >> my webrev. . Please see inline text. >> >> >> On 11/19/13, 10:35 PM, Martin Buchholz wrote: >> >> Hi Kalyan, >> >> None of us can review your changes yet because you haven't given us a >> URL of your webrev. >> >> It is located here >> http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ >> >> >> I've tried to make the jsr166 copy of CancelledLockLoops fail by >> adjusting ITERS and TIMEOUT radically up and down, but the test just keeps >> on passing for me. Hints appreciated. >> >> Bump up the timeout to 500ms and you will see a failure (i can see it >> consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8 >> latest any promoted build). >> >> >> >> On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar < >> srikalyan.chandrashekar at oracle.com> wrote: >> >>> Suggested Fix: >>>> a) Decrease the timeout from 100 to 50ms which will ensure that the test >>>> will pass even on faster machines >>>> >>> >> This doesn't look like a permanent fix - it just makes the failing case >> rarer. >> >> Thats true , the other way is to make the main thread wait on TIMEOUT >> after firing the interrupts instead of other way round, but that would be >> over-optimization which probably is not desirable as well. The 50 ms was >> arrived at empirically after running several 100 times on multiple >> configurations and did not cause failures. >> >> -- >> Thanks >> kalyan >> Ph: (408)-585-8040 >> >> >> From stuart.marks at oracle.com Thu Nov 21 03:09:16 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Nov 2013 19:09:16 -0800 Subject: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java In-Reply-To: <528BDAFF.80108@oracle.com> References: <528B7595.6090201@oracle.com> <528B7E33.9080203@oracle.com> <528BDAFF.80108@oracle.com> Message-ID: <528D795C.9030704@oracle.com> On 11/19/13 1:41 PM, Alan Bateman wrote: > On 19/11/2013 20:14, Martin Buchholz wrote: >> In jsr166 tests we have mostly switched to 10 second timeouts to mean "forever". >> But in ProcessBuilder tests we are starting up new java processes with their >> well-known startup problems, so using a much larger value of "forever" seems >> reasonable. I vote for 1 minute. You can write >> >> waitFor(1, TimeUnit.MINUTES); >> > I agree that a timeout on that order might be needed when starting process. > However I think this one is just starting a thread that exercises the new > waitFor method. I'll share a discussion we had before I pushed my "fix" yesterday that raised a timeout from 30 to 60 seconds. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138 Some of the test machines in our test farm can be startlingly, even absurdly slow. In this case part of the test involved having a parent process fork a child process, and the child turns around and connects back to the parent. There's a 30 second timeout for this. It should never timeout, right? But it did in our testing environment. One clue is that on my laptop, this test (including framework setup and teardown) took about 8 seconds to run. The test log of the failure showed that the test took 2 MINUTES AND 49 SECONDS to run. (This was on 32-bit Windows, of course.) I can only guess at what causes the machines to run so slowly (virus scanning? other VMs running on the same host?) but sometimes they can be so slow that the unbelievable happens. s'marks From stuart.marks at oracle.com Thu Nov 21 03:32:37 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Nov 2013 19:32:37 -0800 Subject: RFR: 8028185 - XMLFormatter.format emits incorrect year In-Reply-To: <528BA284.5010100@oracle.com> References: <528B3C27.3000608@oracle.com> <528BA284.5010100@oracle.com> Message-ID: <528D7ED5.9080703@oracle.com> On 11/19/13 9:40 AM, Mandy Chung wrote: > On 11/19/13 2:23 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a webrev for: >> >> 8028185: XMLFormatter.format emits incorrect year >> https://bugs.openjdk.java.net/browse/JDK-8028185 >> >> The fix is trivial: >> http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ > > Looks good. Nit: the test can use StringBuilder which is generally in > preference to StringBuffer unless synchronization is required. > > The kind of warning fix [1] causing this regression should probably have a > regression test to go with it to verify the change. > > thanks > Mandy > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36 Interesting and subtle. To save others the research, the changeset that introduced the regression removed a deprecation warning by replacing Date.getYear() + 1900 with Calendar.get(Calendar.YEAR) + 1900 This is incorrect and thus introduced the regression. The javadoc for Date.getYear() says to replace calls to it with: Calendar.get(Calendar.YEAR) - 1900 So, during warnings cleanup, a careful review of the code change plus the javadoc for the deprecated method being replaced would have revealed the error. Obviously, though, it's difficult always to be sufficiently careful in practice. Alan said earlier, > This one is a good reminder as to how fixing warnings can break things. I think this is true. The warnings fixes aren't risk-free. For example, even generifying code can introduce ClassCastExceptions if the original code were to put values of different types into collections. This style has always been rare, but older code would do things like that. Instead of writing regression tests for warnings fixes, though, I think I'd rather have good unit tests for a particular area. That way, general maintenance, as well as cleanups (like fixing warnings) are better protected against regressions. s'marks From patrick.zhang at oracle.com Thu Nov 21 03:58:52 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Thu, 21 Nov 2013 11:58:52 +0800 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <527B0D72.703@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> Message-ID: <528D84FC.9090802@oracle.com> Hi Everyone, I am working on https://bugs.openjdk.java.net/browse/JDK-8027973. The problem is caused by wrong URL format on windows. file://c:\xxx is one invalid schema. Solution: Replace "file://" with "file:///" then it will work on windows and it will not impact other platforms. And remove the test from ProblemList.txt webrev: http://cr.openjdk.java.net/~pzhang/8027973/webrev/ Result on windows: http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.jtr Result on Linux: http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.linux.jtr Regards Patrick From stuart.marks at oracle.com Thu Nov 21 04:04:25 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 20 Nov 2013 20:04:25 -0800 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <52864D7F.3040104@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> <52842184.4030606@oracle.com> <5285631E.6060801@oracle.com> <52864D7F.3040104@oracle.com> Message-ID: <528D8649.2070703@oracle.com> On 11/15/13 8:36 AM, Alan Bateman wrote: > On 14/11/2013 23:56, Stuart Marks wrote: >> >> On 11/14/13 2:04 AM, David Holmes wrote: >>> Sorry for the delay (been enroute). Only issue I have remains the subSequence >>> change - you can't weaken the post-condition of CharSequence.subSequence without >>> breaking subtype substitutability. >> >> Yes, in general, what you say about weakening post-conditions is true. In this >> case, though, I can't see how it can cause any practical harm. > I've looked through the webrev and read the exchange between you and David. > > I think it might be better to leave the subSequence change out for now (the > @apiNote is fine) and submit another bug to track the discrepancy between the > spec and implementation. From what I can tell, this has existed since > CharSequence was added in 1.4, in which case there may be a good argument to > just document the potential deviation. OK, I'll remove the String.subSequence change from this changeset and push it when I get approval. I've filed this bug: https://bugs.openjdk.java.net/browse/JDK-8028757 to cover the CharSequence.subSequence issue and potential spec change. It probably isn't that much work to do, but it probably is easier to handle it separately. s'marks From huizhe.wang at oracle.com Thu Nov 21 05:20:09 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 20 Nov 2013 21:20:09 -0800 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <528D84FC.9090802@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> Message-ID: <528D9809.6050208@oracle.com> Thanks for working on the issue. The fix looks good. Regards, Joe On 11/20/2013 7:58 PM, Patrick Zhang wrote: > Hi Everyone, > > I am working on https://bugs.openjdk.java.net/browse/JDK-8027973. The > problem is caused by wrong URL format on windows. file://c:\xxx is one > invalid schema. > > Solution: > Replace "file://" with "file:///" then it will work on windows and it > will not impact other platforms. And remove the test from ProblemList.txt > > webrev: > http://cr.openjdk.java.net/~pzhang/8027973/webrev/ > > Result on windows: > http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.jtr > Result on Linux: > http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.linux.jtr > > Regards > Patrick From daniel.fuchs at oracle.com Thu Nov 21 09:31:38 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 21 Nov 2013 10:31:38 +0100 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <528D84FC.9090802@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> Message-ID: <528DD2FA.8030202@oracle.com> On 11/21/13 4:58 AM, Patrick Zhang wrote: > Hi Everyone, > > I am working on https://bugs.openjdk.java.net/browse/JDK-8027973. The > problem is caused by wrong URL format on windows. file://c:\xxx is one > invalid schema. > > Solution: > Replace "file://" with "file:///" then it will work on windows and it > will not impact other platforms. And remove the test from ProblemList.txt Hi Patrick, I didn't know windows needed a triple '/' - I think I learned something today ;-) May I suggest that you add the description of the problem & solution (the text you wrote above) in comment in the test? It may save a lot of time to future maintainers - I think I would have had a hard time to figure that out by myself :-) best regards, -- daniel > > webrev: > http://cr.openjdk.java.net/~pzhang/8027973/webrev/ > > Result on windows: > http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.jtr > Result on Linux: > http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.linux.jtr > > Regards > Patrick From Alan.Bateman at oracle.com Thu Nov 21 09:33:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 09:33:58 +0000 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <528D9809.6050208@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> <528D9809.6050208@oracle.com> Message-ID: <528DD386.4020902@oracle.com> On 21/11/2013 05:20, huizhe wang wrote: > Thanks for working on the issue. The fix looks good. Looks good to me too (very subtle). (A side point but should "jdk" be dropped from the directory name so that it is a bit more consistent with the tests in the test/javax/xml tree). -Alan From Alan.Bateman at oracle.com Thu Nov 21 09:41:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 09:41:42 +0000 Subject: RFR(2): 7174936: several String methods claim to always create new String In-Reply-To: <528D8649.2070703@oracle.com> References: <527AED79.2010702@oracle.com> <52825AAD.7030006@oracle.com> <52842184.4030606@oracle.com> <5285631E.6060801@oracle.com> <52864D7F.3040104@oracle.com> <528D8649.2070703@oracle.com> Message-ID: <528DD556.9080905@oracle.com> On 21/11/2013 04:04, Stuart Marks wrote: > > OK, I'll remove the String.subSequence change from this changeset and > push it when I get approval. > > I've filed this bug: > > https://bugs.openjdk.java.net/browse/JDK-8028757 > > to cover the CharSequence.subSequence issue and potential spec change. > It probably isn't that much work to do, but it probably is easier to > handle it separately. Thanks, I think this is the best approach given that the subSequence issue may require clearly documenting the deviation from how it is specified in CharSequence. -Alan From patrick.zhang at oracle.com Thu Nov 21 10:48:32 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Thu, 21 Nov 2013 18:48:32 +0800 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <528DD386.4020902@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> <528D9809.6050208@oracle.com> <528DD386.4020902@oracle.com> Message-ID: <528DE500.2010808@oracle.com> Hi Alan, I have renamed "jdk8004476" to "8004476". And as Daniel's suggestion, add some comments to XSLTExFuncTest.java. I have updated the webrev for review. http://cr.openjdk.java.net/~pzhang/8027973/webrev/ Regards Patrick On 11/21/13 5:33 PM, Alan Bateman wrote: > On 21/11/2013 05:20, huizhe wang wrote: >> Thanks for working on the issue. The fix looks good. > Looks good to me too (very subtle). > > (A side point but should "jdk" be dropped from the directory name so > that it is a bit more consistent with the tests in the test/javax/xml > tree). > > -Alan From mark.sheppard at oracle.com Thu Nov 21 11:35:13 2013 From: mark.sheppard at oracle.com (mark.sheppard at oracle.com) Date: Thu, 21 Nov 2013 11:35:13 +0000 Subject: hg: jdk8/tl/corba: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Message-ID: <20131121113515.1971C62731@hg.openjdk.java.net> Changeset: fe781b3badd6 Author: msheppar Date: 2013-11-21 11:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe781b3badd6 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung ! src/share/classes/org/omg/CORBA/ORB.java From Alan.Bateman at oracle.com Thu Nov 21 12:01:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 12:01:31 +0000 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: <528DF61B.6060403@oracle.com> On 20/11/2013 18:26, Volker Simonis wrote: > Hi, > > this is the second review round for "8024854: Basic changes and files > to build the class library on AIX > ". The previous > reviews can be found at the end of this mail in the references section. > > I've tried to address all the comments and suggestions from the first > round and to further streamline the patch (it perfectly builds on > Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). > The biggest change compared to the first review round is the new > "aix/" subdirectory which I've now created under "jdk/src" and which > contains AIX-only code. Thanks for the update and addressing all the original comments and suggestions. In particular, moving most of the AIX specific files to src/aix and including an implementation of dladdr, make a big difference and makes this much easier to review. I've skimmed through all the non-client files in the webrev and just have a few comments: NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks like it will add this to LIBNET_EXCLUDE_FILES even when building on Mac. In the old verifier code (check_code.c) then it's not clear to me that the caller wrapper is needed but in any case the change suggests to me that we should look at the malloc usages so that they better handle the size==0 case. I realize the wrappers are to avoid changing too much and it should be okay to handle this via a separate bug. In net_util.c then it's a bit ugly to be calling aix_close_init. Michael/Chris - what you would think about the JNI_OnLoad calling into a platform specific function to do platform specific initialization? The changes to java_md_solinux.c look okay to me but it makes me wonder if this should be renamed as it no longer exclusively Solaris + Linux. Port.java - one suggestion for unregisterImpl is to rename it to preUnregister and change it to protected so that it's more obvious that it supposed to be overridden. UnixNativeDispatcher.c - this looks okay (must reduced since the first round), I just wonder if the changes to *_getpwuid and *_getgrgid are really needed as this just impacts the error message. Also might be good to indent the #ifdef to be consistent with the other usages in these functions. That's mostly it. I notice that only a small number of tests have been updated. Are there more test updates to come? I'm pretty sure we have a lot more tests that may require update (searching for SunOS might give some hints). -Alan. From balchandra.vaidya at oracle.com Thu Nov 21 12:26:17 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Thu, 21 Nov 2013 12:26:17 +0000 Subject: Request to review JDK-8028094 In-Reply-To: <528CD120.3050101@oracle.com> References: <528B57BA.3060102@oracle.com> <528CD120.3050101@oracle.com> Message-ID: <528DFBE9.60003@oracle.com> Hi Martin, > + check(elapsedTimeMillis < timeout); > + *check(!reader.isAlive());* The line check(!reader.isAlive()) is causing the test failure when the pkill command is not available. Any idea ? The test is passing with check(reader.isAlive()). The modified test is passing when the pkill command is available. When the pkill command is not available, the test is/was failing without try block around new ProcessBuilder(cmdkill).start(). So, without placing the above line under try block was a mistake. I will make the correction. Thanks Balchandra On 11/20/13 03:11 PM, Balchandra Vaidya wrote: > > Thanks Martin. I will incorporate your suggested improvements, and > will send out another webrev. > > Regards > Balchandra > > On 19/11/2013 22:53, Martin Buchholz wrote: >> I see this is already submitted. >> >> I thought I could do better than using pkill, but no - there is no >> convenient communication from the java process to the grandchild. >> This is a hairy test! >> >> Nevertheless, I would like you to incorporate the following improvements: >> - invoke pkill directly >> - do some extra checking >> - join with reader thread >> - don't fail if pkill is not available >> >> --- a/test/java/lang/ProcessBuilder/Basic.java >> +++ b/test/java/lang/ProcessBuilder/Basic.java >> @@ -2016,7 +2016,7 @@ >> && new File("/bin/bash").exists() >> && new File("/bin/sleep").exists()) { >> final String[] cmd = { "/bin/bash", "-c", >> "(/bin/sleep 6666)" }; >> - final String[] cmdkill = { "/bin/bash", "-c", >> "(/usr/bin/pkill -f \"sleep 6666\")" }; >> + final String[] cmdkill = { "/usr/bin/pkill", "-f", >> "sleep 6666" }; >> final ProcessBuilder pb = new ProcessBuilder(cmd); >> final Process p = pb.start(); >> final InputStream stdout = p.getInputStream(); >> @@ -2044,7 +2044,9 @@ >> stdout.close(); >> stderr.close(); >> stdin.close(); >> - new ProcessBuilder(cmdkill).start(); >> + // Try to clean up the sleep process, but don't fret >> about it. >> + try { new ProcessBuilder(cmdkill).start(); } >> + catch (IOException noPkillCommandInstalled) { } >> //---------------------------------------------------------- >> // There remain unsolved issues with asynchronous close. >> // Here's a highly non-portable experiment to >> demonstrate: >> @@ -2063,8 +2065,14 @@ >> }; >> new ProcessBuilder(wakeupJeff).start().waitFor(); >> // If wakeupJeff worked, reader probably got EBADF. >> - reader.join(); >> } >> + long startTime = System.nanoTime(); >> + long timeout = 60L * 1000L; >> + reader.join(timeout); >> + long elapsedTimeMillis = >> + (System.nanoTime() - startTime) / (1024L * 1024L); >> + check(elapsedTimeMillis < timeout); >> + check(!reader.isAlive()); >> } >> } catch (Throwable t) { unexpected(t); } >> >> >> >> On Tue, Nov 19, 2013 at 4:21 AM, Balchandra Vaidya >> > >> wrote: >> >> >> Hi, >> >> Here is one possible solution for the issue JDK-8028094. >> http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ >> >> >> I am not sure pkill is available in all Unix flavor at /usr/bin >> directory, >> but it is present in Solaris and OEL 6. I have tested on Solaris >> and OEL and "sleep 6666" is no longer left over. >> >> >> Thanks >> Balchandra >> >> >> > From mark.sheppard at oracle.com Thu Nov 21 11:37:57 2013 From: mark.sheppard at oracle.com (mark.sheppard at oracle.com) Date: Thu, 21 Nov 2013 11:37:57 +0000 Subject: hg: jdk8/tl/jdk: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Message-ID: <20131121113853.3C1B762732@hg.openjdk.java.net> Changeset: d5d4b9a63174 Author: msheppar Date: 2013-11-21 11:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5d4b9a63174 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung + test/com/sun/corba/se/impl/orb/SetDefaultORBTest.java From erik.gahlin at oracle.com Thu Nov 21 12:46:40 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Thu, 21 Nov 2013 12:46:40 +0000 Subject: hg: jdk8/tl/jdk: 6402201: ProcessAttachTest.sh needs better synchronization Message-ID: <20131121124655.9331D62737@hg.openjdk.java.net> Changeset: 91ec3bc92793 Author: egahlin Date: 2013-11-21 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91ec3bc92793 6402201: ProcessAttachTest.sh needs better synchronization Reviewed-by: alanb ! test/ProblemList.txt ! test/com/sun/jdi/ProcessAttachDebuggee.java ! test/com/sun/jdi/ProcessAttachTest.sh From staffan.larsen at oracle.com Thu Nov 21 13:26:06 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 21 Nov 2013 13:26:06 +0000 Subject: hg: jdk8/tl/jdk: 8028632: Update jdk/test/ProblemList.txt to reflect fix JDK-8024423 Message-ID: <20131121132618.AEF2B6273A@hg.openjdk.java.net> Changeset: fc9f24b9408e Author: sla Date: 2013-11-21 12:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc9f24b9408e 8028632: Update jdk/test/ProblemList.txt to reflect fix JDK-8024423 Summary: Removed 5 testcases from the ProblemList Reviewed-by: sla Contributed-by: balchandra.vaidya at oracle.com ! test/ProblemList.txt From Alan.Bateman at oracle.com Thu Nov 21 13:41:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 13:41:18 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528D5D2E.9080307@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> Message-ID: <528E0D7E.6050706@oracle.com> On 21/11/2013 01:09, Dan Xu wrote: > Hi All, > > I have updated my fix based on your suggestions. I have changed to > create testing files in the working directory, moved those static > member variables into local method variables, and used > try-with-resources to read and write the testing files. After the > change, the file delete is no longer important. So I just do the > clean-up with deleteOnExit() for simplicity. If the test fails, it is > better to keep the test file to give more clue. Therefore, I don't put > the file clean-up into finally block. Thanks! > > Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ > > -Dan Just one thing about testLargeFile, I see that it additionally creates a file-mapping and it's not clear that this is needed (I don't see anything in JDK-4563125 to explain this). I suspect this can be removed. Otherwise it looks okay to me. -Alan. From chris.hegarty at oracle.com Thu Nov 21 13:44:33 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 21 Nov 2013 13:44:33 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131121134510.833B16273B@hg.openjdk.java.net> Changeset: 2972241cf7eb Author: tyan Date: 2013-11-21 13:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2972241cf7eb 7036666: test/com/sun/net/httpserver/Test9a.java fails intermittently Summary: Additional stacktrace information is printed on failure Reviewed-by: alanb, dfuchs, chegar ! test/ProblemList.txt ! test/com/sun/net/httpserver/Test9a.java Changeset: ed979f9b40cd Author: tyan Date: 2013-11-21 13:42 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed979f9b40cd 8022212: Intermittent test failures in java/net Reviewed-by: chegar ! test/java/net/NetworkInterface/IndexTest.java From forax at univ-mlv.fr Thu Nov 21 14:56:20 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 21 Nov 2013 15:56:20 +0100 Subject: Map.Entry.setValue as a default method In-Reply-To: References: <528D3DC0.4000508@univ-mlv.fr> <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> <528D545A.8020109@univ-mlv.fr> Message-ID: <528E1F14.2020001@univ-mlv.fr> On 11/21/2013 02:08 AM, John Rose wrote: > On Nov 20, 2013, at 4:31 PM, Remi Forax > wrote: > >> But while you can declare a default hashCode and equals, it will not >> work because the implementation of Object.hashCode and Object.equals >> will always be preferred to the default methods by the VM, this is >> how default methods are specified. Not something I'm very proud. > > Next question: What's the best practice for declaring reusable code > for exactly those restricted methods (hashCode/equals, toString)? > Because of the irregularity with Object, the opt-in isn't by default, > but there should still be a convention for supplying the code as a > "would-be default method". > > Maybe one of: > interface KoolReusablePair { > default boolean defaultEquals(Object x) { ... } > static int hashCode(KoolReusablePair self) { ... } > ... > } > > class KoolImpl implements KoolReusablePair { > @Override //manual opt-in: > public boolean equals(Object x) { return > KoolReusablePair.super.defaultEquals(x); } > @Override //manual opt-in: > public int hashCode() { return KoolReusablePair.hashCode(this); } > ... > } > > ? John The plumber in me think that a static method unlike a default method will not pollute the itable. regards, R?mi From volker.simonis at gmail.com Thu Nov 21 15:54:07 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 21 Nov 2013 16:54:07 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <528DF61B.6060403@oracle.com> References: <528DF61B.6060403@oracle.com> Message-ID: Hi Alan, thanks a lot for the fast review and your valuable comments. Please find my answers inline: On Thu, Nov 21, 2013 at 1:01 PM, Alan Bateman wrote: > On 20/11/2013 18:26, Volker Simonis wrote: > > Hi, > > this is the second review round for "8024854: Basic changes and files to > build the class library on AIX". > The previous reviews can be found at the end of this mail in the references > section. > > I've tried to address all the comments and suggestions from the first > round and to further streamline the patch (it perfectly builds on > Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The > biggest change compared to the first review round is the new "aix/" > subdirectory which I've now created under "jdk/src" and which contains > AIX-only code. > > Thanks for the update and addressing all the original comments and > suggestions. In particular, moving most of the AIX specific files to > src/aix and including an implementation of dladdr, make a big difference > and makes this much easier to review. > > I've skimmed through all the non-client files in the webrev and just have > a few comments: > > NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks like > it will add this to LIBNET_EXCLUDE_FILES even when building on Mac. > > You're right, that's a typo. That should have read: 48 ifneq ($(OPENJDK_TARGET_OS), aix) 49 LIBNET_EXCLUDE_FILES += aix_close.c 50 else 51 LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ 52 endif But actually I've just realized that it is not need at all, because 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be probably called a feature of the new file layout:) So I'll simply change it to: 48 ifeq ($(OPENJDK_TARGET_OS), aix) 49 LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ 50 endif In the old verifier code (check_code.c) then it's not clear to me that the > caller wrapper is needed but in any case the change suggests to me that we > should look at the malloc usages so that they better handle the size==0 > case. I realize the wrappers are to avoid changing too much and it should > be okay to handle this via a separate bug. > > Yes, exactly. I didn't wanted to change too much code. But as the C-Standard states ( http://pubs.opengroup.org/onlinepubs/000095399/functions/malloc.html) "...If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned..." it is perfectly legal that malloc/calloc return a NULL pointer if called with a zero argument. This case is currently not handled (i.e. it's handled as an 'out of memory' error) in check_code.c and I agree that this should be fixed via a separate bug. > In net_util.c then it's a bit ugly to be calling aix_close_init. > Michael/Chris - what you would think about the JNI_OnLoad calling into a > platform specific function to do platform specific initialization? > > What about renaming 'initLocalAddrTable()' into something like 'platformInit()' and moving the call to 'aix_close_init' to a AIX-specific version of 'platformInit()' in net_util_md.c? > The changes to java_md_solinux.c look okay to me but it makes me wonder if > this should be renamed as it no longer exclusively Solaris + Linux. > > You're right - we could rename it to something like 'java_md_unix.c'. But no matter how fancy the name would be, the file would still be in the 'src/solaris/bin' subdirectory:( So I think we'd better leave this for a later change when we completely factor out the Linux/Mac code from the 'solaris/' directory. > Port.java - one suggestion for unregisterImpl is to rename it to > preUnregister and change it to protected so that it's more obvious that it > supposed to be overridden. > > Done. Also changed the comment to JavaDoc style to be more consistent with the other comments in that file. > UnixNativeDispatcher.c - this looks okay (must reduced since the first > round), I just wonder if the changes to *_getpwuid and *_getgrgid are > really needed as this just impacts the error message. Also might be good to > indent the #ifdef to be consistent with the other usages in these functions. > > You're right. This change was done before you fixed "7043788: (fs) PosixFileAttributes.owner() or group() throws NPE if owner/group not in passwd/group database" ( http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After you're fix it was "automatically" adapted. I've removed the special AIX handling as suggested because I think as well that another error message in the exception won't have any impact. > That's mostly it. I notice that only a small number of tests have been > updated. Are there more test updates to come? I'm pretty sure we have a lot > more tests that may require update (searching for SunOS might give some > hints). > > I'm currently working on it and created "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" for it because I didn't wanted to blow up this change unnecessarily. -Alan. > > > > > > > > From rob.mckenna at oracle.com Thu Nov 21 16:08:17 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 21 Nov 2013 16:08:17 +0000 Subject: hg: jdk8/tl/jdk: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug Message-ID: <20131121160829.C978862741@hg.openjdk.java.net> Changeset: 89fccc5a7469 Author: martin Date: 2013-11-21 16:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89fccc5a7469 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Basic.java From peter.levart at gmail.com Thu Nov 21 16:44:48 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 21 Nov 2013 17:44:48 +0100 Subject: Map.Entry.setValue as a default method In-Reply-To: <528E1F14.2020001@univ-mlv.fr> References: <528D3DC0.4000508@univ-mlv.fr> <771E070D-6E5B-42B2-80B0-80CAA2FBFBC8@oracle.com> <528D545A.8020109@univ-mlv.fr> <528E1F14.2020001@univ-mlv.fr> Message-ID: <528E3880.4000904@gmail.com> 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 boolean equals(Object x) { return >> KoolReusablePair.super.defaultEquals(x); } >> @Override //manual opt-in: >> public int hashCode() { return KoolReusablePair.hashCode(this); } >> ... >> } >> >> ? John > > The plumber in me think that a static method unlike a default method > will not pollute the itable. ...and static interface method, unlike default, will not pollute the public API (static interface methods are not inherited). Regards, Peter > > regards, > R?mi From dan.xu at oracle.com Thu Nov 21 17:02:56 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 09:02:56 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E0D7E.6050706@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> Message-ID: <528E3CC0.1070907@oracle.com> On 11/21/2013 05:41 AM, Alan Bateman wrote: > On 21/11/2013 01:09, Dan Xu wrote: >> Hi All, >> >> I have updated my fix based on your suggestions. I have changed to >> create testing files in the working directory, moved those static >> member variables into local method variables, and used >> try-with-resources to read and write the testing files. After the >> change, the file delete is no longer important. So I just do the >> clean-up with deleteOnExit() for simplicity. If the test fails, it is >> better to keep the test file to give more clue. Therefore, I don't >> put the file clean-up into finally block. Thanks! >> >> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ >> >> -Dan > Just one thing about testLargeFile, I see that it additionally creates > a file-mapping and it's not clear that this is needed (I don't see > anything in JDK-4563125 to explain this). I suspect this can be removed. > > Otherwise it looks okay to me. > > -Alan. > > Hi Alan, I think the map is used to enlarge the size of the largeFile to testSize + 10. In initTestFile(), it initiates the file with size 10. My understanding is that it avoids writing large amount of data into the largeFile by using the map. Thanks! -Dan From lowasser at google.com Thu Nov 21 18:17:57 2013 From: lowasser at google.com (Louis Wasserman) Date: Thu, 21 Nov 2013 10:17:57 -0800 Subject: Map.merge Javadoc is confusing Message-ID: The Javadoc for Map.mergestates that its default implementation is equivalent to: V oldValue = map.get(key); V newValue = (oldValue == null) ? value : remappingFunction.apply(oldValue, value); if (newValue == null) map.remove(key); else if (oldValue == null) map.remove(key); else map.put(key, newValue); I'm somewhat confused by the second branch of this if statement, which is reached if newValue is nonnull and oldValue is null. Does this really *remove* the entry for that key? I would have expected there to be only two branches: either remove the entry if newValue is null, or put newValue if it's nonnull. -- Louis Wasserman From david.holmes at oracle.com Thu Nov 21 18:53:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Nov 2013 04:53:01 +1000 Subject: Map.merge Javadoc is confusing In-Reply-To: References: Message-ID: <528E568D.8020909@oracle.com> On 22/11/2013 4:17 AM, Louis Wasserman wrote: > The Javadoc for > Map.mergestates > that its default implementation is equivalent to: > > V oldValue = map.get(key); > V newValue = (oldValue == null) ? value : > remappingFunction.apply(oldValue, value); > if (newValue == null) > map.remove(key); > else if (oldValue == null) > map.remove(key); > else > map.put(key, newValue); > > I'm somewhat confused by the second branch of this if statement, which is > reached if newValue is nonnull and oldValue is null. Does this really > *remove* the entry for that key? I would have expected there to be only > two branches: either remove the entry if newValue is null, or put newValue > if it's nonnull. There seems to be a hole in the spec regarding how a null value parameter is handled. The default implementation treats it as-if the remappingFunction returns null. Not unreasonable but not specified. David From lowasser at google.com Thu Nov 21 19:02:46 2013 From: lowasser at google.com (Louis Wasserman) Date: Thu, 21 Nov 2013 11:02:46 -0800 Subject: Map.merge Javadoc is confusing In-Reply-To: <528E568D.8020909@oracle.com> References: <528E568D.8020909@oracle.com> Message-ID: While I agree that case should be specified, I'm not certain I follow why that's what's going on here. The weird condition is that if oldValue is null, not value; oldValue is the old result of map.get(key). The Javadoc seems not just unspecified, but actively wrong. Here's a worked example: Map map = new HashMap<>(); map.merge("foo", 3, Integer::plus); Integer fooValue = map.get("foo"); Going through the Javadoc-specified default implementation: V oldValue = map.get(key); // oldValue is null V newValue = (oldValue == null) ? value : remappingFunction.apply(oldValue, value); // newValue is set to value, which is 3 if (newValue == null) // newValue is nonnull, branch not taken map.remove(key); else if (oldValue == null) // oldValue is null, branch taken map.remove(key); // removes the entry from the map else // else if was already triggered, branch not taken map.put(key, newValue); In short, according to the Javadoc, fooValue should be null. This seems like it's not intended. On Thu, Nov 21, 2013 at 10:53 AM, David Holmes wrote: > On 22/11/2013 4:17 AM, Louis Wasserman wrote: > >> The Javadoc for >> Map.merge> util/Map.html#merge-K-V-java.util.function.BiFunction->states >> >> that its default implementation is equivalent to: >> >> V oldValue = map.get(key); >> V newValue = (oldValue == null) ? value : >> remappingFunction.apply(oldValue, value); >> if (newValue == null) >> map.remove(key); >> else if (oldValue == null) >> map.remove(key); >> else >> map.put(key, newValue); >> >> I'm somewhat confused by the second branch of this if statement, which is >> reached if newValue is nonnull and oldValue is null. Does this really >> *remove* the entry for that key? I would have expected there to be only >> >> two branches: either remove the entry if newValue is null, or put newValue >> if it's nonnull. >> > > There seems to be a hole in the spec regarding how a null value parameter > is handled. The default implementation treats it as-if the > remappingFunction returns null. Not unreasonable but not specified. > > David > > -- Louis Wasserman From dan.xu at oracle.com Thu Nov 21 19:29:20 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 11:29:20 -0800 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root Message-ID: <528E5F10.8090508@oracle.com> Hi All, Please review the simple fix towards test/java/nio/file/Files/Misc.java. It only fails when it is run by root. As Alan commented in the bug, the root has all permissions, so the test assumptions are wrong. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ -Dan From joel.franck at oracle.com Thu Nov 21 19:50:24 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 21 Nov 2013 20:50:24 +0100 Subject: RFR: JDK-8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute Message-ID: Hi Please review this fix to the type annotation reflection parser. The wrong kind of exception was thrown in the case of malformed Runtime[In]VisibleTypeAnnotations . Also the parser needed to be fixed for sign issues in a handful of places. The test has tree broken classes encoded that tests a few of the error paths in the parser, I have also run the reproducer from JCK attached to the bug report and it passes. bug: https://bugs.openjdk.java.net/browse/JDK-8023278 webrev: http://cr.openjdk.java.net/~jfranck/8023278/webrev.00/ cheers /Joel From Alan.Bateman at oracle.com Thu Nov 21 19:51:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 19:51:28 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E3CC0.1070907@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> <528E3CC0.1070907@oracle.com> Message-ID: <528E6440.4070306@oracle.com> On 21/11/2013 17:02, Dan Xu wrote: > > Hi Alan, > > I think the map is used to enlarge the size of the largeFile to > testSize + 10. In initTestFile(), it initiates the file with size 10. > My understanding is that it avoids writing large amount of data into > the largeFile by using the map. Thanks! > > -Dan Okay, I guess I was really just wondering about the reliability on Windows as sometimes tests that use memory mapped files are troublesome when it comes to clean-up after the test. Also as this test hasn't run on Windows before then I wonder about how long initTestFile will take to create the 4GB file. You've probably measured already but if you need a speed up then you could change initTestFile to use a FIleChannel and create the file with the SPARSE option. Then just position to size-1 and write 1 byte. That should be faster than writing "e" 4 billion times. -Alan. From valerie.peng at oracle.com Thu Nov 21 20:03:27 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 21 Nov 2013 20:03:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131121200356.B232D6276B@hg.openjdk.java.net> Changeset: 93826827e8b4 Author: valeriep Date: 2013-11-19 15:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93826827e8b4 8026943: SQE test jce/Global/Cipher/SameBuffer failed Summary: Always use different input/output buffers when calling FeedbackCipher objects Reviewed-by: mullan ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java + test/com/sun/crypto/provider/Cipher/AES/TestCopySafe.java Changeset: 06d155a7c9b0 Author: valeriep Date: 2013-11-21 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06d155a7c9b0 Merge From Alan.Bateman at oracle.com Thu Nov 21 20:22:44 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 20:22:44 +0000 Subject: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root In-Reply-To: <528E5F10.8090508@oracle.com> References: <528E5F10.8090508@oracle.com> Message-ID: <528E6B94.1030209@oracle.com> On 21/11/2013 19:29, Dan Xu wrote: > Hi All, > > Please review the simple fix towards > test/java/nio/file/Files/Misc.java. It only fails when it is run by > root. As Alan commented in the bug, the root has all permissions, so > the test assumptions are wrong. Thanks! > > Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 > Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ This looks okay although it's possible for users other than root to be a superuser. I think we have at least one other test that checks if /etc/passwd is writable as a crude indication as to whether the test is being run by root or not. -Alan From dan.xu at oracle.com Thu Nov 21 20:42:51 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 21 Nov 2013 12:42:51 -0800 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E6440.4070306@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> <528E3CC0.1070907@oracle.com> <528E6440.4070306@oracle.com> Message-ID: <528E704B.2030705@oracle.com> Hi Alan, When looking at the FileChannel.map() method, it seems that it will not write "e" 4 billion times. Instead, it only extends the file size to testSize+10. It uses ftruncate() in linux and uses SetFilePointer() in Windows, which causes the file offset different on different platforms. But the performance should be good. On windows, this test runs for around 0.14 seconds in jprt machines. Thanks! -Dan On Thu 21 Nov 2013 11:51:28 AM PST, Alan Bateman wrote: > On 21/11/2013 17:02, Dan Xu wrote: >> >> Hi Alan, >> >> I think the map is used to enlarge the size of the largeFile to >> testSize + 10. In initTestFile(), it initiates the file with size 10. >> My understanding is that it avoids writing large amount of data into >> the largeFile by using the map. Thanks! >> >> -Dan > Okay, I guess I was really just wondering about the reliability on > Windows as sometimes tests that use memory mapped files are > troublesome when it comes to clean-up after the test. Also as this > test hasn't run on Windows before then I wonder about how long > initTestFile will take to create the 4GB file. You've probably > measured already but if you need a speed up then you could change > initTestFile to use a FIleChannel and create the file with the SPARSE > option. Then just position to size-1 and write 1 byte. That should be > faster than writing "e" 4 billion times. > > -Alan. > From joe.darcy at oracle.com Thu Nov 21 21:34:19 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 21 Nov 2013 13:34:19 -0800 Subject: RFR: JDK-8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute In-Reply-To: References: Message-ID: <528E7C5B.10502@oracle.com> Hi Joel, Looks fine; thanks, -Joe On 11/21/2013 11:50 AM, Joel Borggr?n-Franck wrote: > Hi > > Please review this fix to the type annotation reflection parser. The wrong kind of exception was thrown in the case of malformed Runtime[In]VisibleTypeAnnotations . > > Also the parser needed to be fixed for sign issues in a handful of places. > > The test has tree broken classes encoded that tests a few of the error paths in the parser, I have also run the reproducer from JCK attached to the bug report and it passes. > > bug: https://bugs.openjdk.java.net/browse/JDK-8023278 > webrev: http://cr.openjdk.java.net/~jfranck/8023278/webrev.00/ > > cheers > /Joel > From Alan.Bateman at oracle.com Thu Nov 21 21:52:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 21:52:43 +0000 Subject: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run In-Reply-To: <528E704B.2030705@oracle.com> References: <528BFAFC.9010804@oracle.com> <528CA627.9000108@oracle.com> <528D5D2E.9080307@oracle.com> <528E0D7E.6050706@oracle.com> <528E3CC0.1070907@oracle.com> <528E6440.4070306@oracle.com> <528E704B.2030705@oracle.com> Message-ID: <528E80AB.6090900@oracle.com> On 21/11/2013 20:42, Dan Xu wrote: > Hi Alan, > > When looking at the FileChannel.map() method, it seems that it will > not write "e" 4 billion times. Instead, it only extends the file size > to testSize+10. It uses ftruncate() in linux and uses SetFilePointer() > in Windows, which causes the file offset different on different > platforms. But the performance should be good. On windows, this test > runs for around 0.14 seconds in jprt machines. Thanks! Okay, what you have is fine and in time we will see whether it reliable. -Alan From dan.xu at oracle.com Thu Nov 21 22:24:03 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 21 Nov 2013 22:24:03 +0000 Subject: hg: jdk8/tl/jdk: 8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run Message-ID: <20131121222415.EA98D62787@hg.openjdk.java.net> Changeset: 81708985c0a2 Author: dxu Date: 2013-11-21 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81708985c0a2 8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run Reviewed-by: alanb, chegar, mchung, lancea ! test/java/nio/channels/FileChannel/Size.java From dan.xu at oracle.com Thu Nov 21 22:17:15 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 21 Nov 2013 22:17:15 +0000 Subject: hg: jdk8/tl/jdk: 7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root Message-ID: <20131121221729.3D0E962785@hg.openjdk.java.net> Changeset: a74d6aa51654 Author: dxu Date: 2013-11-21 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a74d6aa51654 7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root Reviewed-by: alanb ! test/java/nio/file/Files/Misc.java From stuart.marks at oracle.com Fri Nov 22 00:01:51 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 22 Nov 2013 00:01:51 +0000 Subject: hg: jdk8/tl/jdk: 7174936: several String methods claim to always create new String Message-ID: <20131122000217.394126278A@hg.openjdk.java.net> Changeset: 4bc37b6c4133 Author: smarks Date: 2013-11-21 16:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bc37b6c4133 7174936: several String methods claim to always create new String Reviewed-by: dholmes, bchristi, alanb, lancea ! src/share/classes/java/lang/String.java From sundararajan.athijegannathan at oracle.com Fri Nov 22 04:32:44 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 22 Nov 2013 04:32:44 +0000 Subject: hg: jdk8/tl/nashorn: 5 new changesets Message-ID: <20131122043249.EB1926279A@hg.openjdk.java.net> Changeset: fea9f0f9bbde Author: sundar Date: 2013-11-14 15:53 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fea9f0f9bbde 8028161: nashorn: src/jdk/nashorn/api/scripting/ScriptEngineTest.java Reviewed-by: lagergren, hannesw ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a165c0fb5be6 Author: hannesw Date: 2013-11-16 00:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a165c0fb5be6 8028210: Missing conversions on array index expression Reviewed-by: attila, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + test/script/basic/JDK-8028210.js + test/script/basic/JDK-8028210.js.EXPECTED Changeset: bce2bbfb35ae Author: lagergren Date: 2013-11-18 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bce2bbfb35ae 8028434: Line number nodes were off for while nodes and do while nodes - the line number of a loop node should be treated as the location of the test expression Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8028434.js + test/script/basic/JDK-8028434.js.EXPECTED Changeset: b375d261e56c Author: lagergren Date: 2013-11-19 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b375d261e56c 8028573: Line number nodes were off for while nodes and do while nodes - the line number of a loop node should be treated as the location of the test expression Reviewed-by: attila, hannesw ! test/script/basic/JDK-8028434.js Changeset: 73d741231651 Author: sundar Date: 2013-11-22 08:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/73d741231651 Merge From sean.coffey at oracle.com Fri Nov 22 09:58:40 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 22 Nov 2013 09:58:40 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131122095935.EEE41627A8@hg.openjdk.java.net> Changeset: cd56de5896b4 Author: aefimov Date: 2013-11-15 15:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd56de5896b4 8027848: The ZoneInfoFile doesn't honor future GMT offset changes Reviewed-by: sherman, coffeys ! src/share/classes/sun/util/calendar/ZoneInfoFile.java Changeset: ebd47f6ab172 Author: aefimov Date: 2013-11-21 20:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ebd47f6ab172 8027370: Support tzdata2013h Reviewed-by: sherman, coffeys ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/southamerica Changeset: 3b50d682e7c1 Author: coffeys Date: 2013-11-22 09:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b50d682e7c1 Merge From volker.simonis at gmail.com Fri Nov 22 10:45:25 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Nov 2013 11:45:25 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: We've synced our staging repository yesterday with the latest jdk8-b117 and I noticed that change "8025985: com.sun.management.OSMBeanFactory should not be public" moved the file src/solaris/native/com/sun/ management/UnixOperatingSystem_md.c to src/solaris/native/sun/management/OperatingSystemImpl.c. Fortunately, my changes to UnixOperatingSystem_md.c described in the webrev apply cleanly to the new file (I've tested this locally). I'll update the webrev accordingly once I've collected some more feedback. Thank you and best regards, Volker On Wed, Nov 20, 2013 at 7:26 PM, Volker Simonis wrote: > Hi, > > this is the second review round for "8024854: Basic changes and files to > build the class library on AIX". > The previous reviews can be found at the end of this mail in the references > section. > > I've tried to address all the comments and suggestions from the first > round and to further streamline the patch (it perfectly builds on > Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The > biggest change compared to the first review round is the new "aix/" > subdirectory which I've now created under "jdk/src" and which contains > AIX-only code. > > The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > > Below (and in the webrev) you can find some comments which explain the > changes to each file. In order to be able to push this big change, I need > the approval of reviewers from the lib, net, svc, 2d, awt and sec groups. > So please don't hesitate to jump at it - there are enough changes for > everybody:) > > Thank you and best regards, > Volker > > *References:* > > The following reviews have been posted so far (thanks Iris for collecting > them :) > > - Alan Bateman (lib): Initial comments (16 Sep [2]) > - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) > - Michael McMahon (net): Initial comments (20 Sept [4]) > - Steffan Larsen (svc): APPROVED (20 Sept [5]) > - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments > (15 Oct [7]) > - Sean Mullan (sec): Initial comments (26 Sept [8]) > > [2]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html > [3]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html > [4]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html > [5]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html > [6]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html > [7]: > http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html > [8]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html > > > *Detailed change description:* > > The new "jdk/src/aix" subdirectory contains the following new and > AIX-specific files for now: > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileStore.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/classes/sun/nio/fs/AixFileSystemProvider.java > src/aix/classes/sun/nio/fs/AixNativeDispatcher.java > src/aix/classes/sun/tools/attach/AixAttachProvider.java > src/aix/classes/sun/tools/attach/AixVirtualMachine.java > src/aix/native/java/net/aix_close.c > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/sun/nio/fs/AixNativeDispatcher.c > src/aix/native/sun/tools/attach/AixVirtualMachine.c > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > - Added these two files for AIX relevant utility code. > - Currently these files only contain an implementation of dladdr which > is not available on AIX. > - In the first review round the existing dladdr users in the code > either called the version from the HotSpot on AIX ( > src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of > the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). > This is now not necessary any more. > > The new file layout required some small changes to the makefiles to make > them aware of the new directory locations: > > makefiles/CompileDemos.gmk > > - Add an extra argument to SetupJVMTIDemo which can be used to pass > additional source locations. > - Currently this is only used on AIX for the AIX porting utilities > which are required by hprof. > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/ServiceabilityLibraries.gmk > > - On AIX add the sources of the AIX porting utilities to the build. > They are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and > src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not > available on AIX. > > makefiles/lib/NioLibraries.gmk > > - Make the AIX-build aware of the new NIO source locations under > src/aix/native/sun/nio/. > > makefiles/lib/NetworkingLibraries.gmk > > - Make the AIX-build aware of the new aix_close.c source location > under src/aix/native/java/net/. > > src/share/bin/jli_util.h > > - Define JLI_Lseek on AIX. > > src/share/lib/security/java.security-aix > > - Provide default java.security-aix for AIX based on the latest Linux > version as suggested by Sean Mullan. > > src/share/native/common/check_code.c > > - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is > legal, but the code in check_code.c does not handles this properly. So > we wrap the two methods on AIX and return a non-NULL pointer even if we > allocate 0 bytes. > > src/share/native/sun/awt/medialib/mlib_sys.c > > - malloc always returns 8-byte aligned pointers on AIX as well. > > src/share/native/sun/awt/medialib/mlib_types.h > > - Add AIX to the list of known platforms. > > src/share/native/sun/font/layout/KernTable.cpp > > - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too > common and may be defined in other headers as well as on the command line > and xlc bails out on macro redefinitions with a different value. > > src/share/native/sun/security/ec/impl/ecc_impl.h > > - Define required types and macros on AIX. > > src/solaris/back/exec_md.c > > - AIX behaves like Linux in this case so check for it in the Linux > branch. > > src/solaris/bin/java_md_solinux.c, > src/solaris/bin/java_md_solinux.h > > - On AIX LD_LIBRARY_PATH is called LIBPATH > - Always use LD_LIBRARY_PATH macro instead of using the string " > LD_LIBRARY_PATH" directly to cope with different library path names. > - Add jre/lib//jli to the standard library search path on AIX > because the AIX linker doesn't support the -rpath option. > - Replace #ifdef __linux__ by #ifndef __solaris__ because in this > case, AIX behaves like Linux. > - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from > java_md_solinux.h because the macros are redefined in the > corresponding .c files anyway. > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > - Provide basic fontconfig.propertiesfor AIX. > > src/solaris/classes/java/lang/UNIXProcess.java.aix, > src/aix/classes/sun/tools/attach/AixAttachProvider.java, > src/aix/classes/sun/tools/attach/AixVirtualMachine.java, > src/aix/native/sun/tools/attach/AixVirtualMachine.c > > - Provide AIX specific Java versions, mostly based on the > corresponding Linux versions. > > src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java > src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java > > - Detect AIX operating system and return the corresponding channel and > file system providers. > > src/solaris/classes/sun/nio/ch/Port.java > > - Add a callback function unregisterImpl(int fd) for implementations > that need special handling when fd is removed and call it from unregister(int > fd). By default the implementation of unregisterImpl(int fd) is empty > except for the derived AixPollPort class on AIX. > > src/solaris/demo/jvmti/hprof/hprof_md.c > > - Add AIX support. AIX mostly behaves like Linux, with the one > exception that it has no dladdr functionality. > - Use the dladdr implementation from porting_aix.{c,h} on AIX. > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c > > - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory). > > src/solaris/native/common/jdk_util_md.h > > - Add AIX definitions of the ISNANF and ISNAND macros. > > src/solaris/native/java/io/io_util_md.c > > - AIX behaves like Linux in this case so check for it in the Linux > branch. > > src/solaris/native/java/lang/UNIXProcess_md.c > > - AIX behaves mostly like Solraris in this case so adjust the ifdefs > accordingly. > > src/solaris/native/java/lang/childproc.c > > - AIX does not understand '/proc/self' - it requires the real process > ID to query the proc file system for the current process. > > src/solaris/native/java/net/NetworkInterface.c > > - Add AIX support into the Linux branch because AIX mostly behaves > like AIX for IPv4. > - AIX needs a special function to enumerate IPv6 interfaces and to > query the MAC address. > - Moved the declaration of siocgifconfRequest to the beginning a the > function (as recommend by Michael McMahon) to remain C89 compatible. > > src/solaris/native/java/net/PlainSocketImpl.c > > - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the > socket is closed. The default error message is then confusing. > > src/aix/native/java/net/aix_close.c, > src/share/native/java/net/net_util.c > > - As recommended by Michael McMahon and Alan Bateman I've move an > adapted version of linux_close.c to src/aix/native/java/net/aix_close.cbecause we also need the file and socket wrappers on AIX. > - Compared to the Linux version, we've added the initialization of > some previously uninitialized data structures. > - Also, on AIX we don't have __attribute((constructor)) so we need to > initialize manually (from JNI_OnLoad() in > src/share/native/java/net/net_util.c. > > src/solaris/native/java/net/net_util_md.h > > - AIX needs the same workaround for I/O cancellation like Linux and > MacOSX. > > src/solaris/native/java/net/net_util_md.c > > - SO_REUSEADDR is called SO_REUSEPORT on AIX. > - On AIX we have to ignore failures due to ENOBUFS when setting the > SO_SNDBUF/SO_RCVBUF socket options. > > src/solaris/native/java/util/TimeZone_md.c > > - Currently on AIX the only way to get the platform time zone is to > read it from the TZ environment variable. > > src/solaris/native/sun/awt/awt_LoadLibrary.c > > - Use the dladdr from porting_aix.{c,h} on AIX. > > src/solaris/native/sun/awt/fontpath.c > > - Changed some macros from if !defined(__linux__) to if > defined(__solaris__) because that's their real meaning. > - Add AIX specific fontpath settings and library search paths for > libfontconfig.so. > > src/solaris/native/sun/java2d/x11/X11SurfaceData.c > > - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name > clashes (MIN and MAX are much too common and thexy are already defined > in some AIX system headers). > > src/solaris/native/sun/java2d/x11/XRBackendNative.c > > - Handle AIX like Solaris. > > src/solaris/native/sun/nio/ch/Net.c > > - Add AIX-specific includes and constant definitions. > - On AIX "socket extensions for multicast source filters" support > depends on the OS version. Check for this and throw appropriate exceptions > if it is requested but not supported. This is needed to pass > JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast > > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > > - On AIX strerror() is not thread-safe so we have to use strerror_r()instead. > - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to > NULL for the directory stream end. Otherwise, 'errno' will contain the > error code. > - Handle some AIX corner cases for the results of the statvfs64() call. > - On AIX getgrgid_r() returns ESRCH if group does not exist. > > src/solaris/native/sun/security/pkcs11/j2secmod_md.c > > - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX. > > test/java/lang/ProcessBuilder/Basic.java > test/java/lang/ProcessBuilder/DestroyTest.java > > - Port this test to AIX and make it more robust (i.e. recognize the > "C" locale as isEnglish(), ignore VM-warnings in the output, make sure > the "grandchild" processes created by the test don't run too long (60s vs. > 6666s) because in the case of test problems these processes will pollute > the process space, make sure the test fails with an error and doesn't hang > indefinitley in the case of a problem). > > *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this > intended? > > Well, _AIX is defined in some system headers while AIX is defined by the > build system. This is already used inconsistently (i.e. __linux__ vs. > LINUX) and in general I try to be consistent with the style of the file > where I the changes are. That said, I changes most of the occurences of > AIX to _AIX. > > *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are > they supposed to be there? > > We currently don't support OS/400 (later renamed into i5/OS and currently > called IBM i) in our OpenJDK port but we do support it in our internel, SAP > JVM build. We stripped out all the extra OS/400 functionality from the port > but in some places where there is common functionality needd by both, AIX > and OS/400 the OS/400 support may still be visible in the OpenJDK port. I > don't think this is a real problem and it helps us to keep our internel > sources in sync with the OpenJDK port. That said, I think I've removed all > the references to OS/400 now. > > From headius at headius.com Fri Nov 22 11:02:02 2013 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 22 Nov 2013 05:02:02 -0600 Subject: Different error decoding Shift-JIS sequence in JDK8 Message-ID: Apologies if this is not the correct place to post this, bit i18n seemed more focused on languages and localization than the mechanics of transcoding. I have noticed a behavioral difference in JDK8 decoding a two-byte Shift-JIS sequence. Specifically, JDK8 appears to report malformed input for what should be a valid Shift-JIS sequence, where JDK7 reported that the character was unmappable. The code to reproduce is fairly simple: byte[] bytes = {(byte)0xEF, 0x40}; CharsetDecoder decoder = Charset.forName("Shift-JIS").newDecoder(); System.out.println(decoder.decode(ByteBuffer.wrap(bytes), CharBuffer.allocate(2), false)); Note that this is pumping the decoder directly and specifying partial input (false). We use this mechanism in JRuby for transcoding arbitrary byte[] from one encoding to another. The result of running this on JDK7 is "UNMAPPABLE[2]" while the result on JDK8 is "MALFORMED[1]". Information online is spotty as to whether this sequence is valid. It does appear on the table for [JIS X 203](http://x0213.org/codetable/sjis-0213-2004-std.txt) and several articles on Shift-JIS claim that it is at worst undefined and at best valid. So I'm leaning toward this being a bug in JDK8's Shift-JIS decoder. Note that on JDK7 it is "unmappable", which may mean this code represents a character with no equivalent in Unicode. I have uploaded my code to github here: https://github.com/headius/jdk8_utf8_decoding_bug Thoughts? - Charlie From headius at headius.com Fri Nov 22 11:06:19 2013 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 22 Nov 2013 05:06:19 -0600 Subject: ISO-8859-16 charset/decoder/encoder Message-ID: Again, apologies if this is not the right list. OpenJDK does not currently contain support for encoding/decoding ISO-8859-16. A JRuby user recently reported that they needed this encoding. So, I implemented it. Here's a link to the charset/decoder/encoder in JRuby's repository: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/util/encoding/ISO_8859_16.java I tried to follow the general form of the other ISO-8859 charsets, but there's probably more reuse possible (I believe they use sun.nio.cs classes I can't access). Happy to contribute this. Unsure of the process. - Charlie From paul.sandoz at oracle.com Fri Nov 22 11:24:26 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 Nov 2013 12:24:26 +0100 Subject: RFR 8028516 Java doc error in Int/Long/Double/Stream.peek Message-ID: <8EF7AD8E-1773-4F03-989F-857CEEDDCF61@oracle.com> Hi, https://bugs.openjdk.java.net/browse/JDK-8028516 An attendee of the Devoxx lambda hackathon spotted some doc bugs in code samples of the stream peek methods. I updated those samples to be stand alone samples and verified they compile. Paul. diff -r 4bc37b6c4133 src/share/classes/java/util/stream/DoubleStream.java --- a/src/share/classes/java/util/stream/DoubleStream.java Thu Nov 21 16:02:16 2013 -0800 +++ b/src/share/classes/java/util/stream/DoubleStream.java Fri Nov 22 12:23:30 2013 +0100 @@ -207,12 +207,12 @@ * @apiNote This method exists mainly to support debugging, where you want * to see the elements as they flow past a certain point in a pipeline: * 

{@code
-     *     list.stream()
-     *         .filter(filteringFunction)
-     *         .peek(e -> System.out.println("Filtered value: " + e));
-     *         .map(mappingFunction)
-     *         .peek(e -> System.out.println("Mapped value: " + e));
-     *         .collect(Collectors.toDoubleSummaryStastistics());
+     *     DoubleStream.of(1, 2, 3, 4)
+     *         .filter(e -> e > 2)
+     *         .peek(e -> System.out.println("Filtered value: " + e))
+     *         .map(e -> e * e)
+     *         .peek(e -> System.out.println("Mapped value: " + e))
+     *         .sum();
      * }
* * @param action a diff -r 4bc37b6c4133 src/share/classes/java/util/stream/IntStream.java --- a/src/share/classes/java/util/stream/IntStream.java Thu Nov 21 16:02:16 2013 -0800 +++ b/src/share/classes/java/util/stream/IntStream.java Fri Nov 22 12:23:30 2013 +0100 @@ -200,12 +200,12 @@ * @apiNote This method exists mainly to support debugging, where you want * to see the elements as they flow past a certain point in a pipeline: * 
{@code
-     *     list.stream()
-     *         .filter(filteringFunction)
-     *         .peek(e -> System.out.println("Filtered value: " + e));
-     *         .map(mappingFunction)
-     *         .peek(e -> System.out.println("Mapped value: " + e));
-     *         .collect(Collectors.toIntSummaryStastistics());
+     *     IntStream.of(1, 2, 3, 4)
+     *         .filter(e -> e > 2)
+     *         .peek(e -> System.out.println("Filtered value: " + e))
+     *         .map(e -> e * e)
+     *         .peek(e -> System.out.println("Mapped value: " + e))
+     *         .sum();
      * }
* * @param action a diff -r 4bc37b6c4133 src/share/classes/java/util/stream/LongStream.java --- a/src/share/classes/java/util/stream/LongStream.java Thu Nov 21 16:02:16 2013 -0800 +++ b/src/share/classes/java/util/stream/LongStream.java Fri Nov 22 12:23:30 2013 +0100 @@ -205,12 +205,12 @@ * @apiNote This method exists mainly to support debugging, where you want * to see the elements as they flow past a certain point in a pipeline: * 
{@code
-     *     list.stream()
-     *         .filter(filteringFunction)
-     *         .peek(e -> System.out.println("Filtered value: " + e));
-     *         .map(mappingFunction)
-     *         .peek(e -> System.out.println("Mapped value: " + e));
-     *         .collect(Collectors.toLongSummaryStastistics());
+     *     LongStream.of(1, 2, 3, 4)
+     *         .filter(e -> e > 2)
+     *         .peek(e -> System.out.println("Filtered value: " + e))
+     *         .map(e -> e * e)
+     *         .peek(e -> System.out.println("Mapped value: " + e))
+     *         .sum();
      * }
* * @param action a diff -r 4bc37b6c4133 src/share/classes/java/util/stream/Stream.java --- a/src/share/classes/java/util/stream/Stream.java Thu Nov 21 16:02:16 2013 -0800 +++ b/src/share/classes/java/util/stream/Stream.java Fri Nov 22 12:23:30 2013 +0100 @@ -403,12 +403,12 @@ * @apiNote This method exists mainly to support debugging, where you want * to see the elements as they flow past a certain point in a pipeline: * 
{@code
-     *     list.stream()
-     *         .filter(filteringFunction)
-     *         .peek(e -> System.out.println("Filtered value: " + e));
-     *         .map(mappingFunction)
-     *         .peek(e -> System.out.println("Mapped value: " + e));
-     *         .collect(Collectors.intoList());
+     *     Stream.of("one", "two", "three", "four")
+     *         .filter(e -> e.length() > 3)
+     *         .peek(e -> System.out.println("Filtered value: " + e))
+     *         .map(String::toUpperCase)
+     *         .peek(e -> System.out.println("Mapped value: " + e))
+     *         .collect(Collectors.toList());
      * }
* * @param action a From joel.franck at oracle.com Fri Nov 22 10:38:19 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Fri, 22 Nov 2013 10:38:19 +0000 Subject: hg: jdk8/tl/jdk: 8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute Message-ID: <20131122103836.EEC29627AA@hg.openjdk.java.net> Changeset: 0775f4f6532a Author: jfranck Date: 2013-11-22 11:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0775f4f6532a 8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute Reviewed-by: darcy ! src/share/classes/sun/reflect/annotation/TypeAnnotation.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/annotation/typeAnnotations/BadCPIndex.java From chris.hegarty at oracle.com Fri Nov 22 11:51:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Nov 2013 11:51:16 +0000 Subject: RFR 8028516 Java doc error in Int/Long/Double/Stream.peek In-Reply-To: <8EF7AD8E-1773-4F03-989F-857CEEDDCF61@oracle.com> References: <8EF7AD8E-1773-4F03-989F-857CEEDDCF61@oracle.com> Message-ID: <528F4534.50202@oracle.com> Look good to me Paul. -Chris On 22/11/13 11:24, Paul Sandoz wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-8028516 > > An attendee of the Devoxx lambda hackathon spotted some doc bugs in code samples of the stream peek methods. > > I updated those samples to be stand alone samples and verified they compile. > > Paul. > > diff -r 4bc37b6c4133 src/share/classes/java/util/stream/DoubleStream.java > --- a/src/share/classes/java/util/stream/DoubleStream.java Thu Nov 21 16:02:16 2013 -0800 > +++ b/src/share/classes/java/util/stream/DoubleStream.java Fri Nov 22 12:23:30 2013 +0100 > @@ -207,12 +207,12 @@ > * @apiNote This method exists mainly to support debugging, where you want > * to see the elements as they flow past a certain point in a pipeline: > * 
{@code
> -     *     list.stream()
> -     *         .filter(filteringFunction)
> -     *         .peek(e -> System.out.println("Filtered value: " + e));
> -     *         .map(mappingFunction)
> -     *         .peek(e -> System.out.println("Mapped value: " + e));
> -     *         .collect(Collectors.toDoubleSummaryStastistics());
> +     *     DoubleStream.of(1, 2, 3, 4)
> +     *         .filter(e -> e > 2)
> +     *         .peek(e -> System.out.println("Filtered value: " + e))
> +     *         .map(e -> e * e)
> +     *         .peek(e -> System.out.println("Mapped value: " + e))
> +     *         .sum();
>        * }
> * > * @param action a > diff -r 4bc37b6c4133 src/share/classes/java/util/stream/IntStream.java > --- a/src/share/classes/java/util/stream/IntStream.java Thu Nov 21 16:02:16 2013 -0800 > +++ b/src/share/classes/java/util/stream/IntStream.java Fri Nov 22 12:23:30 2013 +0100 > @@ -200,12 +200,12 @@ > * @apiNote This method exists mainly to support debugging, where you want > * to see the elements as they flow past a certain point in a pipeline: > * 
{@code
> -     *     list.stream()
> -     *         .filter(filteringFunction)
> -     *         .peek(e -> System.out.println("Filtered value: " + e));
> -     *         .map(mappingFunction)
> -     *         .peek(e -> System.out.println("Mapped value: " + e));
> -     *         .collect(Collectors.toIntSummaryStastistics());
> +     *     IntStream.of(1, 2, 3, 4)
> +     *         .filter(e -> e > 2)
> +     *         .peek(e -> System.out.println("Filtered value: " + e))
> +     *         .map(e -> e * e)
> +     *         .peek(e -> System.out.println("Mapped value: " + e))
> +     *         .sum();
>        * }
> * > * @param action a > diff -r 4bc37b6c4133 src/share/classes/java/util/stream/LongStream.java > --- a/src/share/classes/java/util/stream/LongStream.java Thu Nov 21 16:02:16 2013 -0800 > +++ b/src/share/classes/java/util/stream/LongStream.java Fri Nov 22 12:23:30 2013 +0100 > @@ -205,12 +205,12 @@ > * @apiNote This method exists mainly to support debugging, where you want > * to see the elements as they flow past a certain point in a pipeline: > * 
{@code
> -     *     list.stream()
> -     *         .filter(filteringFunction)
> -     *         .peek(e -> System.out.println("Filtered value: " + e));
> -     *         .map(mappingFunction)
> -     *         .peek(e -> System.out.println("Mapped value: " + e));
> -     *         .collect(Collectors.toLongSummaryStastistics());
> +     *     LongStream.of(1, 2, 3, 4)
> +     *         .filter(e -> e > 2)
> +     *         .peek(e -> System.out.println("Filtered value: " + e))
> +     *         .map(e -> e * e)
> +     *         .peek(e -> System.out.println("Mapped value: " + e))
> +     *         .sum();
>        * }
> * > * @param action a > diff -r 4bc37b6c4133 src/share/classes/java/util/stream/Stream.java > --- a/src/share/classes/java/util/stream/Stream.java Thu Nov 21 16:02:16 2013 -0800 > +++ b/src/share/classes/java/util/stream/Stream.java Fri Nov 22 12:23:30 2013 +0100 > @@ -403,12 +403,12 @@ > * @apiNote This method exists mainly to support debugging, where you want > * to see the elements as they flow past a certain point in a pipeline: > * 
{@code
> -     *     list.stream()
> -     *         .filter(filteringFunction)
> -     *         .peek(e -> System.out.println("Filtered value: " + e));
> -     *         .map(mappingFunction)
> -     *         .peek(e -> System.out.println("Mapped value: " + e));
> -     *         .collect(Collectors.intoList());
> +     *     Stream.of("one", "two", "three", "four")
> +     *         .filter(e -> e.length() > 3)
> +     *         .peek(e -> System.out.println("Filtered value: " + e))
> +     *         .map(String::toUpperCase)
> +     *         .peek(e -> System.out.println("Mapped value: " + e))
> +     *         .collect(Collectors.toList());
>        * }
> * > * @param action a > From Alan.Bateman at oracle.com Fri Nov 22 13:20:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Nov 2013 13:20:43 +0000 Subject: Different error decoding Shift-JIS sequence in JDK8 In-Reply-To: References: Message-ID: <528F5A2B.2000402@oracle.com> On 22/11/2013 11:02, Charles Oliver Nutter wrote: > Apologies if this is not the correct place to post this, bit i18n > seemed more focused on languages and localization than the mechanics > of transcoding. > > I have noticed a behavioral difference in JDK8 decoding a two-byte > Shift-JIS sequence. Specifically, JDK8 appears to report malformed > input for what should be a valid Shift-JIS sequence, where JDK7 > reported that the character was unmappable. I assume this is related to JDK-8008386 [1] and I'm sure Sherman or Sean will jump in to explain this (which seems to be related to a long standing regression). -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8008386 From Alan.Bateman at oracle.com Fri Nov 22 13:24:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Nov 2013 13:24:56 +0000 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: <528DF61B.6060403@oracle.com> Message-ID: <528F5B28.7000404@oracle.com> On 21/11/2013 15:54, Volker Simonis wrote: > : > But actually I've just realized that it is not need at all, because > 'aix_close.c' isn't in the PATH for any other OS than AIX (that could > be probably called a feature of the new file layout:) So I'll simply > change it to: > 48 ifeq ($(OPENJDK_TARGET_OS), aix) > 49 LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ > 50 endif This make sense. > > Yes, exactly. I didn't wanted to change too much code. But as the > C-Standard states > (http://pubs.opengroup.org/onlinepubs/000095399/functions/malloc.html) > "...If size is 0, either a null pointer or a unique pointer that can > be successfully passed to free() shall be returned..." it is perfectly > legal that malloc/calloc return a NULL pointer if called with a zero > argument. This case is currently not handled (i.e. it's handled as an > 'out of memory' error) in check_code.c and I agree that this should be > fixed via a separate bug. Yes, let's use a separate bug for this. > In net_util.c then it's a bit ugly to be calling aix_close_init. > Michael/Chris - what you would think about the JNI_OnLoad calling > into a platform specific function to do platform specific > initialization? > > > What about renaming 'initLocalAddrTable()' into something like > 'platformInit()' and moving the call to 'aix_close_init' to a > AIX-specific version of 'platformInit()' in net_util_md.c? I don't have a strong opinion on the name of the function, platformInit is fine for now. > : > > > You're right - we could rename it to something like 'java_md_unix.c'. > But no matter how fancy the name would be, the file would still be in > the 'src/solaris/bin' subdirectory:( So I think we'd better leave this > for a later change when we completely factor out the Linux/Mac code > from the 'solaris/' directory. I think JDK 9 is a good time to finally tackle this issue (as you probably know, this is something that I've brought up on porters-dev or build-dev a few times). > Port.java - one suggestion for unregisterImpl is to rename it to > preUnregister and change it to protected so that it's more obvious > that it supposed to be overridden. > > > Done. Also changed the comment to JavaDoc style to be more consistent > with the other comments in that file. Thanks. > UnixNativeDispatcher.c - this looks okay (must reduced since the > first round), I just wonder if the changes to *_getpwuid and > *_getgrgid are really needed as this just impacts the error > message. Also might be good to indent the #ifdef to be consistent > with the other usages in these functions. > > > You're right. This change was done before you fixed "7043788: (fs) > PosixFileAttributes.owner() or group() throws NPE if owner/group not > in passwd/group database" > (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After > you're fix it was "automatically" adapted. I've removed the special > AIX handling as suggested because I think as well that another error > message in the exception won't have any impact. Thanks. > : > > > I'm currently working on it and created "8028537: PPC64: Updated > jdk/test scripts to understand the AIX os and environment" for it > because I didn't wanted to blow up this change unnecessarily. Okay. So overall I think this patch is in good shape (I have not reviewed the AWT/2D/client changes in any detail) and I don't see any blocking issues to this going in. -Alan From joel.franck at oracle.com Fri Nov 22 14:35:24 2013 From: joel.franck at oracle.com (Joel Borggr?n-Franck) Date: Fri, 22 Nov 2013 15:35:24 +0100 Subject: RFR: JDK-8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute In-Reply-To: <528E7C5B.10502@oracle.com> References: <528E7C5B.10502@oracle.com> Message-ID: <20131122143524.GA10967@oracle.com> Thanks for the review Joe cheers /Joel On 2013-11-21, Joe Darcy wrote: > Hi Joel, > > Looks fine; thanks, > > -Joe > > On 11/21/2013 11:50 AM, Joel Borggr?n-Franck wrote: > >Hi > > > >Please review this fix to the type annotation reflection parser. The wrong kind of exception was thrown in the case of malformed Runtime[In]VisibleTypeAnnotations . > > > >Also the parser needed to be fixed for sign issues in a handful of places. > > > >The test has tree broken classes encoded that tests a few of the error paths in the parser, I have also run the reproducer from JCK attached to the bug report and it passes. > > > >bug: https://bugs.openjdk.java.net/browse/JDK-8023278 > >webrev: http://cr.openjdk.java.net/~jfranck/8023278/webrev.00/ > > > >cheers > >/Joel > > > From martinrb at google.com Fri Nov 22 15:52:29 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 22 Nov 2013 07:52:29 -0800 Subject: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path' In-Reply-To: <1385134345.4427.46.camel@dpointo8-ThinkPad-T400> References: <1385134345.4427.46.camel@dpointo8-ThinkPad-T400> Message-ID: On Fri, Nov 22, 2013 at 7:32 AM, Dave Pointon wrote: > > Much as though I like and indeed applaud, this change, on a more general > note, it surprises me that more use isn't made of the power of perl since > it [perl] is a fundamental part of autotools and thus has to be present > on the system when configure is run. > autotools do not need to be present on the system when configure is run; only sh. From volker.simonis at gmail.com Fri Nov 22 16:37:55 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Nov 2013 17:37:55 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <528F5B28.7000404@oracle.com> References: <528DF61B.6060403@oracle.com> <528F5B28.7000404@oracle.com> Message-ID: Hi Alan, so I'll rename 'initLocalAddrTable()' into 'platformInit()' and move the call to 'aix_close_init' to a AIX-specific version of 'platformInit()' in net_util_md.c as discussed. I'll post a final webrev once I got the comments from the AWT/2D guys. As far as I understood, you've now reviewed the 'core-lib'/'net' parts right? That would mean that I'll still need a review from the AWT/2D and the Security group - any volunteers:). Once again thanks a lot for your help, Volker On Fri, Nov 22, 2013 at 2:24 PM, Alan Bateman wrote: > On 21/11/2013 15:54, Volker Simonis wrote: > > : > But actually I've just realized that it is not need at all, because > 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be > probably called a feature of the new file layout:) So I'll simply change it > to: > > 48 ifeq ($(OPENJDK_TARGET_OS), aix) > 49 LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ > 50 endif > > This make sense. > > > > > Yes, exactly. I didn't wanted to change too much code. But as the C-Standard > states > (http://pubs.opengroup.org/onlinepubs/000095399/functions/malloc.html) > "...If size is 0, either a null pointer or a unique pointer that can be > successfully passed to free() shall be returned..." it is perfectly legal > that malloc/calloc return a NULL pointer if called with a zero argument. > This case is currently not handled (i.e. it's handled as an 'out of memory' > error) in check_code.c and I agree that this should be fixed via a separate > bug. > > Yes, let's use a separate bug for this. > > > > > >> >> In net_util.c then it's a bit ugly to be calling aix_close_init. >> Michael/Chris - what you would think about the JNI_OnLoad calling into a >> platform specific function to do platform specific initialization? >> > > What about renaming 'initLocalAddrTable()' into something like > 'platformInit()' and moving the call to 'aix_close_init' to a AIX-specific > version of 'platformInit()' in net_util_md.c? > > I don't have a strong opinion on the name of the function, platformInit is > fine for now. > > > > : > > > You're right - we could rename it to something like 'java_md_unix.c'. But no > matter how fancy the name would be, the file would still be in the > 'src/solaris/bin' subdirectory:( So I think we'd better leave this for a > later change when we completely factor out the Linux/Mac code from the > 'solaris/' directory. > > I think JDK 9 is a good time to finally tackle this issue (as you probably > know, this is something that I've brought up on porters-dev or build-dev a > few times). > > > > >> >> Port.java - one suggestion for unregisterImpl is to rename it to >> preUnregister and change it to protected so that it's more obvious that it >> supposed to be overridden. >> > > Done. Also changed the comment to JavaDoc style to be more consistent with > the other comments in that file. > > Thanks. > > > >> >> UnixNativeDispatcher.c - this looks okay (must reduced since the first >> round), I just wonder if the changes to *_getpwuid and *_getgrgid are really >> needed as this just impacts the error message. Also might be good to indent >> the #ifdef to be consistent with the other usages in these functions. >> > > You're right. This change was done before you fixed "7043788: (fs) > PosixFileAttributes.owner() or group() throws NPE if owner/group not in > passwd/group database" > (http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After you're > fix it was "automatically" adapted. I've removed the special AIX handling > as suggested because I think as well that another error message in the > exception won't have any impact. > > Thanks. > > > > : > > > I'm currently working on it and created "8028537: PPC64: Updated jdk/test > scripts to understand the AIX os and environment" for it because I didn't > wanted to blow up this change unnecessarily. > > Okay. > > So overall I think this patch is in good shape (I have not reviewed the > AWT/2D/client changes in any detail) and I don't see any blocking issues to > this going in. > > -Alan > > > From huizhe.wang at oracle.com Fri Nov 22 17:37:15 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 22 Nov 2013 09:37:15 -0800 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <528DE500.2010808@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> <528D9809.6050208@oracle.com> <528DD386.4020902@oracle.com> <528DE500.2010808@oracle.com> Message-ID: <528F964B.6020602@oracle.com> The reason it's three slashes is that empty string is legal in place of localhost, file://host/path therefore becomes file:///path. And the reason the test was failing was that JAXP unit tests use: getClass().getResource("filename").getPath() or getFile() that returns it in a format, on Windows: /C:/path, which was why two slashes were added when the test was converted to Jtreg. But then the filepath part of code was changed too, causing a mismatch. Joe On 11/21/2013 2:48 AM, Patrick Zhang wrote: > Hi Alan, > > I have renamed "jdk8004476" to "8004476". And as Daniel's suggestion, > add some comments to XSLTExFuncTest.java. > > I have updated the webrev for review. > http://cr.openjdk.java.net/~pzhang/8027973/webrev/ > > Regards > Patrick > > On 11/21/13 5:33 PM, Alan Bateman wrote: >> On 21/11/2013 05:20, huizhe wang wrote: >>> Thanks for working on the issue. The fix looks good. >> Looks good to me too (very subtle). >> >> (A side point but should "jdk" be dropped from the directory name so >> that it is a bit more consistent with the tests in the test/javax/xml >> tree). >> >> -Alan From david.r.chase at oracle.com Fri Nov 22 19:07:56 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 22 Nov 2013 14:07:56 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method Message-ID: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Updated request. This is for a bug that it "deferred" by compilers, but runtime really wants it fixed because they are working in the same area and don't like it at all. In particular, they want it committed to hotspot-rt ASAP (don't want to wait for the multiweek turnaround) and thus the diffs and testing are against hotspot-rt. There are jdk and hotspot webrevs; the hotspot webrev is designed to allow it to run (with old behavior) in the absence of the jdk change. Bug: https://bugs.openjdk.java.net/browse/JDK-8016839 Related test bug: https://bugs.openjdk.java.net/browse/JDK-8027733 (confidential, sorry) Webrev(s): http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ Testing: ute vm.quick.testlist A/B, no (new) failures jtreg compiler runtime sanity, no (new) failures defmeth, no new failures, fewer old failures New test, specifically tested on Sparc, Intel, embedded -Xint, -Xcomp, plain, and with jdb on embedded, and Netbeans on x86. (this was specifically to address the main uncertainty, which was calling a zero-arg exception-throwing method instead of the expected perhaps-multi-arg inaccessible method; it is possible to devise calling conventions that will make that not work, but we appear not to have done this. The test includes 0- and 11-arg instances of the not-legally-accessible methods). Problem: Various patterns of inheritance and faulty overriding are supposed to throw IllegalAccessError (IAE). At the time the bug was filed, they instead threw NullPointerException (NPE) but after a related bug was fixed the wrong exception changed to AbstractMethodError (AME). The root cause of the error is that (1) by convention, if an itable entry is null, AME is thrown, and (2) in the case of inaccessible methods overriding other methods that implement interface methods, a null was entered into the itable (leading to throws of AME on code paths that use the itable). This is a long-standing problem dating back to at least JDK 6, but made much easier to observe by the introduction of method handles. Before methodhandles this bug was more difficult to observe because resolution of invokeinterface would aggressively evaluate errors and leave the invoke unresolved if there was an error; thus repeated testing with error receivers would always throw the proper error. If, however, a good receiver is used for the invokeinterface, then resolution succeeds, and subsequent invocations with bad receivers throws the wrong error (AME instead of NPE) because the resolved code goes directly to the itable and sees the null method. With Methodhandles, resolution and invocation are separate, and it always throws the wrong error. Fix: I considered (and discussed with John Rose and Coleen Phillimore and Karen Kinnear) use of a "second null value", where instead of using 0x0 for the missing method, I would use 0x1, and then special case the null checks (in triplicate, across all platforms) to instead unsigned compare against a small integer and also special-case the trap handler for this value. This seemed like a big change, potentially confusing to C programmers, hacky, and somewhat hateful. I next considered creating a "bridge to nowhere" stub that would always throw IAE, and fill that Method * in instead of null. Unfortunately, the need for this stub is not discovered until after constant pool rewriting has occurred, and adding new methods and CPC entries after the rewriting looked very hairy. The last choice was to define a helper method in sun.misc.Unsafe that would always throw IllegalAccessError when called, and use that Method * in the should-throw-IAE case. The risk here is that the helper method is zero-arg, where the method about to be called (and whose parameters had been pushed on the stack) could have a different set of arguments, and perhaps there is some platform where this does not work cleanly. However, the existing code that checks for null and throws AME seems to not be special-cased for number of args (that is, it branches to a generic exception thrower with no additional cleanup). In addition, I enhanced the test to try faulty invocations with both zero and 11 args, and to run under jtreg in several modes, and I added iteration to help force code to the compiled case as well, and it has performed properly on Sparc, Intel, and embedded. From karen.kinnear at oracle.com Fri Nov 22 19:56:57 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 22 Nov 2013 14:56:57 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: David, Thank you so much for finding a way to do this. We do think this is important to get in for 8. And thank you for a way to check the hotspot changes in without waiting for the jdk changes. Code looks good. Couple of minor comments: 1. universe.cpp - when the hotspot change gets in and the jdk change isn't in yet, are we going to see the tty->print_cr message? 2. style: Method* rather than Method space * 3. Head's up that ASM is being updated for default method support - visitMethoInsn will take an additional argument at the end for "isinterface" to determine if it needs a methodref or an interfacemethodref in the constant pool. I think that is in b117 (?) so we don't have it yet - so this will need modifying later - don't let that stop you from pushing the fix. See Lois's test webrev http://javaweb.us.oracle.com/~lfoltan/webrev/defmeth_asm_interfacemethodef_2/src/vm/runtime/defmeth/shared/ClassFileGenerator.java.sdiff.html thanks, Karen On Nov 22, 2013, at 2:07 PM, David Chase wrote: > Updated request. > > This is for a bug that it "deferred" by compilers, > but runtime really wants it fixed because they > are working in the same area and don't like it at all. > In particular, they want it committed to hotspot-rt ASAP > (don't want to wait for the multiweek turnaround) > and thus the diffs and testing are against hotspot-rt. > > There are jdk and hotspot webrevs; the hotspot webrev > is designed to allow it to run (with old behavior) in the > absence of the jdk change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016839 > Related test bug: https://bugs.openjdk.java.net/browse/JDK-8027733 (confidential, sorry) > > Webrev(s): > http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ > http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ > > Testing: > ute vm.quick.testlist A/B, no (new) failures > jtreg compiler runtime sanity, no (new) failures > defmeth, no new failures, fewer old failures > > New test, specifically tested on Sparc, Intel, embedded > -Xint, -Xcomp, plain, and with jdb on embedded, and > Netbeans on x86. (this was specifically to address the main > uncertainty, which was calling a zero-arg exception-throwing > method instead of the expected perhaps-multi-arg inaccessible > method; it is possible to devise calling conventions that will > make that not work, but we appear not to have done this. The test > includes 0- and 11-arg instances of the not-legally-accessible > methods). > > Problem: > Various patterns of inheritance and faulty overriding are supposed to > throw IllegalAccessError (IAE). At the time the bug was filed, they > instead threw NullPointerException (NPE) but after a related bug was > fixed the wrong exception changed to AbstractMethodError (AME). > > The root cause of the error is that (1) by convention, if an itable > entry is null, AME is thrown, and (2) in the case of inaccessible > methods overriding other methods that implement interface methods, a > null was entered into the itable (leading to throws of AME on code paths > that use the itable). > > This is a long-standing problem dating back to at least JDK 6, but made > much easier to observe by the introduction of method handles. Before > methodhandles this bug was more difficult to observe because resolution > of invokeinterface would aggressively evaluate errors and leave the > invoke unresolved if there was an error; thus repeated testing with > error receivers would always throw the proper error. If, however, a > good receiver is used for the invokeinterface, then resolution succeeds, > and subsequent invocations with bad receivers throws the wrong error > (AME instead of NPE) because the resolved code goes directly to the > itable and sees the null method. > > With Methodhandles, resolution and invocation are separate, and it > always throws the wrong error. > > Fix: > > I considered (and discussed with John Rose and Coleen Phillimore and > Karen Kinnear) use of a "second null value", where instead of using 0x0 > for the missing method, I would use 0x1, and then special case the null > checks (in triplicate, across all platforms) to instead unsigned compare > against a small integer and also special-case the trap handler for this > value. > > This seemed like a big change, potentially confusing to C programmers, > hacky, and somewhat hateful. > > I next considered creating a "bridge to nowhere" stub that would always > throw IAE, and fill that Method * in instead of null. Unfortunately, > the need for this stub is not discovered until after constant pool > rewriting has occurred, and adding new methods and CPC entries after > the rewriting looked very hairy. > > The last choice was to define a helper method in sun.misc.Unsafe that > would always throw IllegalAccessError when called, and use that Method * > in the should-throw-IAE case. The risk here is that the helper method > is zero-arg, where the method about to be called (and whose parameters > had been pushed on the stack) could have a different set of arguments, > and perhaps there is some platform where this does not work cleanly. > However, the existing code that checks for null and throws AME seems to > not be special-cased for number of args (that is, it branches to a > generic exception thrower with no additional cleanup). In addition, I > enhanced the test to try faulty invocations with both zero and 11 args, > and to run under jtreg in several modes, and I added iteration to help > force code to the compiled case as well, and it has performed properly > on Sparc, Intel, and embedded. > From david.r.chase at oracle.com Fri Nov 22 20:49:44 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 22 Nov 2013 15:49:44 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: On 2013-11-22, at 2:56 PM, Karen Kinnear wrote: > David, > > Thank you so much for finding a way to do this. We do think this is important to get in for 8. > And thank you for a way to check the hotspot changes in without waiting for the jdk changes. > > Code looks good. > > Couple of minor comments: > 1. universe.cpp - when the hotspot change gets in and the jdk change isn't in yet, are > we going to see the tty->print_cr message? No. if (m != NULL && !m->is_static()) { It only occurs if m is incorrectly defined (defined, so not null, but not static). > 2. style: Method* rather than Method space * Will fix. > 3. Head's up that ASM is being updated for default method support > - visitMethoInsn will take an additional argument at the end for "isinterface" to determine > if it needs a methodref or an interfacemethodref in the constant pool. I think that is in b117 (?) > so we don't have it yet - so this will need modifying later - don't let that stop you from pushing the > fix. > > See Lois's test webrev > http://javaweb.us.oracle.com/~lfoltan/webrev/defmeth_asm_interfacemethodef_2/src/vm/runtime/defmeth/shared/ClassFileGenerator.java.sdiff.html From brian.burkhalter at oracle.com Fri Nov 22 21:47:48 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Nov 2013 13:47:48 -0800 Subject: BigInteger Burnikel-Ziegler division algorithm crossover heuristic Message-ID: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> Hello, We've been doing fairly extensive micro-benchmark testing of the effect of adjusting the various algorithm crossover thresholds in BigInteger (cf. https://bugs.openjdk.java.net/browse/JDK-8022181). There'll be another post on that particular topic in the near future. This testing did however expose another topic for which an issue is not yet (but likely will be) on file, i.e., the heuristic for determining when to use Burnikel-Ziegler divide and conquer division instead of "standard" division. At present the test used is if divisor_int_length < BZ_THRESHOLD or dividend_int_length < BZ_THRESHOLD then use standard division else use B-Z division (where BZ_THRESHOLD is currently 50). Let {N,D} represent a dividend-divisor pair with the int-length of the former being N and that of the latter being D. The following cases were among those initially tested: {T,2T}, {T,T+2}, {T,T}, {T+2,T}, and {2T,T} where T is the BZ threshold. In all but the last case, where the dividend is twice the length of the divisor, a (sometimes serious) performance regression was observed. The implementation was reviewed along with the original paper [1]. The implementation is accurate with respect to the paper as had already been verified some months ago [2]. It was observed however that something interesting happens for the case where the int-length of the dividend A is equal to that of the divisor B. For this situation, the algorithm parameter t (step 5 in algorithm 3 in the paper) becomes 2. This causes A to be virtually padded out to a 2T-length value [0,A]. The net result is that the BZ algorithm ends up being applied in effect to a pair {2T,T} which is significantly slower than using the standard algorithm on the pair {T,T}. This appears to be primarily due to the algorithm overhead rather than a length dependent problem. For the {T,T} case, the following recursive call sequence of significant operations ensues: divide divideBZ divide2n1n divide3n2n divide2n1n divideKnuth multiply subtract divide3n2n divide2n1n divideKnuth multiply subtract add Despite the fact that some of the method calls reduce to simple operations like dividing zero by non-zero, dividing something by itself, or multiplying something by zero or one, the algorithm overhead causes the performance to be worse than had this sequence been used: divide divideKnuth Through micro-benchmark testing it was discovered that, given the original BZ_THRESHOLD criterion is met, for some value C the BZ algorithm will start to outperform the standard algorithm for the case {T+C,T}, i.e., the dividend is C ints longer than the divisor. Testing supports the value of the offset C being independent of the value of the BZ threshold. This suggests that the following heuristic would be more appropriate for this algorithm: if divisor_int_length < BZ_THRESHOLD or dividend_int_length - divisor_int_length < BZ_OFFSET_THRESHOLD then use standard division else use B-Z division Any comments on this alternative heuristic would be appreciated as I would not be in the least bit surprised to have missed some fine point altogether. Thanks, Brian [1] Christoph Burnikel and Joachim Ziegler, "Fast Recursive Division", Max-Planck-Institut fuer Informatik Research Report MPI-I-98-1-022, http://www.mpi-sb.mpg.de/~ziegler/TechRep.ps.gz. [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018922.html From david.holmes at oracle.com Fri Nov 22 02:33:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Nov 2013 12:33:47 +1000 Subject: Map.merge Javadoc is confusing In-Reply-To: References: <528E568D.8020909@oracle.com> Message-ID: <528EC28B.6040002@oracle.com> On 22/11/2013 5:02 AM, Louis Wasserman wrote: > While I agree that case should be specified, I'm not certain I follow why > that's what's going on here. > > The weird condition is that if oldValue is null, not value; oldValue is the > old result of map.get(key). The Javadoc seems not just unspecified, but > actively wrong. Here's a worked example: > > Map map = new HashMap<>(); > map.merge("foo", 3, Integer::plus); > Integer fooValue = map.get("foo"); > > Going through the Javadoc-specified default implementation: > > V oldValue = map.get(key); // oldValue is null > V newValue = (oldValue == null) ? value : > remappingFunction.apply(oldValue, value); > // newValue is set to value, which is 3 > if (newValue == null) // newValue is nonnull, branch not taken > map.remove(key); > else if (oldValue == null) // oldValue is null, branch taken > map.remove(key); // removes the entry from the map > else // else if was already triggered, branch not taken > map.put(key, newValue); > > In short, according to the Javadoc, fooValue should be null. This seems > like it's not intended. Ah I see your point. The actual implementation doesn't do that of course. So a couple of issues with this particular method. David > > On Thu, Nov 21, 2013 at 10:53 AM, David Holmes wrote: > >> On 22/11/2013 4:17 AM, Louis Wasserman wrote: >> >>> The Javadoc for >>> Map.merge>> util/Map.html#merge-K-V-java.util.function.BiFunction->states >>> >>> that its default implementation is equivalent to: >>> >>> V oldValue = map.get(key); >>> V newValue = (oldValue == null) ? value : >>> remappingFunction.apply(oldValue, value); >>> if (newValue == null) >>> map.remove(key); >>> else if (oldValue == null) >>> map.remove(key); >>> else >>> map.put(key, newValue); >>> >>> I'm somewhat confused by the second branch of this if statement, which is >>> reached if newValue is nonnull and oldValue is null. Does this really >>> *remove* the entry for that key? I would have expected there to be only >>> >>> two branches: either remove the entry if newValue is null, or put newValue >>> if it's nonnull. >>> >> >> There seems to be a hole in the spec regarding how a null value parameter >> is handled. The default implementation treats it as-if the >> remappingFunction returns null. Not unreasonable but not specified. >> >> David >> >> > > From henry.jen at oracle.com Sat Nov 23 00:01:38 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 22 Nov 2013 16:01:38 -0800 Subject: Map.merge Javadoc is confusing In-Reply-To: <528EC28B.6040002@oracle.com> References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> Message-ID: <528FF062.9030800@oracle.com> On 11/21/2013 06:33 PM, David Holmes wrote: > On 22/11/2013 5:02 AM, Louis Wasserman wrote: >> While I agree that case should be specified, I'm not certain I follow why >> that's what's going on here. >> >> The weird condition is that if oldValue is null, not value; oldValue >> is the >> old result of map.get(key). The Javadoc seems not just unspecified, but >> actively wrong. Here's a worked example: >> >> Map map = new HashMap<>(); >> map.merge("foo", 3, Integer::plus); >> Integer fooValue = map.get("foo"); >> >> Going through the Javadoc-specified default implementation: >> >> V oldValue = map.get(key); // oldValue is null >> V newValue = (oldValue == null) ? value : >> remappingFunction.apply(oldValue, value); >> // newValue is set to value, which is 3 >> if (newValue == null) // newValue is nonnull, branch not taken >> map.remove(key); >> else if (oldValue == null) // oldValue is null, branch taken >> map.remove(key); // removes the entry from the map >> else // else if was already triggered, branch not taken >> map.put(key, newValue); >> Seems like a document bug to me, we should fix this @implSpec. Cheers, Henry From mike.duigou at oracle.com Sat Nov 23 00:25:50 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 22 Nov 2013 16:25:50 -0800 Subject: RFR: 8029055: Map.merge @implDoc is incorrect. (was: Map.merge Javadoc is confusing) In-Reply-To: <528FF062.9030800@oracle.com> References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> Message-ID: We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. I've posted a webrev here: http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ There is an identical change in ConcurrentMap's merge(). Mike On Nov 22 2013, at 16:01 , Henry Jen wrote: > > On 11/21/2013 06:33 PM, David Holmes wrote: >> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>> While I agree that case should be specified, I'm not certain I follow why >>> that's what's going on here. >>> >>> The weird condition is that if oldValue is null, not value; oldValue >>> is the >>> old result of map.get(key). The Javadoc seems not just unspecified, but >>> actively wrong. Here's a worked example: >>> >>> Map map = new HashMap<>(); >>> map.merge("foo", 3, Integer::plus); >>> Integer fooValue = map.get("foo"); >>> >>> Going through the Javadoc-specified default implementation: >>> >>> V oldValue = map.get(key); // oldValue is null >>> V newValue = (oldValue == null) ? value : >>> remappingFunction.apply(oldValue, value); >>> // newValue is set to value, which is 3 >>> if (newValue == null) // newValue is nonnull, branch not taken >>> map.remove(key); >>> else if (oldValue == null) // oldValue is null, branch taken >>> map.remove(key); // removes the entry from the map >>> else // else if was already triggered, branch not taken >>> map.put(key, newValue); >>> > > Seems like a document bug to me, we should fix this @implSpec. > > Cheers, > Henry > From henry.jen at oracle.com Sat Nov 23 00:30:33 2013 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 22 Nov 2013 16:30:33 -0800 Subject: RFR: 8029055: Map.merge @implDoc is incorrect. (was: Map.merge Javadoc is confusing) In-Reply-To: References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> Message-ID: <528FF729.2070107@oracle.com> +1 (Not a reviewer). Cheers, Henry On Fri 22 Nov 2013 04:25:50 PM PST, Mike Duigou wrote: > We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. > > I've posted a webrev here: > > http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ > > There is an identical change in ConcurrentMap's merge(). > > Mike > > On Nov 22 2013, at 16:01 , Henry Jen wrote: > >> >> On 11/21/2013 06:33 PM, David Holmes wrote: >>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>>> While I agree that case should be specified, I'm not certain I follow why >>>> that's what's going on here. >>>> >>>> The weird condition is that if oldValue is null, not value; oldValue >>>> is the >>>> old result of map.get(key). The Javadoc seems not just unspecified, but >>>> actively wrong. Here's a worked example: >>>> >>>> Map map = new HashMap<>(); >>>> map.merge("foo", 3, Integer::plus); >>>> Integer fooValue = map.get("foo"); >>>> >>>> Going through the Javadoc-specified default implementation: >>>> >>>> V oldValue = map.get(key); // oldValue is null >>>> V newValue = (oldValue == null) ? value : >>>> remappingFunction.apply(oldValue, value); >>>> // newValue is set to value, which is 3 >>>> if (newValue == null) // newValue is nonnull, branch not taken >>>> map.remove(key); >>>> else if (oldValue == null) // oldValue is null, branch taken >>>> map.remove(key); // removes the entry from the map >>>> else // else if was already triggered, branch not taken >>>> map.put(key, newValue); >>>> >> >> Seems like a document bug to me, we should fix this @implSpec. >> >> Cheers, >> Henry >> > From robert.field at oracle.com Sat Nov 23 01:08:04 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sat, 23 Nov 2013 01:08:04 +0000 Subject: hg: jdk8/tl/langtools: 8028739: javac generates incorrect descriptor for MethodHandle::invoke Message-ID: <20131123010808.22666627CB@hg.openjdk.java.net> Changeset: 4fa835472e3c Author: rfield Date: 2013-11-22 17:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4fa835472e3c 8028739: javac generates incorrect descriptor for MethodHandle::invoke Summary: introduce special handling for signature polymorphic methods Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestMethodHandle.java From joe.darcy at oracle.com Sat Nov 23 07:06:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Nov 2013 23:06:03 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <528D0F80.5010905@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> <528D0F80.5010905@oracle.com> Message-ID: <529053DB.2010705@oracle.com> Hello Mike and Paul, Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at http://cr.openjdk.java.net/~darcy/8006572.4/ Two numerical aspects of the change are different in this iteration: * when two running compensated sums and combined, the compensation portion of the second is now added in first. Since it should have smaller magnitude, this is favorable in terms of error analysis * the final sum returned (or used to compute the average) is (sum + sumCompensation). I checked one of my references, "Accuracy and Stability of Numerical Algorithms" from Nicholas Higham, and that tweak gave a better error bound The test code has been updated as you've suggested (other than porting to TestNG ;-) and I also added a test case for a bug Paul spotted on an earlier review. All the streams tests pass with the new code. Thanks, -Joe On 11/20/2013 11:37 AM, Joe Darcy wrote: > Hi Mike, > > On 11/20/2013 10:31 AM, Mike Duigou wrote: >> - Collectors averagingDouble could use the same @implNote as in >> DoublePipeline. >> >> - DoublePipeline implementation could document the usage of the >> double array indices. >> >> - @summary in test. > > I'll reflect these in the next iteration. > >> >> - I agree with Paul that refactoring as a testNG test would be nice. > > While learning about testNG would be useful, I don't want to take that > on right at the moment ;-) > >> >> - I wondered at the mechanism for combining compensation values. Do >> you have a reference which explains the correctness? I thought >> perhaps directly adding the compensations together before doing >> compensated addition of the two sums might be better. > > One of the inquiries I have out to my numerical reviewer is how to > best combine two compensations. > > In the code as written, from the perspective of one compensation, the > two doubles in the other other compensation are just two more double > values. So I think this is correct, if not ideal. > > The compensation portion of one running sum could be of vastly > different magnitude than the compensation portion (or the high-order > sum bits) of the other sum. Therefore, I believe a direct combination > of either (sum1 + sum2) or (comp1 + comp2) would lose the numerical > properties of interest here. > > Thanks for the feedback, > > -Joe > >> >> Mike >> >> >> On Nov 20 2013, at 00:21 , Joe Darcy wrote: >> >>> Hi Paul, >>> >>> On 11/18/2013 07:38 AM, Paul Sandoz wrote: >>>> Hi Joe, >>>> >>>> You can use the three arg form of collect for >>>> DoublePipeline.sum/average impls, which is already used for average: >>>> >>>> public final OptionalDouble average() { >>>> double[] avg = collect(() -> new double[2], >>>> (ll, i) -> { >>>> ll[0]++; >>>> ll[1] += i; >>>> }, >>>> (ll, rr) -> { >>>> ll[0] += rr[0]; >>>> ll[1] += rr[1]; >>>> }); >>>> return avg[0] > 0 >>>> ? OptionalDouble.of(avg[1] / avg[0]) >>>> : OptionalDouble.empty(); >>>> } >>>> >>>> That would be the most expedient way. >>> Thanks for the tip. For the moment, I'm feeling a bit expedient and >>> used the array-based approach in an iteration of the change: >>> >>> http://cr.openjdk.java.net/~darcy/8006572.3/ >> > From aph at redhat.com Sat Nov 23 11:00:18 2013 From: aph at redhat.com (Andrew Haley) Date: Sat, 23 Nov 2013 11:00:18 +0000 Subject: BigInteger Burnikel-Ziegler division algorithm crossover heuristic In-Reply-To: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> References: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> Message-ID: <52908AC2.1000009@redhat.com> On 11/22/2013 09:47 PM, Brian Burkhalter wrote: > We've been doing fairly extensive micro-benchmark testing of the > effect of adjusting the various algorithm crossover thresholds in > BigInteger (cf. https://bugs.openjdk.java.net/browse/JDK-8022181). Out of interest, is this x86, sparc, or both? It probably doesn't matter, but it might. Andrew. From dmitry.nadezhin at gmail.com Sat Nov 23 12:04:57 2013 From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin) Date: Sat, 23 Nov 2013 16:04:57 +0400 Subject: BigInteger Burnikel-Ziegler division algorithm crossover heuristic In-Reply-To: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> References: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> Message-ID: Time complexity of Knuth divide a/b=q approximately the same as complexity of school multiplication b*q and is length(b)*length(q) = length(b) * (length(a) - length(b)). So the new heuristic seems reasonable for me. On Sat, Nov 23, 2013 at 1:47 AM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > Hello, > > We've been doing fairly extensive micro-benchmark testing of the effect of > adjusting the various algorithm crossover thresholds in BigInteger (cf. > https://bugs.openjdk.java.net/browse/JDK-8022181). There'll be another > post on that particular topic in the near future. This testing did however > expose another topic for which an issue is not yet (but likely will be) on > file, i.e., the heuristic for determining when to use Burnikel-Ziegler > divide and conquer division instead of "standard" division. > > At present the test used is > > if divisor_int_length < BZ_THRESHOLD or dividend_int_length < > BZ_THRESHOLD then > use standard division > else > use B-Z division > > (where BZ_THRESHOLD is currently 50). > > Let {N,D} represent a dividend-divisor pair with the int-length of the > former being N and that of the latter being D. The following cases were > among those initially tested: {T,2T}, {T,T+2}, {T,T}, {T+2,T}, and {2T,T} > where T is the BZ threshold. In all but the last case, where the dividend > is twice the length of the divisor, a (sometimes serious) performance > regression was observed. > > The implementation was reviewed along with the original paper [1]. The > implementation is accurate with respect to the paper as had already been > verified some months ago [2]. It was observed however that something > interesting happens for the case where the int-length of the dividend A is > equal to that of the divisor B. For this situation, the algorithm parameter > t (step 5 in algorithm 3 in the paper) becomes 2. This causes A to be > virtually padded out to a 2T-length value [0,A]. The net result is that the > BZ algorithm ends up being applied in effect to a pair {2T,T} which is > significantly slower than using the standard algorithm on the pair {T,T}. > This appears to be primarily due to the algorithm overhead rather than a > length dependent problem. For the {T,T} case, the following recursive call > sequence of significant operations ensues: > > divide > divideBZ > divide2n1n > divide3n2n > divide2n1n > divideKnuth > multiply > subtract > divide3n2n > divide2n1n > divideKnuth > multiply > subtract > add > > Despite the fact that some of the method calls reduce to simple operations > like dividing zero by non-zero, dividing something by itself, or > multiplying something by zero or one, the algorithm overhead causes the > performance to be worse than had this sequence been used: > > divide > divideKnuth > > Through micro-benchmark testing it was discovered that, given the original > BZ_THRESHOLD criterion is met, for some value C the BZ algorithm will start > to outperform the standard algorithm for the case {T+C,T}, i.e., the > dividend is C ints longer than the divisor. Testing supports the value of > the offset C being independent of the value of the BZ threshold. This > suggests that the following heuristic would be more appropriate for this > algorithm: > > if divisor_int_length < BZ_THRESHOLD or dividend_int_length - > divisor_int_length < BZ_OFFSET_THRESHOLD then > use standard division > else > use B-Z division > > Any comments on this alternative heuristic would be appreciated as I would > not be in the least bit surprised to have missed some fine point altogether. > > Thanks, > > Brian > > [1] Christoph Burnikel and Joachim Ziegler, "Fast Recursive Division", > Max-Planck-Institut fuer Informatik Research Report MPI-I-98-1-022, > http://www.mpi-sb.mpg.de/~ziegler/TechRep.ps.gz. > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018922.html From Alan.Bateman at oracle.com Sat Nov 23 14:38:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Nov 2013 14:38:24 +0000 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <528DE500.2010808@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> <528D9809.6050208@oracle.com> <528DD386.4020902@oracle.com> <528DE500.2010808@oracle.com> Message-ID: <5290BDE0.8060102@oracle.com> On 21/11/2013 10:48, Patrick Zhang wrote: > Hi Alan, > > I have renamed "jdk8004476" to "8004476". And as Daniel's suggestion, > add some comments to XSLTExFuncTest.java. > > I have updated the webrev for review. > http://cr.openjdk.java.net/~pzhang/8027973/webrev/ Thanks for moving it. One thing I notice in the updated webrev is that you've commented it out in the ProblemList.txt file, I assume you meant to remove it. Joe - are you going to sponsor this for Patrick? -Alan From kustos at gmx.net Sun Nov 24 17:07:25 2013 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 24 Nov 2013 18:07:25 +0100 Subject: ArrayStoreException in Class#getAnnotations Message-ID: <5292324D.5080805@gmx.net> Hi The following issue was been bothering me for a while: When you have an annotation with a value that is an array of classes [1] and one of those classes can't be loaded with the class loader of defining class of the element the annotation is defined on you get a ArrayStoreException (stack trace below). Personally I would expect a NoClassDefFoundError or something similar that tells me which class can't be loaded and allows me to fix the issue. Is this the intended behavior? Caused by: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:724) at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:531) at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:355) at sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:286) at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:120) at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72) at java.lang.Class.createAnnotationData(Class.java:3384) at java.lang.Class.annotationData(Class.java:3373) at java.lang.Class.getAnnotations(Class.java:3310) The issue seems to be that AnnotationParser#parseClassValue can return a TypeNotPresentExceptionProxy and AnnotationParser#parseAnnotationArray does not check the value before storing it into a typed array. [1] eg. public @interface Sample { Class[] value(); } I would like to take a moment to lament the fact that you no longer offer fastdebug builds and no longer include sources for non-API classes. Things like this were much easier to debug in the good old JDK 6 days. This is double annoying when your marketing honchos are always touting increased developer productivity. Cheers Philippe From joe.darcy at oracle.com Sun Nov 24 19:02:28 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 24 Nov 2013 11:02:28 -0800 Subject: ArrayStoreException in Class#getAnnotations In-Reply-To: <5292324D.5080805@gmx.net> References: <5292324D.5080805@gmx.net> Message-ID: <52924D44.70804@oracle.com> On 11/24/2013 9:07 AM, Philippe Marschall wrote: [snip] > > I would like to take a moment to lament the fact that you no longer > offer fastdebug builds and no longer include sources for non-API > classes. Things like this were much easier to debug in the good old > JDK 6 days. This is double annoying when your marketing honchos are > always touting increased developer productivity. > > See http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ http://hg.openjdk.java.net/jdk8/jdk8/jdk -Joe From david.holmes at oracle.com Mon Nov 25 00:31:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Nov 2013 10:31:21 +1000 Subject: RFR: 8029055: Map.merge @implDoc is incorrect. In-Reply-To: References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> Message-ID: <52929A59.20204@oracle.com> Hi Mike, There is still no clear spec for what should happen if the param value is null. To me the spec implies that null should become the new value for the mapping, but the code actually removes the mapping. There is also a further error in this spec. First we have: 1112 * If the specified key is not already associated with a value or is 1113 * associated with null, associates it with the given value. 1114 * Otherwise, replaces the value with the results of the given 1115 * remapping function but then we have 1124 *

If the function returns {@code null}, the mapping is removed (or 1125 * remains absent if initially absent). The parenthesized part is wrong. If the mapping was initially absent then the function is never even examined so we don't know if it returns null or not. But let us assume that it would have returned null. If the mapping was initially absent then we create a new mapping from key->value, hence regardless of whether the function would return null, the mapping does not remain absent if initially absent. Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading. Thanks, David On 23/11/2013 10:25 AM, Mike Duigou wrote: > We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. > > I've posted a webrev here: > > http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ > > There is an identical change in ConcurrentMap's merge(). > > Mike > > On Nov 22 2013, at 16:01 , Henry Jen wrote: > >> >> On 11/21/2013 06:33 PM, David Holmes wrote: >>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>>> While I agree that case should be specified, I'm not certain I follow why >>>> that's what's going on here. >>>> >>>> The weird condition is that if oldValue is null, not value; oldValue >>>> is the >>>> old result of map.get(key). The Javadoc seems not just unspecified, but >>>> actively wrong. Here's a worked example: >>>> >>>> Map map = new HashMap<>(); >>>> map.merge("foo", 3, Integer::plus); >>>> Integer fooValue = map.get("foo"); >>>> >>>> Going through the Javadoc-specified default implementation: >>>> >>>> V oldValue = map.get(key); // oldValue is null >>>> V newValue = (oldValue == null) ? value : >>>> remappingFunction.apply(oldValue, value); >>>> // newValue is set to value, which is 3 >>>> if (newValue == null) // newValue is nonnull, branch not taken >>>> map.remove(key); >>>> else if (oldValue == null) // oldValue is null, branch taken >>>> map.remove(key); // removes the entry from the map >>>> else // else if was already triggered, branch not taken >>>> map.put(key, newValue); >>>> >> >> Seems like a document bug to me, we should fix this @implSpec. >> >> Cheers, >> Henry >> > From paul.sandoz at oracle.com Mon Nov 25 09:13:57 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Nov 2013 10:13:57 +0100 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <529053DB.2010705@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> <528D0F80.5010905@oracle.com> <529053DB.2010705@oracle.com> Message-ID: <3AD6D713-01EF-4174-8554-FB72E8626744@oracle.com> +1 Paul. On Nov 23, 2013, at 8:06 AM, Joe Darcy wrote: > Hello Mike and Paul, > > Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at > > http://cr.openjdk.java.net/~darcy/8006572.4/ > > Two numerical aspects of the change are different in this iteration: > > * when two running compensated sums and combined, the compensation portion of the second is now added in first. Since it should have smaller magnitude, this is favorable in terms of error analysis > > * the final sum returned (or used to compute the average) is (sum + sumCompensation). I checked one of my references, "Accuracy and Stability of Numerical Algorithms" from Nicholas Higham, and that tweak gave a better error bound > > The test code has been updated as you've suggested (other than porting to TestNG ;-) and I also added a test case for a bug Paul spotted on an earlier review. > > All the streams tests pass with the new code. > > Thanks, > > -Joe From paul.sandoz at oracle.com Mon Nov 25 09:49:42 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Nov 2013 10:49:42 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> HI David, Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? Paul. From paul.sandoz at oracle.com Mon Nov 25 09:18:15 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 25 Nov 2013 09:18:15 +0000 Subject: hg: jdk8/tl/jdk: 8028516: Java doc error in Int/Long/Double/Stream.peek Message-ID: <20131125091828.3B135627FF@hg.openjdk.java.net> Changeset: 1f45b24ffe4b Author: psandoz Date: 2013-11-25 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f45b24ffe4b 8028516: Java doc error in Int/Long/Double/Stream.peek Reviewed-by: chegar ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java From sean.coffey at oracle.com Mon Nov 25 10:08:34 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 25 Nov 2013 10:08:34 +0000 Subject: Different error decoding Shift-JIS sequence in JDK8 In-Reply-To: <528F5A2B.2000402@oracle.com> References: <528F5A2B.2000402@oracle.com> Message-ID: <529321A2.40905@oracle.com> Sherman can answer this best. The 8008386 fix for 8 differs from earlier updates since alot of the code was rewritten in this area. The initial report was identified as a regression in JDK6. Back in 2005, the 6227339 fix changed behaviour which meant that invalid single byte characters were treated incorrectly when decoding Shift_JIS encoded bytes. It meant that two bytes are decoded to a "?" character rather than one. The valid single byte characters are lost as a result and I believe this was all unintended when the 6227339 fix was made. Changes made in 8008386 mean that the case of a malformed character (legal leading byte) followed by a valid single byte should now return a replacement character for the first malformed byte and a correctly decoded single byte character. regards, Sean. On 22/11/2013 13:20, Alan Bateman wrote: > On 22/11/2013 11:02, Charles Oliver Nutter wrote: >> Apologies if this is not the correct place to post this, bit i18n >> seemed more focused on languages and localization than the mechanics >> of transcoding. >> >> I have noticed a behavioral difference in JDK8 decoding a two-byte >> Shift-JIS sequence. Specifically, JDK8 appears to report malformed >> input for what should be a valid Shift-JIS sequence, where JDK7 >> reported that the character was unmappable. > I assume this is related to JDK-8008386 [1] and I'm sure Sherman or > Sean will jump in to explain this (which seems to be related to a long > standing regression). > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8008386 > Apologies if this is not the correct place to post this, bit i18n > seemed more focused on languages and localization than the mechanics > of transcoding. > > I have noticed a behavioral difference in JDK8 decoding a two-byte > Shift-JIS sequence. Specifically, JDK8 appears to report malformed > input for what should be a valid Shift-JIS sequence, where JDK7 > reported that the character was unmappable. > > The code to reproduce is fairly simple: > > byte[] bytes = {(byte)0xEF, 0x40}; > CharsetDecoder decoder = Charset.forName("Shift-JIS").newDecoder(); > System.out.println(decoder.decode(ByteBuffer.wrap(bytes), > CharBuffer.allocate(2), false)); > > Note that this is pumping the decoder directly and specifying partial > input (false). We use this mechanism in JRuby for transcoding > arbitrary byte[] from one encoding to another. > > The result of running this on JDK7 is "UNMAPPABLE[2]" while the result > on JDK8 is "MALFORMED[1]". > > Information online is spotty as to whether this sequence is valid. It > does appear on the table for [JIS X > 203](http://x0213.org/codetable/sjis-0213-2004-std.txt) and several > articles on Shift-JIS claim that it is at worst undefined and at best > valid. So I'm leaning toward this being a bug in JDK8's Shift-JIS > decoder. > > Note that on JDK7 it is "unmappable", which may mean this code > represents a character with no equivalent in Unicode. > > I have uploaded my code to github here: > https://github.com/headius/jdk8_utf8_decoding_bug > > Thoughts? > > - Charlie From joel.franck at oracle.com Mon Nov 25 14:57:51 2013 From: joel.franck at oracle.com (Joel Borggren-Franck) Date: Mon, 25 Nov 2013 15:57:51 +0100 Subject: hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ... In-Reply-To: <5278BA3F.3070602@gmail.com> References: <20131104181255.459946297B@hg.openjdk.java.net> <5278B27C.30303@gmail.com> <5278BA3F.3070602@gmail.com> Message-ID: <20131125145751.GG27258@oracle.com> Hi Peter, I filed: https://bugs.openjdk.java.net/browse/JDK-8029100 Thanks! cheers /Joel On 2013-11-05, Peter Levart wrote: > Hi John, > > Speaking of names, the following test: > > package pkg; > > public class Test { > public static void main(String[] args) > { > Runnable r = () -> {}; > Class c = r.getClass(); > Class ac = java.lang.reflect.Array.newInstance(c, 0).getClass(); > System.out.println("c: " + c.getName() + " / " + > c.getSimpleName()); > System.out.println("ac: " + ac.getName() + " / " + > ac.getSimpleName()); > } > } > > > Prints: > > c: pkg.Test$$Lambda$1/798154996 / Test$$Lambda$1/798154996 > ac: [Lpkg.Test$$Lambda$1; / Test$$Lambda$1/798154996[] > > > I think the array class name is missing 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.field at 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 serialization fails once reflection proxy generation kicks in > >>Reviewed-by: ksrini, briangoetz, jfranck > >>Contributed-by:joel.franck at oracle.com,brian.goetz at oracle.com,robert.field at oracle.com > >> > >>! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java > >>! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java > >>! src/share/classes/sun/reflect/misc/ReflectUtil.java > >>+ test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java > >>! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java > >>+ test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java > >> > >Hi Robert, > > > >I also propose a much faster variant of: > > > >+ /** > >+ * Checks if {@code Class cls} is a VM-anonymous class > >+ * as defined by {@link sun.misc.Unsafe#defineAnonymousClass} > >+ * (not to be confused with a Java Language anonymous inner class). > >+ */ > >+ public static boolean isVMAnonymousClass(Class cls) { > >+ return cls.getSimpleName().contains("/"); > >+ } > > > > > >The following: > > > > public static boolean isVMAnonymousClassFAST(Class cls) { > > String name = cls.getName(); > > for (int i = name.length() - 1; i >= 0; i--) { > > char c = name.charAt(i); > > if (c == '.') return false; > > if (c == '/') return true; > > } > > return false; // root package > > } > > > >It's about 12..25x faster for typical class names and doesn't > >produce any garbage. > > > > > >Regards, Peter > > > From brian.burkhalter at oracle.com Mon Nov 25 15:29:58 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Nov 2013 07:29:58 -0800 Subject: BigInteger Burnikel-Ziegler division algorithm crossover heuristic In-Reply-To: <52908AC2.1000009@redhat.com> References: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> <52908AC2.1000009@redhat.com> Message-ID: On Nov 23, 2013, at 3:00 AM, Andrew Haley wrote: >> We've been doing fairly extensive micro-benchmark testing of the >> effect of adjusting the various algorithm crossover thresholds in >> BigInteger (cf. https://bugs.openjdk.java.net/browse/JDK-8022181). > > Out of interest, is this x86, sparc, or both? It probably doesn't > matter, but it might. Various flavors of x86 and AMD Opteron but no SPARC as yet. Brian From brian.burkhalter at oracle.com Mon Nov 25 15:30:57 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 25 Nov 2013 07:30:57 -0800 Subject: BigInteger Burnikel-Ziegler division algorithm crossover heuristic In-Reply-To: References: <85803710-4752-40C9-A64D-AFE81D1DDBF8@oracle.com> Message-ID: On Nov 23, 2013, at 4:04 AM, Dmitry Nadezhin wrote: > Time complexity of Knuth divide a/b=q approximately the same as > complexity of school multiplication b*q and is > length(b)*length(q) = length(b) * (length(a) - length(b)). > So the new heuristic seems reasonable for me. Thanks, Dima. Brian From pbenedict at apache.org Mon Nov 25 15:43:28 2013 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 25 Nov 2013 09:43:28 -0600 Subject: JavaDoc is indenting multiple documented annotations Message-ID: On 10/16, I wrote: > If you look at the current classes (b111) that have documented annotations, > the first annotation is correctly left-aligned but all others are indented > by one space. If this is already reported, my apologies; if not, please > confirm. > > Example: > http://download.java.net/jdk8/docs/api/java/lang/FunctionalInterface.html This is very low-hanging fruit, but I think this is a bug. The latest (b116) is still indenting wrong. -- Cheers, Paul From lowasser at google.com Mon Nov 25 15:47:06 2013 From: lowasser at google.com (Louis Wasserman) Date: Mon, 25 Nov 2013 10:47:06 -0500 Subject: RFR: 8029055: Map.merge @implDoc is incorrect. In-Reply-To: <52929A59.20204@oracle.com> References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> <52929A59.20204@oracle.com> Message-ID: FWIW, I would tend to expect map.merge(key, value, remappingFunction) to be equivalent to map.compute(key, (k, oldValue) -> (oldValue == null) ? value : remappingFunction.apply(oldValue, value)); ...in which case the mapping would be removed. On Sun, Nov 24, 2013 at 7:31 PM, David Holmes wrote: > Hi Mike, > > There is still no clear spec for what should happen if the param value is > null. To me the spec implies that null should become the new value for the > mapping, but the code actually removes the mapping. > > There is also a further error in this spec. First we have: > > 1112 * If the specified key is not already associated with a value or > is > 1113 * associated with null, associates it with the given value. > 1114 * Otherwise, replaces the value with the results of the given > 1115 * remapping function > > but then we have > > 1124 *

If the function returns {@code null}, the mapping is > removed (or > 1125 * remains absent if initially absent). > > The parenthesized part is wrong. If the mapping was initially absent then > the function is never even examined so we don't know if it returns null or > not. But let us assume that it would have returned null. If the mapping was > initially absent then we create a new mapping from key->value, hence > regardless of whether the function would return null, the mapping does not > remain absent if initially absent. > > Also you have changed the method implementation not just the implDoc so > the bug synopsis is somewhat misleading. > > Thanks, > David > > On 23/11/2013 10:25 AM, Mike Duigou wrote: > >> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this >> issue. >> >> I've posted a webrev here: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ >> >> There is an identical change in ConcurrentMap's merge(). >> >> Mike >> >> On Nov 22 2013, at 16:01 , Henry Jen wrote: >> >> >>> On 11/21/2013 06:33 PM, David Holmes wrote: >>> >>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>>> >>>>> While I agree that case should be specified, I'm not certain I follow >>>>> why >>>>> that's what's going on here. >>>>> >>>>> The weird condition is that if oldValue is null, not value; oldValue >>>>> is the >>>>> old result of map.get(key). The Javadoc seems not just unspecified, >>>>> but >>>>> actively wrong. Here's a worked example: >>>>> >>>>> Map map = new HashMap<>(); >>>>> map.merge("foo", 3, Integer::plus); >>>>> Integer fooValue = map.get("foo"); >>>>> >>>>> Going through the Javadoc-specified default implementation: >>>>> >>>>> V oldValue = map.get(key); // oldValue is null >>>>> V newValue = (oldValue == null) ? value : >>>>> remappingFunction.apply(oldValue, value); >>>>> // newValue is set to value, which is 3 >>>>> if (newValue == null) // newValue is nonnull, branch not taken >>>>> map.remove(key); >>>>> else if (oldValue == null) // oldValue is null, branch taken >>>>> map.remove(key); // removes the entry from the map >>>>> else // else if was already triggered, branch not taken >>>>> map.put(key, newValue); >>>>> >>>>> >>> Seems like a document bug to me, we should fix this @implSpec. >>> >>> Cheers, >>> Henry >>> >>> >> -- Louis Wasserman From artem.ananiev at oracle.com Mon Nov 25 15:52:03 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 25 Nov 2013 19:52:03 +0400 Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: <52937223.408@oracle.com> Hi, Volker, just a few very minor comments about the client changes: 1. mlib_sys.c: the change is fine, but it makes the following comment obsolete. 2. XRBackendNative.c: the same comment here. 3. Awt2dLibraries.gmk: $(JDK_TOPDIR)/src/aix/porting/porting_aix.c would be better than just porting_aix.c Thanks, Artem On 11/20/2013 10:26 PM, Volker Simonis wrote: > Hi, > > this is the second review round for "8024854: Basic changes and files to > build the class library on AIX > ". The previous > reviews can be found at the end of this mail in the references section. > > I've tried to address all the comments and suggestions from the first > round and to further streamline the patch (it perfectly builds on > Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The > biggest change compared to the first review round is the new "aix/" > subdirectory which I've now created under "jdk/src" and which contains > AIX-only code. > > The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stage > repository which has been recently synchronised with the jdk8 master: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > > Below (and in the webrev) you can find some comments which explain the > changes to each file. In order to be able to push this big change, I > need the approval of reviewers from the lib, net, svc, 2d, awt and sec > groups. So please don't hesitate to jump at it - there are enough > changes for everybody:) > > Thank you and best regards, > Volker > > *References:* > > The following reviews have been posted so far (thanks Iris for > collecting them :) > > - Alan Bateman (lib): Initial comments (16 Sep [2]) > - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) > - Michael McMahon (net): Initial comments (20 Sept [4]) > - Steffan Larsen (svc): APPROVED (20 Sept [5]) > - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments > (15 Oct [7]) > - Sean Mullan (sec): Initial comments (26 Sept [8]) > > [2]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html > [3]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html > [4]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html > [5]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html > [6]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html > [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html > [8]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html > > > *Detailed change description:* > > The new "jdk/src/aix" subdirectory contains the following new and > AIX-specific files for now: > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileStore.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/classes/sun/nio/fs/AixFileSystemProvider.java > src/aix/classes/sun/nio/fs/AixNativeDispatcher.java > src/aix/classes/sun/tools/attach/AixAttachProvider.java > src/aix/classes/sun/tools/attach/AixVirtualMachine.java > src/aix/native/java/net/aix_close.c > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/sun/nio/fs/AixNativeDispatcher.c > src/aix/native/sun/tools/attach/AixVirtualMachine.c > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > * Added these two files for AIX relevant utility code. > * Currently these files only contain an implementation of |dladdr| > which is not available on AIX. > * In the first review round the existing |dladdr| users in the code > either called the version from the HotSpot on AIX > (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private > copy of the whole implementation > (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not > necessary any more. > > The new file layout required some small changes to the makefiles to make > them aware of the new directory locations: > > > makefiles/CompileDemos.gmk > > * Add an extra argument to |SetupJVMTIDemo| which can be used to pass > additional source locations. > * Currently this is only used on AIX for the AIX porting utilities > which are required by hprof. > > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/ServiceabilityLibraries.gmk > > * On AIX add the sources of the AIX porting utilities to the build. > They are required by |src/solaris/native/sun/awt/awt_LoadLibrary.c| > and |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is > not available on AIX. > > > makefiles/lib/NioLibraries.gmk > > * Make the AIX-build aware of the new NIO source locations under > |src/aix/native/sun/nio/|. > > > makefiles/lib/NetworkingLibraries.gmk > > * Make the AIX-build aware of the new |aix_close.c| source location > under |src/aix/native/java/net/|. > > > src/share/bin/jli_util.h > > * Define |JLI_Lseek| on AIX. > > > src/share/lib/security/java.security-aix > > * Provide default |java.security-aix| for AIX based on the latest > Linux version as suggested by Sean Mullan. > > > src/share/native/common/check_code.c > > * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is > legal, but the code in |check_code.c| does not handles this > properly. So we wrap the two methods on AIX and return a non-NULL > pointer even if we allocate 0 bytes. > > > src/share/native/sun/awt/medialib/mlib_sys.c > > * |malloc| always returns 8-byte aligned pointers on AIX as well. > > > src/share/native/sun/awt/medialib/mlib_types.h > > * Add AIX to the list of known platforms. > > > src/share/native/sun/font/layout/KernTable.cpp > > * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is > too common and may be defined in other headers as well as on the > command line and |xlc| bails out on macro redefinitions with a > different value. > > > src/share/native/sun/security/ec/impl/ecc_impl.h > > * Define required types and macros on AIX. > > > src/solaris/back/exec_md.c > > * AIX behaves like Linux in this case so check for it in the Linux branch. > > > src/solaris/bin/java_md_solinux.c, > src/solaris/bin/java_md_solinux.h > > * On AIX |LD_LIBRARY_PATH| is called |LIBPATH| > * Always use |LD_LIBRARY_PATH| macro instead of using the string > "|LD_LIBRARY_PATH|" directly to cope with different library path names. > * Add |jre/lib//jli| to the standard library search path on AIX > because the AIX linker doesn't support the |-rpath| option. > * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in this > case, AIX behaves like Linux. > * Removed the definition of |JVM_DLL|, |JAVA_DLL| and > |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are > redefined in the corresponding |.c| files anyway. > > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > * Provide basic |fontconfig.properties|for AIX. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix, > src/aix/classes/sun/tools/attach/AixAttachProvider.java, > src/aix/classes/sun/tools/attach/AixVirtualMachine.java, > src/aix/native/sun/tools/attach/AixVirtualMachine.c > > * Provide AIX specific Java versions, mostly based on the > corresponding Linux versions. > > > src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java > src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java > > * Detect AIX operating system and return the corresponding channel and > file system providers. > > > src/solaris/classes/sun/nio/ch/Port.java > > * Add a callback function |unregisterImpl(int fd)| for implementations > that need special handling when |fd| is removed and call it from > |unregister(int fd)|. By default the implementation of > |unregisterImpl(int fd)| is empty except for the derived > |AixPollPort| class on AIX. > > > src/solaris/demo/jvmti/hprof/hprof_md.c > > * Add AIX support. AIX mostly behaves like Linux, with the one > exception that it has no |dladdr| functionality. > * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX. > > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c > > * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory). > > > src/solaris/native/common/jdk_util_md.h > > * Add AIX definitions of the |ISNANF| and |ISNAND| macros. > > > src/solaris/native/java/io/io_util_md.c > > * AIX behaves like Linux in this case so check for it in the Linux branch. > > > src/solaris/native/java/lang/UNIXProcess_md.c > > * AIX behaves mostly like Solraris in this case so adjust the ifdefs > accordingly. > > > src/solaris/native/java/lang/childproc.c > > * AIX does not understand '/proc/self' - it requires the real process > ID to query the proc file system for the current process. > > > src/solaris/native/java/net/NetworkInterface.c > > * Add AIX support into the Linux branch because AIX mostly behaves > like AIX for IPv4. > * AIX needs a special function to enumerate IPv6 interfaces and to > query the MAC address. > * Moved the declaration of |siocgifconfRequest| to the beginning a the > function (as recommend by Michael McMahon) to remain C89 compatible. > > > src/solaris/native/java/net/PlainSocketImpl.c > > * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL| if > the socket is closed. The default error message is then confusing. > > > src/aix/native/java/net/aix_close.c, > src/share/native/java/net/net_util.c > > * As recommended by Michael McMahon and Alan Bateman I've move an > adapted version of |linux_close.c| to > |src/aix/native/java/net/aix_close.c| because we also need the file > and socket wrappers on AIX. > * Compared to the Linux version, we've added the initialization of > some previously uninitialized data structures. > * Also, on AIX we don't have |__attribute((constructor))| so we need > to initialize manually (from |JNI_OnLoad()| in > |src/share/native/java/net/net_util.c|. > > > src/solaris/native/java/net/net_util_md.h > > * AIX needs the same workaround for I/O cancellation like Linux and > MacOSX. > > > src/solaris/native/java/net/net_util_md.c > > * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX. > * On AIX we have to ignore failures due to |ENOBUFS| when setting the > |SO_SNDBUF|/|SO_RCVBUF| socket options. > > > src/solaris/native/java/util/TimeZone_md.c > > * Currently on AIX the only way to get the platform time zone is to > read it from the |TZ| environment variable. > > > src/solaris/native/sun/awt/awt_LoadLibrary.c > > * Use the |dladdr| from |porting_aix.{c,h}| on AIX. > > > src/solaris/native/sun/awt/fontpath.c > > * Changed some macros from |if !defined(__linux__)| to |if > defined(__solaris__)| because that's their real meaning. > * Add AIX specific fontpath settings and library search paths for > |libfontconfig.so|. > > > src/solaris/native/sun/java2d/x11/X11SurfaceData.c > > * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to > avoid name clashes (|MIN| and |MAX| are much too common and thexy > are already defined in some AIX system headers). > > > src/solaris/native/sun/java2d/x11/XRBackendNative.c > > * Handle AIX like Solaris. > > > src/solaris/native/sun/nio/ch/Net.c > > * Add AIX-specific includes and constant definitions. > * On AIX "socket extensions for multicast source filters" support > depends on the OS version. Check for this and throw appropriate > exceptions if it is requested but not supported. This is needed to > pass > JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast > > > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > > * On AIX |strerror()| is not thread-safe so we have to use > |strerror_r()| instead. > * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to > NULL for the directory stream end. Otherwise, 'errno' will contain > the error code. > * Handle some AIX corner cases for the results of the |statvfs64()| call. > * On AIX |getgrgid_r()| returns ESRCH if group does not exist. > > > src/solaris/native/sun/security/pkcs11/j2secmod_md.c > > * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX. > > > test/java/lang/ProcessBuilder/Basic.java > test/java/lang/ProcessBuilder/DestroyTest.java > > * Port this test to AIX and make it more robust (i.e. recognize the > "C" locale as |isEnglish()|, ignore VM-warnings in the output, make > sure the "grandchild" processes created by the test don't run too > long (60s vs. 6666s) because in the case of test problems these > processes will pollute the process space, make sure the test fails > with an error and doesn't hang indefinitley in the case of a problem). > > *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this > intended? > > Well, |_AIX| is defined in some system headers while |AIX| is defined by > the build system. This is already used inconsistently (i.e. |__linux__| > vs. |LINUX|) and in general I try to be consistent with the style of the > file where I the changes are. That said, I changes most of the > occurences of |AIX| to |_AIX|. > > *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are > they supposed to be there? > > We currently don't support OS/400 (later renamed into i5/OS and > currently called IBM i) in our OpenJDK port but we do support it in our > internel, SAP JVM build. We stripped out all the extra OS/400 > functionality from the port but in some places where there is common > functionality needd by both, AIX and OS/400 the OS/400 support may still > be visible in the OpenJDK port. I don't think this is a real problem and > it helps us to keep our internel sources in sync with the OpenJDK port. > That said, I think I've removed all the references to OS/400 now. > > From david.r.chase at oracle.com Mon Nov 25 17:12:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 25 Nov 2013 12:12:51 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: I wasn't 100% clear on the desire to not add another preloaded class, and I was under the impression that if s.m.Unsafe could not load, then things were hosed indeed. If there's another already preloaded class that would be a good choice, it is an easy change to make; MethodHandleNatives, or others in the java.lang.invoke world, also seem potentially appropriate, though there is also a possibility that someone might want to backport this to 7 (I can demonstrate the bug in 6, and I suspect also in 5 if I could get my hands on such a VM) so we need to be aware of that, too (I am not myself 100% clear on which of those files appeared when, except that sun.misc.Unsafe has been around for a while). David On 2013-11-25, at 4:49 AM, Paul Sandoz wrote: > HI David, > > Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? > > Paul. > > > > From dalibor.topic at oracle.com Mon Nov 25 17:15:18 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 25 Nov 2013 18:15:18 +0100 Subject: ArrayStoreException in Class#getAnnotations In-Reply-To: <52924D44.70804@oracle.com> References: <5292324D.5080805@gmx.net> <52924D44.70804@oracle.com> Message-ID: <529385A6.9070401@oracle.com> On 11/24/13 8:02 PM, Joe Darcy wrote: > > On 11/24/2013 9:07 AM, Philippe Marschall wrote: > > [snip] > >> >> I would like to take a moment to lament the fact that you no longer offer fastdebug builds and no longer include sources for non-API classes. Things like this were much easier to debug in the good old JDK 6 days. This is double annoying when your marketing honchos are always touting increased developer productivity. >> >> > > See > > http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/ > http://hg.openjdk.java.net/jdk8/jdk8/jdk And see http://openjdk.java.net/groups/build/ for build instructions. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From mike.duigou at oracle.com Mon Nov 25 17:57:32 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Nov 2013 09:57:32 -0800 Subject: Initial request for review of JDK-8006572 DoubleStream.sum()/average() implementations that reduce numerical errors In-Reply-To: <529053DB.2010705@oracle.com> References: <528484F3.5030706@oracle.com> <6D817B0A-96E8-42A8-8B8B-C1884253F689@oracle.com> <528C710F.4070909@oracle.com> <78CE3D21-D279-4BDC-8C3F-930F63044149@oracle.com> <528D0F80.5010905@oracle.com> <529053DB.2010705@oracle.com> Message-ID: <17B18871-F198-433C-920B-1475D11D4753@oracle.com> Looks good Mike On Nov 22 2013, at 23:06 , Joe Darcy wrote: > Hello Mike and Paul, > > Thanks for reviewing the earlier versions of the change; I've posted an update revision for your consideration at > > http://cr.openjdk.java.net/~darcy/8006572.4/ > > Two numerical aspects of the change are different in this iteration: > > * when two running compensated sums and combined, the compensation portion of the second is now added in first. Since it should have smaller magnitude, this is favorable in terms of error analysis > > * the final sum returned (or used to compute the average) is (sum + sumCompensation). I checked one of my references, "Accuracy and Stability of Numerical Algorithms" from Nicholas Higham, and that tweak gave a better error bound > > The test code has been updated as you've suggested (other than porting to TestNG ;-) and I also added a test case for a bug Paul spotted on an earlier review. > > All the streams tests pass with the new code. > > Thanks, > > -Joe > > On 11/20/2013 11:37 AM, Joe Darcy wrote: >> Hi Mike, >> >> On 11/20/2013 10:31 AM, Mike Duigou wrote: >>> - Collectors averagingDouble could use the same @implNote as in DoublePipeline. >>> >>> - DoublePipeline implementation could document the usage of the double array indices. >>> >>> - @summary in test. >> >> I'll reflect these in the next iteration. >> >>> >>> - I agree with Paul that refactoring as a testNG test would be nice. >> >> While learning about testNG would be useful, I don't want to take that on right at the moment ;-) >> >>> >>> - I wondered at the mechanism for combining compensation values. Do you have a reference which explains the correctness? I thought perhaps directly adding the compensations together before doing compensated addition of the two sums might be better. >> >> One of the inquiries I have out to my numerical reviewer is how to best combine two compensations. >> >> In the code as written, from the perspective of one compensation, the two doubles in the other other compensation are just two more double values. So I think this is correct, if not ideal. >> >> The compensation portion of one running sum could be of vastly different magnitude than the compensation portion (or the high-order sum bits) of the other sum. Therefore, I believe a direct combination of either (sum1 + sum2) or (comp1 + comp2) would lose the numerical properties of interest here. >> >> Thanks for the feedback, >> >> -Joe >> >>> >>> Mike >>> >>> >>> On Nov 20 2013, at 00:21 , Joe Darcy wrote: >>> >>>> Hi Paul, >>>> >>>> On 11/18/2013 07:38 AM, Paul Sandoz wrote: >>>>> Hi Joe, >>>>> >>>>> You can use the three arg form of collect for DoublePipeline.sum/average impls, which is already used for average: >>>>> >>>>> public final OptionalDouble average() { >>>>> double[] avg = collect(() -> new double[2], >>>>> (ll, i) -> { >>>>> ll[0]++; >>>>> ll[1] += i; >>>>> }, >>>>> (ll, rr) -> { >>>>> ll[0] += rr[0]; >>>>> ll[1] += rr[1]; >>>>> }); >>>>> return avg[0] > 0 >>>>> ? OptionalDouble.of(avg[1] / avg[0]) >>>>> : OptionalDouble.empty(); >>>>> } >>>>> >>>>> That would be the most expedient way. >>>> Thanks for the tip. For the moment, I'm feeling a bit expedient and used the array-based approach in an iteration of the change: >>>> >>>> http://cr.openjdk.java.net/~darcy/8006572.3/ >>> >> > From joel.franck at oracle.com Mon Nov 25 18:33:44 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 25 Nov 2013 19:33:44 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: <062F2AA5-48A7-4D6C-BB37-55673126B453@oracle.com> Hi, On 22 Nov 2013, at 20:07, David Chase wrote: > The last choice was to define a helper method in sun.misc.Unsafe that > would always throw IllegalAccessError when called, and use that Method * > in the should-throw-IAE case. The risk here is that the helper method > is zero-arg, where the method about to be called (and whose parameters > had been pushed on the stack) could have a different set of arguments, > and perhaps there is some platform where this does not work cleanly. > However, the existing code that checks for null and throws AME seems to > not be special-cased for number of args (that is, it branches to a > generic exception thrower with no additional cleanup). In addition, I > enhanced the test to try faulty invocations with both zero and 11 args, > and to run under jtreg in several modes, and I added iteration to help > force code to the compiled case as well, and it has performed properly > on Sparc, Intel, and embedded. I was under the impression that a HotSpot Method can move as the result of a class redefine. An added bonus of having this in s.m.Unsafe is that hopefully it should be very uncommon to redefine those methods. cheers /Joel From Alan.Bateman at oracle.com Mon Nov 25 19:07:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Nov 2013 19:07:18 +0000 Subject: JavaDoc is indenting multiple documented annotations In-Reply-To: References: Message-ID: <52939FE6.2040104@oracle.com> On 25/11/2013 15:43, Paul Benedict wrote: > On 10/16, I wrote: > >> If you look at the current classes (b111) that have documented > annotations, >> the first annotation is correctly left-aligned but all others are indented >> by one space. If this is already reported, my apologies; if not, please >> confirm. >> >> Example: >> http://download.java.net/jdk8/docs/api/java/lang/FunctionalInterface.html > This is very low-hanging fruit, but I think this is a bug. The latest > (b116) is still indenting wrong. > Have you brought this up on javadoc-dev? -Alan. From lana.steuck at oracle.com Mon Nov 25 19:08:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:08:46 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20131125190851.92AAF62825@hg.openjdk.java.net> Changeset: 7299367c8aa4 Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7299367c8aa4 Added tag jdk8-b116 for changeset 5fdc44652089 ! .hgtags Changeset: e53d1ee4d2ae Author: lana Date: 2013-11-14 23:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e53d1ee4d2ae Merge Changeset: d6820a414f18 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d6820a414f18 Added tag jdk8-b117 for changeset e53d1ee4d2ae ! .hgtags Changeset: e648df60c8a2 Author: lana Date: 2013-11-25 09:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e648df60c8a2 Merge From lana.steuck at oracle.com Mon Nov 25 19:08:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:08:56 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131125190907.26CBC62827@hg.openjdk.java.net> Changeset: 774c63629870 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/774c63629870 Added tag jdk8-b116 for changeset 0fb1a427fbf6 ! .hgtags Changeset: 1db3d4e4d189 Author: lana Date: 2013-11-15 07:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1db3d4e4d189 Merge Changeset: 8d014b039b44 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8d014b039b44 Added tag jdk8-b117 for changeset 1db3d4e4d189 ! .hgtags Changeset: 44ea3815e414 Author: lana Date: 2013-11-25 09:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/44ea3815e414 Merge From lana.steuck at oracle.com Mon Nov 25 19:08:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:08:51 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20131125190908.5C8FC62828@hg.openjdk.java.net> Changeset: fe56ba456fd3 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fe56ba456fd3 Added tag jdk8-b116 for changeset 587560c222a2 ! .hgtags Changeset: 76a598cf50c4 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/76a598cf50c4 Added tag jdk8-b117 for changeset fe56ba456fd3 ! .hgtags Changeset: 4900fcaae498 Author: lana Date: 2013-11-25 09:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/4900fcaae498 Merge From lana.steuck at oracle.com Mon Nov 25 19:08:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:08:56 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20131125190919.64DCC62829@hg.openjdk.java.net> Changeset: 64d119680f0a Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64d119680f0a Added tag jdk8-b116 for changeset 3c040b04af05 ! .hgtags Changeset: 19de039a03a6 Author: lana Date: 2013-11-15 07:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/19de039a03a6 Merge - test/tools/javac/ArraysInIntersections.java - test/tools/javac/InferArraysInIntersections.java - test/tools/javac/diags/examples/InterfaceOrArrayExpected.java Changeset: 4fd6a7ff8c06 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4fd6a7ff8c06 Added tag jdk8-b117 for changeset 19de039a03a6 ! .hgtags Changeset: 7ef88faaa16c Author: lana Date: 2013-11-25 09:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7ef88faaa16c Merge From lana.steuck at oracle.com Mon Nov 25 19:08:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:08:46 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20131125190847.985AE62824@hg.openjdk.java.net> Changeset: c1029b02ca87 Author: ihse Date: 2013-11-08 09:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1029b02ca87 8027836: Webrev should handle files that has been moved from a directory which now is removed. Reviewed-by: mduigou, tbell ! make/scripts/webrev.ksh Changeset: cbfe5da942c6 Author: katleman Date: 2013-11-11 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cbfe5da942c6 Merge Changeset: a4afb0a8d55e Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a4afb0a8d55e Added tag jdk8-b116 for changeset cbfe5da942c6 ! .hgtags Changeset: 0a6db1aac998 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0a6db1aac998 Added tag jdk8-b117 for changeset a4afb0a8d55e ! .hgtags Changeset: 24847bd96465 Author: lana Date: 2013-11-25 09:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/24847bd96465 Merge From lana.steuck at oracle.com Mon Nov 25 19:09:14 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:09:14 +0000 Subject: hg: jdk8/tl/hotspot: 36 new changesets Message-ID: <20131125191035.64E3D6282A@hg.openjdk.java.net> Changeset: aec3226be72d Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aec3226be72d Added tag jdk8-b116 for changeset 52b076e6ffae ! .hgtags Changeset: 20c72bec2707 Author: amurillo Date: 2013-11-08 07:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20c72bec2707 8028061: new hotspot build - hs25-b59 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9d8b29a0548c Author: mgerdin Date: 2013-11-08 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d8b29a0548c 8027237: New tests on ReservedSpace/VirtualSpace classes Summary: Three tests added: 1) test stressing VirtualSpace by resizing it constantly 2) test running unit tests in several threads 3) test checking protected area in ReservedHeapSpace class Reviewed-by: stefank, zgu Contributed-by: aleksey.timofeev at oracle.com ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReadFromNoaccessArea.java + test/runtime/memory/RunUnitTestsConcurrently.java + test/runtime/memory/StressVirtualSpaceResize.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 19f8a5d7600b Author: mgerdin Date: 2013-11-08 23:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19f8a5d7600b Merge Changeset: fce21ac5968d Author: acorn Date: 2013-11-13 07:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fce21ac5968d 8027229: ICCE expected for >=2 maximally specific default methods. Summary: Need to process defaults for interfaces for invokespecial Reviewed-by: lfoltan, hseigel, coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 41cb10cbfb3c Author: coleenp Date: 2013-11-13 16:42 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41cb10cbfb3c 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field change Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. Reviewed-by: jrose, lfoltan, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: 4288e54fd145 Author: jwilhelm Date: 2013-10-21 18:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4288e54fd145 8026851: Remove unnecessary code in GenRemSet Summary: Removed the GenRemSet::rem_set_name() since we only have one remset. Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 3aee6bc29547 Author: jwilhelm Date: 2013-10-21 18:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3aee6bc29547 8026852: Use restricted_align_down in collector policy code Summary: Moved restricted_align_down to globalDefinitions and renamed it align_size_down_bounded Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 46d7652b223c Author: jwilhelm Date: 2013-10-21 18:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46d7652b223c 8026853: Prepare GC code for collector policy regression fix Summary: Cleanup related to the NewSize and MaxNewSize bugs Reviewed-by: tschatzl, jcoomes, ehelin ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8f07aa079343 Author: jwilhelm Date: 2013-11-01 17:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f07aa079343 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking 7057939: jmap shows MaxNewSize=4GB when Java is using parallel collector Summary: Major cleanup of the collectorpolicy classes Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp + src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMaxNewSize.java Changeset: 610be0309a79 Author: amurillo Date: 2013-11-02 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/610be0309a79 Merge ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 28674af341ac Author: tschatzl Date: 2013-11-07 15:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28674af341ac 8027756: assert(!hr->isHumongous()) failed: code root in humongous region? Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts. Reviewed-by: jmasa, tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestHumongousCodeCacheRoots.java Changeset: 40b8c6bad703 Author: jmasa Date: 2013-10-16 15:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40b8c6bad703 8024954: CMS: CMSClassUnloadingMaxInterval is not implemented correctly. This change is also part of the fix for 8024483. Reviewed-by: mgerdin, brutisso, tschatzl Contributed-by: jwha at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 592d8b01fedd Author: jmasa Date: 2013-11-08 06:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/592d8b01fedd 8024483: assertion failure: (!mirror_alive || loader_alive) failed: Reviewed-by: brutisso, tschatzl, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 3ad2b68d107e Author: jwilhelm Date: 2013-11-10 00:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3ad2b68d107e 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java Summary: Update NewSize when _initial_gen0_size is changed Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp Changeset: 236cecd9ec97 Author: jwilhelm Date: 2013-11-11 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/236cecd9ec97 8028093: Initial young size is smaller than minimum young size Summary: Remove min_gen1_size argument from adjust_gen0_sizes() Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: bde526e3667e Author: jwilhelm Date: 2013-11-11 05:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bde526e3667e Merge Changeset: 11b116661830 Author: mgerdin Date: 2013-11-11 16:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11b116661830 Merge ! src/share/vm/memory/metaspace.cpp Changeset: ee527493b36d Author: sjohanss Date: 2013-11-08 17:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee527493b36d 8027960: Assertion assert(end >= start) failed during nightly testing on solaris Summary: Needed to update _space_alignment in generation sizer to ensure correct sizing of spaces. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp Changeset: 755c423791ab Author: ehelin Date: 2013-11-14 21:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/755c423791ab Merge ! src/share/vm/prims/whitebox.cpp Changeset: e2509677809c Author: vlivanov Date: 2013-11-08 01:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2509677809c 8023037: Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp Changeset: 83c8f6f4ab09 Author: drchase Date: 2013-11-08 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83c8f6f4ab09 Merge Changeset: 1dcea64e9f00 Author: kvn Date: 2013-11-11 11:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1dcea64e9f00 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Summary: Exclude last input argument's stack slots from vector's spilling masks. Reviewed-by: iveresov ! src/share/vm/opto/matcher.cpp Changeset: 78da3894b86f Author: anoll Date: 2013-11-12 09:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78da3894b86f 8027593: performance drop with constrained codecache starting with hs25 b111 Summary: Fixed proper sweeping of small code cache sizes Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: 144b23411b51 Author: roland Date: 2013-11-12 13:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/144b23411b51 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp Summary: receiver type collected by profiling for default method may be interface Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f675976a61e7 Author: rbackman Date: 2013-11-12 13:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f675976a61e7 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post Reviewed-by: iveresov, kvn ! src/share/vm/opto/loopopts.cpp + test/compiler/intrinsics/mathexact/SplitThruPhiTest.java Changeset: b957c650babb Author: rbackman Date: 2013-11-12 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b957c650babb 8028207: assert(_outcnt==1) failed: not unique in compile.cpp Reviewed-by: iveresov, kvn ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/GVNTest.java Changeset: e6ba215af802 Author: roland Date: 2013-11-13 09:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e6ba215af802 8027631: "unexpected profiling mismatch" error with new type profiling Summary: inlined method handle calls can call methods with different signatures Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp + test/compiler/profiling/TestUnexpectedProfilingMismatch.java Changeset: 924c32982a12 Author: roland Date: 2013-11-13 01:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/924c32982a12 Merge Changeset: 6e1826d5c23e Author: roland Date: 2013-11-13 13:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e1826d5c23e 8027572: assert(r != 0) failed: invalid Summary: null classes should be expected in profiles with conflicts Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp + test/compiler/profiling/unloadingconflict/B.java + test/compiler/profiling/unloadingconflict/TestProfileConflictClassUnloading.java Changeset: e74074c34312 Author: vlivanov Date: 2013-11-14 09:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e74074c34312 8028159: C2: compiler stack overflow during inlining of @ForceInline methods Reviewed-by: roland, kvn ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: df0df745224c Author: drchase Date: 2013-11-14 15:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df0df745224c Merge Changeset: 6f206b5d258f Author: drchase Date: 2013-11-14 13:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f206b5d258f Merge ! src/share/vm/runtime/arguments.cpp Changeset: c78d517c7ea4 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c78d517c7ea4 Merge Changeset: f573d00213b7 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f573d00213b7 Added tag hs25-b59 for changeset c78d517c7ea4 ! .hgtags Changeset: 55be5aac78e2 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55be5aac78e2 Added tag jdk8-b117 for changeset f573d00213b7 ! .hgtags From lana.steuck at oracle.com Mon Nov 25 19:08:49 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:08:49 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20131125190906.CEE8762826@hg.openjdk.java.net> Changeset: c1d234d4f164 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c1d234d4f164 Added tag jdk8-b116 for changeset e757eb9aee3d ! .hgtags Changeset: e4e5069250e7 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e4e5069250e7 Added tag jdk8-b117 for changeset c1d234d4f164 ! .hgtags Changeset: 7ce7e38868d3 Author: lana Date: 2013-11-25 09:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7ce7e38868d3 Merge From pbenedict at apache.org Mon Nov 25 19:11:47 2013 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 25 Nov 2013 13:11:47 -0600 Subject: JavaDoc is indenting multiple documented annotations In-Reply-To: <52939FE6.2040104@oracle.com> References: <52939FE6.2040104@oracle.com> Message-ID: No, I didn't know such a list existed. But I do now :-) Thanks. I will send the message there. On Mon, Nov 25, 2013 at 1:07 PM, Alan Bateman wrote: > On 25/11/2013 15:43, Paul Benedict wrote: > >> On 10/16, I wrote: >> >> If you look at the current classes (b111) that have documented >>> >> annotations, >> >>> the first annotation is correctly left-aligned but all others are >>> indented >>> by one space. If this is already reported, my apologies; if not, please >>> confirm. >>> >>> Example: >>> http://download.java.net/jdk8/docs/api/java/lang/ >>> FunctionalInterface.html >>> >> This is very low-hanging fruit, but I think this is a bug. The latest >> (b116) is still indenting wrong. >> >> Have you brought this up on javadoc-dev? > > -Alan. > -- Cheers, Paul From lana.steuck at oracle.com Mon Nov 25 19:11:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 25 Nov 2013 19:11:22 +0000 Subject: hg: jdk8/tl/jdk: 20 new changesets Message-ID: <20131125191534.9FACF6282B@hg.openjdk.java.net> Changeset: bdcba4854576 Author: erikj Date: 2013-11-07 10:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdcba4854576 8027698: Platform specific jars are not being signed by the sign-jars target Reviewed-by: ihse, tbell, wetmore ! makefiles/SignJars.gmk Changeset: 295a641fc86b Author: erikj Date: 2013-11-07 14:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/295a641fc86b 8027406: JDK demos are missing source files Reviewed-by: alexsch, ihse ! makefiles/CompileDemos.gmk Changeset: 43168d403243 Author: anthony Date: 2013-11-08 20:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43168d403243 8027912: [macosx] Provide means to force the headful mode on OS X when running via ssh Summary: Bypass AquaSession check if AWT_FORCE_HEADFUL env. variable is set to TRUE Reviewed-by: anthony, art Contributed-by: David Dehaven ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 0dc0067f3b8e Author: katleman Date: 2013-11-11 15:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0dc0067f3b8e Merge Changeset: 483148bf625e Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/483148bf625e Added tag jdk8-b116 for changeset 0dc0067f3b8e ! .hgtags Changeset: f2ae86dba4bc Author: prr Date: 2013-11-13 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2ae86dba4bc 8028206: sun/java2d/cmm/ProfileOp/SetDataTest.java fails Reviewed-by: bae, jchen ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: b691a6abf9e0 Author: lana Date: 2013-11-14 23:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b691a6abf9e0 Merge Changeset: 30766f910509 Author: malenkov Date: 2013-11-01 21:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30766f910509 8026491: Typos in string literals Reviewed-by: alexsch, anthony ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/script/shell/init.js ! src/share/classes/com/sun/tools/script/shell/messages.properties ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/sample/nio/chatserver/ClientReader.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java Changeset: b8eb21e93fa7 Author: yan Date: 2013-11-07 18:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8eb21e93fa7 8025234: [javadoc] fix some errors in javax.swing.** Reviewed-by: alexsch, malenkov Contributed-by: Dmitry Ginzburg ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DesktopManager.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JTextField.java Changeset: 29f979efbabf Author: malenkov Date: 2013-11-08 14:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f979efbabf 8027648: Type of overridden property is resolved incorrectly Reviewed-by: alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java + test/java/beans/Introspector/Test8027648.java + test/java/beans/Introspector/Test8027905.java Changeset: 184f13eeed41 Author: lana Date: 2013-11-08 15:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184f13eeed41 Merge - src/share/classes/java/lang/invoke/MagicLambdaImpl.java - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties - test/java/net/NetworkInterface/MemLeakTest.java - test/jdk/lambda/vm/DefaultMethodsTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out Changeset: 4bc2414624e2 Author: leonidr Date: 2013-11-12 20:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bc2414624e2 8027972: [macosx] Provide a regression test for JDK-8007006 Reviewed-by: anthony + test/java/awt/MenuBar/8007006/bug8007006.java Changeset: 0242fce0f717 Author: serb Date: 2013-11-12 20:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0242fce0f717 8027696: Incorrect copyright header in the tests Reviewed-by: alanb, malenkov, mullan ! test/ProblemList.txt ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java ! test/com/sun/jndi/cosnaming/CNNameParser.java ! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java ! test/demo/zipfs/ZipFSTester.java ! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java ! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html ! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html ! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html ! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventQueue/MainAppContext/MainAppContext.java ! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java ! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html ! test/java/awt/FileDialog/MultipleMode/MultipleMode.html ! test/java/awt/FileDialog/RegexpFilterTest/RegexpFilterTest.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java ! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html ! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java ! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html ! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html ! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html ! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java ! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html ! test/java/awt/Frame/ShownOnPack/ShownOnPack.html ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java ! test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java ! test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html ! test/java/awt/List/SetFontTest/SetFontTest.html ! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java ! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html ! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java ! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java ! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html ! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java ! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html ! test/java/awt/PrintJob/Text/stringwidth.sh ! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java ! test/java/awt/Robot/ManualInstructions/ManualInstructions.java ! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java ! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java ! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html ! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html ! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html ! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java ! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java ! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java ! test/java/awt/Window/Grab/GrabTest.java ! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java ! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/test.html ! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html ! test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html ! test/java/awt/dnd/Button2DragTest/Button2DragTest.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java ! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html ! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java ! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html ! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java ! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html ! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html ! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html ! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java ! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java ! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html ! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html ! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java ! test/java/awt/im/4490692/bug4490692.html ! test/java/awt/im/4959409/bug4959409.html ! test/java/awt/im/JTextFieldTest.html ! test/java/awt/image/BufferedImage/TinyScale.java ! test/java/awt/image/DrawImage/EABlitTest.java ! test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java ! test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java ! test/java/awt/print/bug8023392/bug8023392.html ! test/java/awt/print/bug8023392/bug8023392.java ! test/java/beans/Introspector/6380849/beans/FirstBean.java ! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java ! test/java/beans/Introspector/6380849/beans/SecondBean.java ! test/java/beans/Introspector/6380849/beans/ThirdBean.java ! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java ! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java ! test/java/beans/Introspector/6976577/test/Accessor.java ! test/java/beans/Introspector/7122138/pack/Sub.java ! test/java/beans/Introspector/7122138/pack/Super.java ! test/java/beans/XMLEncoder/6380849/Bean.java ! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java ! test/java/io/FileInputStream/OpsAfterClose.java ! test/java/io/FileOutputStream/OpsAfterClose.java ! test/java/io/RandomAccessFile/OpsAfterClose.java ! test/java/lang/StringBuffer/BufferForwarding.java ! test/java/lang/StringBuilder/BuilderForwarding.java ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RevealDirectTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/TestCatchExceptionWithVarargs.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/lang/ref/ReferenceEnqueuePending.java ! test/java/net/URLClassLoader/closetest/build.sh ! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh ! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh ! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh ! test/java/security/cert/CertificateRevokedException/Basic.java ! test/java/util/Calendar/CldrFormatNamesTest.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/Locale/LocaleTestFmwk.java ! test/java/util/Locale/tools/EquivMapsGenerator.java ! test/java/util/TimeZone/Bug6912560.java ! test/java/util/TimeZone/CLDRDisplayNamesTest.java ! test/java/util/TimeZone/ListTimeZones.java ! test/java/util/TimeZone/OldIDMappingTest.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/SetDefaultSecurityTest.java ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.java ! test/java/util/TimeZone/TzIDOldMapping.java ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefFirst.java ! test/java/util/prefs/CheckUserPrefLater.java ! test/java/util/regex/RegExTest.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TotalInOut.java ! test/javax/imageio/plugins/gif/GifTransparencyTest.java ! test/javax/management/modelmbean/LoggingExceptionTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/print/DialogMargins.java ! test/javax/print/StreamPrintingOrientation.java ! test/javax/print/applet/AppletPrintLookup.html ! test/javax/sound/midi/File/SMPTESequence.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java ! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java ! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java ! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/Controller.java ! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java ! test/javax/sound/midi/Gervill/SoftChannel/Mono.java ! test/javax/sound/midi/Gervill/SoftChannel/Mute.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java ! test/javax/sound/midi/Gervill/SoftChannel/Omni.java ! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java ! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftChannel/Solo.java ! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java ! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java ! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java ! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Close.java ! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java ! test/javax/sound/midi/Gervill/SoftTuning/GetName.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java ! test/javax/sound/midi/Gervill/SoftTuning/Load1.java ! test/javax/sound/midi/Gervill/SoftTuning/Load2.java ! test/javax/sound/midi/Gervill/SoftTuning/Load4.java ! test/javax/sound/midi/Gervill/SoftTuning/Load5.java ! test/javax/sound/midi/Gervill/SoftTuning/Load6.java ! test/javax/sound/midi/Gervill/SoftTuning/Load7.java ! test/javax/sound/midi/Gervill/SoftTuning/Load8.java ! test/javax/sound/midi/Gervill/SoftTuning/Load9.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java ! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java ! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java ! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java ! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java ! test/javax/sound/sampled/Clip/ClipSetPos.java ! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java ! test/javax/sound/sampled/DirectAudio/bug6400879.java ! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java ! test/javax/sound/sampled/FileWriter/WriterCloseInput.java ! test/javax/swing/JCheckBox/4449413/bug4449413.html ! test/javax/swing/JColorChooser/Test4222508.html ! test/javax/swing/JColorChooser/Test4759306.html ! test/javax/swing/JColorChooser/Test4759934.html ! test/javax/swing/JColorChooser/Test4887836.html ! test/javax/swing/JColorChooser/Test6348456.html ! test/javax/swing/JColorChooser/Test6977726.html ! test/javax/swing/JComponent/4337267/bug4337267.java ! test/javax/swing/JComponent/6683775/bug6683775.java ! test/javax/swing/JEditorPane/4492274/test.html ! test/javax/swing/JEditorPane/6917744/test.html ! test/javax/swing/JEditorPane/bug4714674.java ! test/javax/swing/JFileChooser/6570445/bug6570445.java ! test/javax/swing/JFileChooser/6698013/bug6698013.html ! test/javax/swing/JFileChooser/6698013/bug6698013.java ! test/javax/swing/JFileChooser/6798062/bug6798062.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.java ! test/javax/swing/JSlider/4987336/bug4987336.html ! test/javax/swing/JSlider/6524424/bug6524424.html ! test/javax/swing/JSlider/6587742/bug6587742.html ! test/javax/swing/JSlider/6742358/bug6742358.html ! test/javax/swing/JTabbedPane/4310381/bug4310381.html ! test/javax/swing/JTree/4314199/bug4314199.html ! test/javax/swing/SwingUtilities/7170657/bug7170657.java ! test/javax/swing/border/Test4129681.html ! test/javax/swing/border/Test4243289.html ! test/javax/swing/border/Test4247606.html ! test/javax/swing/border/Test4252164.html ! test/javax/swing/border/Test4760089.html ! test/javax/swing/border/Test6910490.html ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/html/TableView/7030332/bug7030332.html ! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html ! test/sun/nio/cs/EUC_TW_OLD.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/X11CNS11643.java ! test/sun/nio/cs/X11CNS11643P1.java ! test/sun/nio/cs/X11CNS11643P2.java ! test/sun/nio/cs/X11CNS11643P3.java ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java ! test/sun/security/pkcs11/ec/TestECGenSpec.java ! test/sun/security/pkcs11/ec/TestKeyFactory.java ! test/sun/util/resources/Locale/Bug6275682.java ! test/tools/launcher/DiacriticTest.java ! test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java ! test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java Changeset: d6fe4e451dfb Author: bagiras Date: 2013-11-13 20:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6fe4e451dfb 8028283: Revert JavaDoc changes pushed for JDK-7068423 Reviewed-by: art, serb ! src/share/classes/java/awt/GraphicsDevice.java Changeset: 535f19dd3960 Author: pchelko Date: 2013-11-14 10:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/535f19dd3960 8028230: Behavior of SystemFlavorMap.getNativesForFlavor differ from that in Java 7 Reviewed-by: anthony, serb ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java + test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java Changeset: 8d17ebcef958 Author: pchelko Date: 2013-11-14 11:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d17ebcef958 8025440: [TEST_BUG] com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java failed since jdk8b108 Reviewed-by: anthony + test/com/sun/awt/SecurityWarning/CustomSecurityManager.java ! test/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java + test/java/awt/regtesthelpers/CopyClassFile.java Changeset: ca0db77f6d6b Author: lana Date: 2013-11-14 23:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca0db77f6d6b Merge Changeset: fc4ac66aa657 Author: lana Date: 2013-11-15 07:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc4ac66aa657 Merge ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/sun/awt/AppContext.java - src/share/classes/sun/management/OperatingSystemImpl.java - src/share/native/java/lang/ref/Finalizer.c - src/solaris/classes/com/sun/management/OSMBeanFactory.java - src/solaris/classes/com/sun/management/UnixOperatingSystem.java - src/solaris/native/com/sun/management/LinuxOperatingSystem.c - src/solaris/native/com/sun/management/MacosxOperatingSystem.c - src/solaris/native/com/sun/management/SolarisOperatingSystem.c - src/solaris/native/com/sun/management/UnixOperatingSystem_md.c - src/windows/classes/com/sun/management/OSMBeanFactory.java - src/windows/classes/com/sun/management/OperatingSystem.java - src/windows/native/com/sun/management/OperatingSystem_md.c ! test/ProblemList.txt - test/java/lang/management/ThreadMXBean/ThreadStateTest.java - test/java/lang/reflect/Method/DefaultMethodModeling.java - test/java/net/URLPermission/nstest/policy ! test/java/util/regex/RegExTest.java - test/lib/testlibrary/jdk/testlibrary/JdkFinder.java Changeset: 8bc258c021a3 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bc258c021a3 Added tag jdk8-b117 for changeset fc4ac66aa657 ! .hgtags Changeset: ee3c7ab60373 Author: lana Date: 2013-11-25 09:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee3c7ab60373 Merge ! make/CompileDemos.gmk ! make/SignJars.gmk ! test/ProblemList.txt ! test/tools/launcher/DiacriticTest.java From sean.mullan at oracle.com Mon Nov 25 21:06:43 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 25 Nov 2013 16:06:43 -0500 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: <5293BBE3.7040709@oracle.com> Hi Volker, The security changes look fine. I'm not crazy that we now have to maintain one additional java.security file which is the exact same as java.security-linux, but this is really an existing issue with duplicated content across the java.security files which I will try to fix early in JDK 9: https://bugs.openjdk.java.net/browse/JDK-6997010 Thanks, Sean On 11/20/2013 01:26 PM, Volker Simonis wrote: > Hi, > > this is the second review round for "8024854: Basic changes and files to > build the class library on > AIX". > The previous reviews can be found at the end of this mail in the references > section. > > I've tried to address all the comments and suggestions from the first round > and to further streamline the patch (it perfectly builds on Linux/x86_64, > Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change > compared to the first review round is the new "aix/" subdirectory which > I've now created under "jdk/src" and which contains AIX-only code. > > The webrev is against our > http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been > recently synchronised with the jdk8 master: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > > Below (and in the webrev) you can find some comments which explain the > changes to each file. In order to be able to push this big change, I need > the approval of reviewers from the lib, net, svc, 2d, awt and sec groups. > So please don't hesitate to jump at it - there are enough changes for > everybody:) > > Thank you and best regards, > Volker > > *References:* > > The following reviews have been posted so far (thanks Iris for collecting > them :) > > - Alan Bateman (lib): Initial comments (16 Sep [2]) > - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) > - Michael McMahon (net): Initial comments (20 Sept [4]) > - Steffan Larsen (svc): APPROVED (20 Sept [5]) > - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments (15 > Oct [7]) > - Sean Mullan (sec): Initial comments (26 Sept [8]) > > [2]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html > [3]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html > [4]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html > [5]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html > [6]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html > [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html > [8]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html > > > *Detailed change description:* > > The new "jdk/src/aix" subdirectory contains the following new and > AIX-specific files for now: > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileStore.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/classes/sun/nio/fs/AixFileSystemProvider.java > src/aix/classes/sun/nio/fs/AixNativeDispatcher.java > src/aix/classes/sun/tools/attach/AixAttachProvider.java > src/aix/classes/sun/tools/attach/AixVirtualMachine.java > src/aix/native/java/net/aix_close.c > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/sun/nio/fs/AixNativeDispatcher.c > src/aix/native/sun/tools/attach/AixVirtualMachine.c > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > - Added these two files for AIX relevant utility code. > - Currently these files only contain an implementation of dladdr which > is not available on AIX. > - In the first review round the existing dladdr users in the code either > called the version from the HotSpot on AIX ( > src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of > the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). This > is now not necessary any more. > > The new file layout required some small changes to the makefiles to make > them aware of the new directory locations: > > makefiles/CompileDemos.gmk > > - Add an extra argument to SetupJVMTIDemo which can be used to pass > additional source locations. > - Currently this is only used on AIX for the AIX porting utilities which > are required by hprof. > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/ServiceabilityLibraries.gmk > > - On AIX add the sources of the AIX porting utilities to the build. They > are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and > src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not available > on AIX. > > makefiles/lib/NioLibraries.gmk > > - Make the AIX-build aware of the new NIO source locations under > src/aix/native/sun/nio/. > > makefiles/lib/NetworkingLibraries.gmk > > - Make the AIX-build aware of the new aix_close.c source location under > src/aix/native/java/net/. > > src/share/bin/jli_util.h > > - Define JLI_Lseek on AIX. > > src/share/lib/security/java.security-aix > > - Provide default java.security-aix for AIX based on the latest Linux > version as suggested by Sean Mullan. > > src/share/native/common/check_code.c > > - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is > legal, but the code in check_code.c does not handles this properly. So > we wrap the two methods on AIX and return a non-NULL pointer even if we > allocate 0 bytes. > > src/share/native/sun/awt/medialib/mlib_sys.c > > - malloc always returns 8-byte aligned pointers on AIX as well. > > src/share/native/sun/awt/medialib/mlib_types.h > > - Add AIX to the list of known platforms. > > src/share/native/sun/font/layout/KernTable.cpp > > - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common > and may be defined in other headers as well as on the command line and > xlc bails out on macro redefinitions with a different value. > > src/share/native/sun/security/ec/impl/ecc_impl.h > > - Define required types and macros on AIX. > > src/solaris/back/exec_md.c > > - AIX behaves like Linux in this case so check for it in the Linux > branch. > > src/solaris/bin/java_md_solinux.c, > src/solaris/bin/java_md_solinux.h > > - On AIX LD_LIBRARY_PATH is called LIBPATH > - Always use LD_LIBRARY_PATH macro instead of using the string " > LD_LIBRARY_PATH" directly to cope with different library path names. > - Add jre/lib//jli to the standard library search path on AIX > because the AIX linker doesn't support the -rpath option. > - Replace #ifdef __linux__ by #ifndef __solaris__ because in this case, > AIX behaves like Linux. > - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from > java_md_solinux.h because the macros are redefined in the corresponding > .c files anyway. > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > - Provide basic fontconfig.propertiesfor AIX. > > src/solaris/classes/java/lang/UNIXProcess.java.aix, > src/aix/classes/sun/tools/attach/AixAttachProvider.java, > src/aix/classes/sun/tools/attach/AixVirtualMachine.java, > src/aix/native/sun/tools/attach/AixVirtualMachine.c > > - Provide AIX specific Java versions, mostly based on the corresponding > Linux versions. > > src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java > src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java > > - Detect AIX operating system and return the corresponding channel and > file system providers. > > src/solaris/classes/sun/nio/ch/Port.java > > - Add a callback function unregisterImpl(int fd) for implementations > that need special handling when fd is removed and call it from > unregister(int > fd). By default the implementation of unregisterImpl(int fd) is empty > except for the derived AixPollPort class on AIX. > > src/solaris/demo/jvmti/hprof/hprof_md.c > > - Add AIX support. AIX mostly behaves like Linux, with the one exception > that it has no dladdr functionality. > - Use the dladdr implementation from porting_aix.{c,h} on AIX. > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c > > - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory). > > src/solaris/native/common/jdk_util_md.h > > - Add AIX definitions of the ISNANF and ISNAND macros. > > src/solaris/native/java/io/io_util_md.c > > - AIX behaves like Linux in this case so check for it in the Linux > branch. > > src/solaris/native/java/lang/UNIXProcess_md.c > > - AIX behaves mostly like Solraris in this case so adjust the ifdefs > accordingly. > > src/solaris/native/java/lang/childproc.c > > - AIX does not understand '/proc/self' - it requires the real process ID > to query the proc file system for the current process. > > src/solaris/native/java/net/NetworkInterface.c > > - Add AIX support into the Linux branch because AIX mostly behaves like > AIX for IPv4. > - AIX needs a special function to enumerate IPv6 interfaces and to query > the MAC address. > - Moved the declaration of siocgifconfRequest to the beginning a the > function (as recommend by Michael McMahon) to remain C89 compatible. > > src/solaris/native/java/net/PlainSocketImpl.c > > - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the > socket is closed. The default error message is then confusing. > > src/aix/native/java/net/aix_close.c, > src/share/native/java/net/net_util.c > > - As recommended by Michael McMahon and Alan Bateman I've move an > adapted version of linux_close.c to > src/aix/native/java/net/aix_close.cbecause we also need the file and > socket wrappers on AIX. > - Compared to the Linux version, we've added the initialization of some > previously uninitialized data structures. > - Also, on AIX we don't have __attribute((constructor)) so we need to > initialize manually (from JNI_OnLoad() in > src/share/native/java/net/net_util.c. > > src/solaris/native/java/net/net_util_md.h > > - AIX needs the same workaround for I/O cancellation like Linux and > MacOSX. > > src/solaris/native/java/net/net_util_md.c > > - SO_REUSEADDR is called SO_REUSEPORT on AIX. > - On AIX we have to ignore failures due to ENOBUFS when setting the > SO_SNDBUF/SO_RCVBUF socket options. > > src/solaris/native/java/util/TimeZone_md.c > > - Currently on AIX the only way to get the platform time zone is to read > it from the TZ environment variable. > > src/solaris/native/sun/awt/awt_LoadLibrary.c > > - Use the dladdr from porting_aix.{c,h} on AIX. > > src/solaris/native/sun/awt/fontpath.c > > - Changed some macros from if !defined(__linux__) to if > defined(__solaris__) because that's their real meaning. > - Add AIX specific fontpath settings and library search paths for > libfontconfig.so. > > src/solaris/native/sun/java2d/x11/X11SurfaceData.c > > - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name > clashes (MIN and MAX are much too common and thexy are already defined > in some AIX system headers). > > src/solaris/native/sun/java2d/x11/XRBackendNative.c > > - Handle AIX like Solaris. > > src/solaris/native/sun/nio/ch/Net.c > > - Add AIX-specific includes and constant definitions. > - On AIX "socket extensions for multicast source filters" support > depends on the OS version. Check for this and throw appropriate exceptions > if it is requested but not supported. This is needed to pass > JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast > > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > > - On AIX strerror() is not thread-safe so we have to use strerror_r()instead. > - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL > for the directory stream end. Otherwise, 'errno' will contain the error > code. > - Handle some AIX corner cases for the results of the statvfs64() call. > - On AIX getgrgid_r() returns ESRCH if group does not exist. > > src/solaris/native/sun/security/pkcs11/j2secmod_md.c > > - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX. > > test/java/lang/ProcessBuilder/Basic.java > test/java/lang/ProcessBuilder/DestroyTest.java > > - Port this test to AIX and make it more robust (i.e. recognize the "C" > locale as isEnglish(), ignore VM-warnings in the output, make sure the > "grandchild" processes created by the test don't run too long (60s vs. > 6666s) because in the case of test problems these processes will pollute > the process space, make sure the test fails with an error and doesn't hang > indefinitley in the case of a problem). > > *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this > intended? > > Well, _AIX is defined in some system headers while AIX is defined by the > build system. This is already used inconsistently (i.e. __linux__ vs. LINUX) > and in general I try to be consistent with the style of the file where I > the changes are. That said, I changes most of the occurences of AIX to _AIX. > > > *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are > they supposed to be there? > > We currently don't support OS/400 (later renamed into i5/OS and currently > called IBM i) in our OpenJDK port but we do support it in our internel, SAP > JVM build. We stripped out all the extra OS/400 functionality from the port > but in some places where there is common functionality needd by both, AIX > and OS/400 the OS/400 support may still be visible in the OpenJDK port. I > don't think this is a real problem and it helps us to keep our internel > sources in sync with the OpenJDK port. That said, I think I've removed all > the references to OS/400 now. > From huizhe.wang at oracle.com Mon Nov 25 21:47:08 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 25 Nov 2013 13:47:08 -0800 Subject: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) In-Reply-To: <5290BDE0.8060102@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <528D84FC.9090802@oracle.com> <528D9809.6050208@oracle.com> <528DD386.4020902@oracle.com> <528DE500.2010808@oracle.com> <5290BDE0.8060102@oracle.com> Message-ID: <5293C55C.8000802@oracle.com> On 11/23/2013 6:38 AM, Alan Bateman wrote: > On 21/11/2013 10:48, Patrick Zhang wrote: >> Hi Alan, >> >> I have renamed "jdk8004476" to "8004476". And as Daniel's suggestion, >> add some comments to XSLTExFuncTest.java. >> >> I have updated the webrev for review. >> http://cr.openjdk.java.net/~pzhang/8027973/webrev/ > Thanks for moving it. One thing I notice in the updated webrev is that > you've commented it out in the ProblemList.txt file, I assume you > meant to remove it. > > Joe - are you going to sponsor this for Patrick? Sure. Joe > > -Alan From huizhe.wang at oracle.com Mon Nov 25 21:51:50 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 25 Nov 2013 13:51:50 -0800 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories Message-ID: <5293C676.7020304@oracle.com> Hi, This is a patch to fix an error in StAX factories' newFactory(String factoryId, ClassLoader classLoader). In the 3 step of the documentation, it should have stated that the specified ClassLoader is used. http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/webrev/ Thanks, Joe From Alan.Bateman at oracle.com Mon Nov 25 22:01:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Nov 2013 22:01:45 +0000 Subject: ArrayStoreException in Class#getAnnotations In-Reply-To: <5292324D.5080805@gmx.net> References: <5292324D.5080805@gmx.net> Message-ID: <5293C8C9.80006@oracle.com> On 24/11/2013 17:07, Philippe Marschall wrote: > Hi > > The following issue was been bothering me for a while: > When you have an annotation with a value that is an array of classes > [1] and one of those classes can't be loaded with the class loader of > defining class of the element the annotation is defined on you get a > ArrayStoreException (stack trace below). See JDK-7183985 [1]. > : > > I would like to take a moment to lament the fact that you no longer > offer fastdebug builds and no longer include sources for non-API > classes. Things like this were much easier to debug in the good old > JDK 6 days. This is double annoying when your marketing honchos are > always touting increased developer productivity. I'm curious what you mean by "no longer include source for non-API classes". If you mean src.zip then I thought it only ever contained the classes for the API classes. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-7183985 From lance.andersen at oracle.com Mon Nov 25 22:10:43 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Mon, 25 Nov 2013 17:10:43 -0500 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5293C676.7020304@oracle.com> References: <5293C676.7020304@oracle.com> Message-ID: <696EBC08-0E8E-4A5C-BEDF-E03EDF1C3676@oracle.com> +1 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 Sent from my iPad On Nov 25, 2013, at 4:51 PM, huizhe wang wrote: > Hi, > > This is a patch to fix an error in StAX factories' newFactory(String factoryId, ClassLoader classLoader). In the 3 step of the documentation, it should have stated that the specified ClassLoader is used. > > http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/webrev/ > > Thanks, > Joe From michael.fang at oracle.com Mon Nov 25 22:15:35 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Mon, 25 Nov 2013 22:15:35 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20131125221542.D8A6C62830@hg.openjdk.java.net> Changeset: abd44ea60dbe Author: mfang Date: 2013-11-21 15:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/abd44ea60dbe 8028803: jdk8 l10n resource file translation update 5 - jaxp repo Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java Changeset: e65463c785ed Author: mfang Date: 2013-11-25 14:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e65463c785ed Merge From volker.simonis at gmail.com Mon Nov 25 22:30:26 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Nov 2013 23:30:26 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <52937223.408@oracle.com> References: <52937223.408@oracle.com> Message-ID: Hi Artem, thanks a lot for your review. Please find my comments inline: On Monday, November 25, 2013, Artem Ananiev wrote: > Hi, Volker, > > just a few very minor comments about the client changes: > > 1. mlib_sys.c: the change is fine, but it makes the following comment > obsolete. You're right. I'll update the comment and try to find a corresponding reference for the AIX compiler. > 2. XRBackendNative.c: the same comment here. Again, I'll update the comment accordingly. > 3. Awt2dLibraries.gmk: $(JDK_TOPDIR)/src/aix/porting/porting_aix.c would > be better than just porting_aix.c Good catch! I think the right solution would be to add $(JDK_TOPDIR)/src/aix/porting to LIBAWT_DIRS. This will also add the directory automatically to LIBAWT_CFLAGS. I'll prepare a final webrev with all the proposed changes tomorrow. Thanks once again, Volker > > Thanks, > > Artem > > On 11/20/2013 10:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on AIX >> ". The previous >> reviews can be found at the end of this mail in the references section. >> >> I've tried to address all the comments and suggestions from the first >> round and to further streamline the patch (it perfectly builds on >> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The >> biggest change compared to the first review round is the new "aix/" >> subdirectory which I've now created under "jdk/src" and which contains >> AIX-only code. >> >> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stage >> repository which has been recently synchronised with the jdk8 master: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ >> >> Below (and in the webrev) you can find some comments which explain the >> changes to each file. In order to be able to push this big change, I >> need the approval of reviewers from the lib, net, svc, 2d, awt and sec >> groups. So please don't hesitate to jump at it - there are enough >> changes for everybody:) >> >> Thank you and best regards, >> Volker >> >> *References:* >> >> The following reviews have been posted so far (thanks Iris for >> collecting them :) >> >> - Alan Bateman (lib): Initial comments (16 Sep [2]) >> - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) >> - Michael McMahon (net): Initial comments (20 Sept [4]) >> - Steffan Larsen (svc): APPROVED (20 Sept [5]) >> - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments >> (15 Oct [7]) >> - Sean Mullan (sec): Initial comments (26 Sept [8]) >> >> [2]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001045.html >> [3]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001078.html >> [4]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001079.html >> [5]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001077.html >> [6]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001069.html >> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/ >> 003826.html >> [8]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001081.html >> >> >> *Detailed change description:* >> >> The new "jdk/src/aix" subdirectory contains the following new and >> AIX-specific files for now: >> >> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties >> src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/classes/sun/nio/fs/AixFileStore.java >> src/aix/classes/sun/nio/fs/AixFileSystem.java >> src/aix/classes/sun/nio/fs/AixFileSystemProvider.java >> src/aix/classes/sun/nio/fs/AixNativeDispatcher.java >> src/aix/classes/sun/tools/attach/AixAttachProvider.java >> src/aix/classes/sun/tools/attach/AixVirtualMachine.java >> src/aix/native/java/net/aix_close.c >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/sun/nio/fs/AixNativeDispatcher.c >> src/aix/native/sun/tools/attach/AixVirtualMachine.c >> src/aix/porting/porting_aix.c >> src/aix/porting/porting_aix.h >> >> >> src/aix/porting/porting_aix.c >> src/aix/porting/porting_aix.h >> >> * Added these two files for AIX relevant utility code. >> * Currently these files only contain an implementation of |dladdr| >> which is not available on AIX. >> * In the first review round the existing |dladdr| users in the code >> either called the version from the HotSpot on AIX >> (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private >> copy of the whole implementation >> (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not >> necessary any more. >> >> The new file layout required some small changes to the makefiles to make >> them aware of the new directory locations: >> >> >> makefiles/CompileDemos.gmk >> >> * Add an extra argument to |SetupJVMTIDemo| which can be used to pass >> additional source locations. >> * Currently this is only used on AIX for the AIX porting utilities >> which are required by hprof. >> >> >> makefiles/lib/Awt2dLibraries.gmk >> makefiles/lib/ServiceabilityLibraries.gmk >> >> * On AIX add the sources of the AIX porting utilities to the build. >> They are required by |src/solaris/native/sun/awt/awt_LoadLibrary.c| >> and |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is >> not available on AIX. >> >> >> makefiles/lib/NioLibraries.gmk >> >> * Make the AIX-build aware of the new NIO source locations under >> |src/aix/native/sun/nio/|. >> >> >> makefiles/lib/NetworkingLibraries.gmk >> >> * Make the AIX-build aware of the new |aix_close.c| source location >> under |src/aix/native/java/net/|. >> >> >> src/share/bin/jli_util.h >> >> * Define |JLI_Lseek| on AIX. >> >> >> src/share/lib/security/java.security-aix >> >> * Provide default |java.security-aix| for AIX based on the latest >> Linux version as suggested by Sean Mullan. >> >> >> src/share/native/common/check_code.c >> >> * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is >> legal, but the code in |check_code.c| does not handles this >> properly. So we wrap the two methods on AIX and return a non-NULL >> pointer even if we allocate 0 bytes. >> >> >> src/share/native/sun/awt/medialib/mlib_sys.c >> >> * |malloc| always returns 8-byte aligned pointers on AIX as well. >> >> >> src/share/native/sun/awt/medialib/mlib_types.h >> >> * Add AIX to the list of known platforms. >> >> >> src/share/native/sun/font/layout/KernTable.cpp >> >> * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is >> too common and may be defined in other headers as well as on the >> command line and |xlc| bails out on macro redefinitions with a >> different value. >> >> >> src/share/native/sun/security/ec/impl/ecc_impl.h >> >> * Define required types and macros on AIX. >> >> >> src/solaris/back/exec_md.c >> >> * AIX behaves like Linux in this case so check for it in the Linux >> branch. >> >> >> src/solaris/bin/java_md_solinux.c, >> src/solaris/bin/java_md_solinux.h >> >> * On AIX |LD_LIBRARY_PATH| is called |LIBPATH| >> * Always use |LD_LIBRARY_PATH| macro instead of using the string >> "|LD_LIBRARY_PATH|" directly to cope with different library path >> names. >> * Add |jre/lib//jli| to the standard library search path on AIX >> because the AIX linker doesn't support the |-rpath| option. >> * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in this >> case, AIX behaves like Linux. >> * Removed the definition of |JVM_DLL|, |JAVA_DLL| and >> |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are >> redefined in the corresponding |.c| files anyway. >> >> >> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties >> >> * Provide basic |fontconfig.properties|for AIX. >> >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix, >> src/aix/classes/sun/tools/attach/AixAttachProvider.java, >> src/aix/classes/sun/tools/attach/AixVirtualMachine.java, >> src/aix/native/sun/tools/attach/AixVirtualMachine.c >> >> * Provide AIX specific Java versions, mostly based on the >> corresponding Linux versions. >> >> >> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProv >> ider.java >> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java >> >> * Detect AIX operating system and return the corresponding channel and >> file system providers. >> >> >> src/solaris/classes/sun/nio/ch/Port.java >> >> * Add a callback function |unregisterImpl(int fd)| for implementations >> that need special handling when |fd| is removed and call it from >> |unregister(int fd)|. By default the implementation of >> |unregisterImpl(int fd)| is empty except for the derived >> |AixPollPort| class on AIX. >> >> >> src/solaris/demo/jvmti/hprof/hprof_md.c >> >> * Add AIX support. AIX mostly behaves like Linux, with the one >> exception that it has no |dladdr| functionality. >> * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX. >> >> >> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c >> >> * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory). >> >> >> src/solaris/native/common/jdk_util_md.h >> >> * Add AIX definitions of the |ISNANF| and |ISNAND| macros. >> >> >> src/solaris/native/java/io/io_util_md.c >> >> * AIX behaves like Linux in this case so check for it in the Linux >> branch. >> >> >> src/solaris/native/java/lang/UNIXProcess_md.c >> >> * AIX behaves mostly like Solraris in this case so adjust the ifdefs >> accordingly. >> >> >> src/solaris/native/java/lang/childproc.c >> >> * AIX does not understand '/proc/self' - it requires the real process >> ID to query the proc file system for the current process. >> >> >> src/solaris/native/java/net/NetworkInterface.c >> >> * Add AIX support into the Linux branch because AIX mostly behaves >> like AIX for IPv4. >> * AIX needs a special function to enumerate IPv6 interfaces and to >> query the MAC address. >> * Moved the declaration of |siocgifconfRequest| to the beginning a the >> function (as recommend by Michael McMahon) to remain C89 compatible. >> >> >> src/solaris/native/java/net/PlainSocketImpl.c >> >> * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL| if >> the socket is closed. The default error message is then confusing. >> >> >> src/aix/native/java/net/aix_close.c, >> src/share/native/java/net/net_util.c >> >> * As recommended by Michael McMahon and Alan Bateman I've move an >> adapted version of |linux_close.c| to >> |src/aix/native/java/net/aix_close.c| because we also need the file >> and socket wrappers on AIX. >> * Compared to the Linux version, we've added the initialization of >> some previously uninitialized data structures. >> * Also, on AIX we don't have |__attribute((constructor))| so we need >> to initialize manually (from |JNI_OnLoad()| in >> |src/share/native/java/net/net_util.c|. >> >> >> src/solaris/native/java/net/net_util_md.h >> >> * AIX needs the same workaround for I/O cancellation like Linux and >> MacOSX. >> >> >> src/solaris/native/java/net/net_util_md.c >> >> * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX. >> * On AIX we have to ignore failures due to |ENOBUFS| when setting the >> |SO_SNDBUF|/|SO_RCVBUF| socket options. >> >> >> src/solaris/native/java/util/TimeZone_md.c >> >> * Currently on AIX the only way to get the platform time zone is to >> read it from the |TZ| environment variable. >> >> >> src/solaris/native/sun/awt/awt_LoadLibrary.c >> >> * Use the |dladdr| from |porting_aix.{c,h}| on AIX. >> >> >> src/solaris/native/sun/awt/fontpath.c >> >> * Changed some macros from |if !defined(__linux__)| to |if >> defined(__solaris__)| because that's their real meaning. >> * Add AIX specific fontpath settings and library search paths for >> |libfontconfig.so|. >> >> >> src/solaris/native/sun/java2d/x11/X11SurfaceData.c >> >> * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to >> avoid name clashes (|MIN| and |MAX| are much too common and thexy >> are already defined in some AIX system headers). >> >> >> src/solaris/native/sun/java2d/x11/XRBackendNative.c >> >> * Handle AIX like Solaris. >> >> >> src/solaris/native/sun/nio/ch/Net.c >> >> * Add AIX-specific includes and constant definitions. >> * On AIX "socket extensions for multicast source filters" support >> depends on the OS version. Check for this and throw appropriate >> exceptions if it is requested but not supported. This is needed to >> pass >> JCK-api/java_nio/channels/DatagramChannel/ >> DatagramChannel.html#Multicast >> >> >> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c >> >> * On AIX |strerror()| is not thread-safe so we have to use >> |strerror_r()| instead. >> * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to >> NULL for the directory stream end. Otherwise, 'errno' will contain >> the error code. >> * Handle some AIX corner cases for the results of the |statvfs64()| >> call. >> * On AIX |getgrgid_r()| returns ESRCH if group does not exist. >> >> >> src/solaris/native/sun/security/pkcs11/j2secmod_md.c >> >> * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX. >> >> >> test/java/lang/ProcessBuilder/Basic.java >> test/java/lang/ProcessBuilder/DestroyTest.java >> >> * Port this test to AIX and make it more robust (i.e. recognize the >> "C" locale as |isEnglish()|, ignore VM-warnings in the output, make >> sure the "grandchild" processes created by the test don't run too >> long (60s vs. 6666s) because in the case of test problems these >> processes will pollute the process space, make sure the test fails >> with an error and doesn't hang indefinitley in the case of a problem). >> >> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this >> intended? >> >> Well, |_AIX| is defined in some system headers while |AIX| is defined by >> the build system. This is already used inconsistently (i.e. |__linux__| >> vs. |LINUX|) and in general I try to be consistent with the style of the >> file where I the changes are. That said, I changes most of the >> occurences of |AIX| to |_AIX|. >> >> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are >> they supposed to be there? >> >> We currently don't support OS/400 (later renamed into i5/OS and >> currently called IBM i) in our OpenJDK port but we do support it in our >> internel, SAP JVM build. We stripped out all the extra OS/400 >> functionality from the port but in some places where there is common >> functionality needd by both, AIX and OS/400 the OS/400 support may still >> be visible in the OpenJDK port. I don't think this is a real problem and >> it helps us to keep our internel sources in sync with the OpenJDK port. >> That said, I think I've removed all the references to OS/400 now. >> >> >> From volker.simonis at gmail.com Mon Nov 25 22:35:33 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Nov 2013 23:35:33 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <5293BBE3.7040709@oracle.com> References: <5293BBE3.7040709@oracle.com> Message-ID: Hi Sean, thanks a lot for you review. Please let me know once you start working on 6997010 so I can update the corresponding AIX file accordingly. Regards, Volker On Monday, November 25, 2013, Sean Mullan wrote: > Hi Volker, > > The security changes look fine. I'm not crazy that we now have to maintain > one additional java.security file which is the exact same as > java.security-linux, but this is really an existing issue with duplicated > content across the java.security files which I will try to fix early in JDK > 9: https://bugs.openjdk.java.net/browse/JDK-6997010 > > Thanks, > Sean > > On 11/20/2013 01:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on >> AIX". >> The previous reviews can be found at the end of this mail in the >> references >> section. >> >> I've tried to address all the comments and suggestions from the first >> round >> and to further streamline the patch (it perfectly builds on Linux/x86_64, >> Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change >> compared to the first review round is the new "aix/" subdirectory which >> I've now created under "jdk/src" and which contains AIX-only code. >> >> The webrev is against our >> http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been >> recently synchronised with the jdk8 master: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ >> >> Below (and in the webrev) you can find some comments which explain the >> changes to each file. In order to be able to push this big change, I need >> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups. >> So please don't hesitate to jump at it - there are enough changes for >> everybody:) >> >> Thank you and best regards, >> Volker >> >> *References:* >> >> The following reviews have been posted so far (thanks Iris for collecting >> them :) >> >> - Alan Bateman (lib): Initial comments (16 Sep [2]) >> - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) >> - Michael McMahon (net): Initial comments (20 Sept [4]) >> - Steffan Larsen (svc): APPROVED (20 Sept [5]) >> - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments (15 >> Oct [7]) >> - Sean Mullan (sec): Initial comments (26 Sept [8]) >> >> [2]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001045.html >> [3]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001078.html >> [4]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001079.html >> [5]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001077.html >> [6]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001069.html >> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/ >> 003826.html >> [8]: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001081.html >> >> >> *Detailed change description:* >> >> The new "jdk/src/aix" subdirectory contains the following new and >> AIX-specific files for now: >> >> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties >> src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/classes/sun/nio/fs/AixFileStore.java >> src/aix/classes/sun/nio/fs/AixFileSystem.java >> src/aix/classes/sun/nio/fs/AixFileSystemProvider.java >> src/aix/classes/sun/nio/fs/AixNativeDispatcher.java >> src/aix/classes/sun/tools/attach/AixAttachProvider.java >> src/aix/classes/sun/tools/attach/AixVirtualMachine.java >> src/aix/native/java/net/aix_close.c >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/sun/nio/fs/AixNativeDispatcher.c >> src/aix/native/sun/tools/attach/AixVirtualMachine.c >> src/aix/porting/porting_aix.c >> src/aix/porting/porting_aix.h >> >> src/aix/porting/porting_aix.c >> src/aix/porting/porting_aix.h >> >> - Added these two files for AIX relevant utility code. >> - Currently these files only contain an implementation of dladdr which >> is not available on AIX. >> - In the first review round the existing dladdr users in the code >> either >> called the version from the HotSpot on AIX ( >> src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy >> of >> the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). >> This >> is now not necessary any more. >> >> The new file layout required some small changes to the makefiles to make >> them aware of the new directory locations: >> >> makefiles/CompileDemos.gmk >> >> - Add an extra argument to SetupJVMTIDemo which can be used to pass >> additional source locations. >> - Currently this is only used on AIX for the AIX porting utilities >> which >> are required by hprof. >> >> makefiles/lib/Awt2dLibraries.gmk >> makefiles/lib/ServiceabilityLibraries.gmk >> >> - On AIX add the sources of the AIX porting utilities to the build. >> They >> are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and >> src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not >> available >> on AIX. >> >> makefiles/lib/NioLibraries.gmk >> >> - Make the AIX-build aware of the new NIO source locations under >> src/aix/native/sun/nio/. >> >> makefiles/lib/NetworkingLibraries.gmk >> >> - Make the AIX-build aware of the new aix_close.c source location >> under >> src/aix/native/java/net/. >> >> src/share/bin/jli_util.h >> >> - Define JLI_Lseek on AIX. >> >> src/share/lib/security/java.security-aix >> >> - Provide default java.security-aix for AIX based on the latest Linux >> version as suggested by Sean Mullan. >> >> src/share/native/common/check_code.c >> >> - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is >> legal, but the code in check_code.c does not handles this properly. So >> we wrap the two methods on AIX and return a non-NULL pointer even if >> we >> allocate 0 bytes. >> >> src/share/native/sun/awt/medialib/mlib_sys.c >> >> - malloc always returns 8-byte aligned pointers on AIX as well. >> >> src/share/native/sun/awt/medialib/mlib_types.h >> >> - Add AIX to the list of known platforms. >> >> src/share/native/sun/font/layout/KernTable.cpp >> >> - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too >> common >> and may be defined in other headers as well as on the command line and >> xlc bails out on macro redefinitions with a different value. >> >> src/share/native/sun/security/ec/impl/ecc_impl.h >> >> - Define required types and macros on AIX. >> >> src/solaris/back/exec_md.c >> >> - AIX behaves like Linux in this case so check for it in the Linux >> branch. >> >> src/solaris/bin/java_md_solinux.c, >> src/solaris/bin/java_md_solinux.h >> >> - On AIX LD_LIBRARY_PATH is called LIBPATH >> - Always use LD_LIBRARY_PATH macro instead of using the string " >> LD_LIBRARY_PATH" directly to cope with different library path names. >> - Add jre/lib//jli to the standard library search path on AIX >> because the AIX linker doesn't support the -rpath option. >> - Replace #ifdef __linux__ by #ifndef __solaris__ because in this >> case, >> AIX behaves like Linux. >> - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from >> java_md_solinux.h because the macros are redefined in the >> corresponding >> .c files anyway. >> >> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties >> >> - Provide basic fontconfig.propertiesfor AIX. >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix, >> src/aix/classes/sun/tools/attach/AixAttachProvider.java, >> src/aix/classes/sun/tools/attach/AixVirtualMachine.java, >> src/aix/native/sun/tools/attach/AixVirtualMachine.c >> >> - Provide AIX specific Java versions, mostly based on the >> corresponding >> Linux versions. >> >> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java >> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java >> >> - Detect AIX operating system and return the corresponding channel and >> file system providers. >> >> src/solaris/classes/sun/nio/ch/Port.java >> >> - Add a callback function unregisterImpl(int fd) for implementations >> that need special handling when fd is removed and call it from >> unregister(int >> fd). By default the implementation of unregisterImpl(int fd) is empty >> except for the derived AixPollPort class on AIX. >> >> src/solaris/demo/jvmti/hprof/hprof_md.c >> >> - Add AIX support. AIX mostly behaves like Linux, with the one >> exception >> that it has no dladdr functionality. >> - Use the dladdr implementation from porting_aix.{c,h} on AIX. >> >> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c >> >> - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory). >> >> src/solaris/native/common/jdk_util_md.h >> >> - Add AIX definitions of the ISNANF and ISNAND macros. >> >> src/solaris/native/java/io/io_util_md.c >> >> - AIX behaves like Linux in this case so check for it in the Linux >> branch. >> >> src/solaris/native/java/lang/UNIXProcess_md.c >> >> - AIX behaves mostly like Solraris in this case so adjust the ifdefs >> accordingly. >> >> src/solaris/native/java/lang/childproc.c >> >> - AIX does not understand '/proc/self' - it requires the real process >> ID >> to query the proc file system for the current process. >> >> src/solaris/native/java/net/NetworkInterface.c >> >> - Add AIX support into the Linux branch because AIX mostly behaves >> like >> AIX for IPv4. >> - AIX needs a special function to enumerate IPv6 interfaces and to >> query >> the MAC address. >> - Moved the declaration of siocgifconfRequest to the beginning a the >> function (as recommend by Michael McMahon) to remain C89 compatible. >> >> src/solaris/native/java/net/PlainSocketImpl.c >> >> - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the >> socket is closed. The default error message is then confusing. >> >> src/aix/native/java/net/aix_close.c, >> src/share/native/java/net/net_util.c >> >> - As recommended by Michael McMahon and Alan Bateman I've move an >> adapted version of linux_close.c to >> src/aix/native/java/net/aix_close.cbecause we also need the file and >> socket wrappers on AIX. >> - Compared to the Linux version, we've added the initialization of >> some >> previously uninitialized data structures. >> - Also, on AIX we don't have __attribute((constructor)) so we need to >> initialize manually (from JNI_OnLoad() in >> src/share/native/java/net/net_util.c. >> >> src/solaris/native/java/net/net_util_md.h >> >> - AIX needs the same workaround for I/O cancellation like Linux and >> MacOSX. >> >> src/solaris/native/java/net/net_util_md.c >> >> - SO_REUSEADDR is called SO_REUSEPORT on AIX. >> - On AIX we have to ignore failures due to ENOBUFS when setting the >> SO_SNDBUF/SO_RCVBUF socket options. >> >> src/solaris/native/java/util/TimeZone_md.c >> >> - Currently on AIX the only way to get the platform time zone is to >> read >> it from the TZ environment variable. >> >> src/solaris/native/sun/awt/awt_LoadLibrary.c >> >> - Use the dladdr from porting_aix.{c,h} on AIX. >> >> src/solaris/native/sun/awt/fontpath.c >> >> - Changed some macros from if !defined(__linux__) to if >> defined(__solaris__) because that's their real meaning. >> - Add AIX specific fontpath settings and library search paths for >> libfontconfig.so. >> >> src/solaris/native/sun/java2d/x11/X11SurfaceData.c >> >> - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name >> clashes (MIN and MAX are much too common and thexy are already defined >> in some AIX system headers). >> >> src/solaris/native/sun/java2d/x11/XRBackendNative.c >> >> - Handle AIX like Solaris. >> >> src/solaris/native/sun/nio/ch/Net.c >> >> - Add AIX-specific includes and constant definitions. >> - On AIX "socket extensions for multicast source filters" support >> depends on the OS version. Check for this and throw appropriate >> exceptions >> if it is requested but not supported. This is needed to pass >> JCK-api/java_nio/channels/DatagramChannel/ >> DatagramChannel.html#Multicast >> >> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c >> >> - On AIX strerror() is not thread-safe so we have to use >> strerror_r()instead. >> - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to >> NULL >> for the directory stream end. Otherwise, 'errno' will contain the >> error >> code. >> - Handle some AIX corner cases for the results of the statvfs64() >> call. >> - On AIX getgrgid_r() returns ESRCH if group does not exist. >> >> src/solaris/native/sun/security/pkcs11/j2secmod_md.c >> >> - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX. >> >> test/java/lang/ProcessBuilder/Basic.java >> test/java/lang/ProcessBuilder/DestroyTest.java >> >> - Port this test to AIX and make it more robust (i.e. recognize the >> "C" >> locale as isEnglish(), ignore VM-warnings in the output, make sure the >> "grandchild" processes created by the test don't run too long (60s vs. >> 6666s) because in the case of test problems these processes will >> pollute >> the process space, make sure the test fails with an error and doesn't >> hang >> indefinitley in the case of a problem). >> >> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this >> intended? >> >> Well, _AIX is defined in some system headers while AIX is defined by the >> build system. This is already used inconsistently (i.e. __linux__ vs. >> LINUX) >> and in general I try to be consistent with the style of the file where I >> the changes are. That said, I changes most of the occurences of AIX to >> _AIX. >> >> >> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are >> they supposed to be there? >> >> We currently don't support OS/400 (later renamed into i5/OS and currently >> called IBM i) in our OpenJDK port but we do support it in our internel, >> SAP >> JVM build. We stripped out all the extra OS/400 functionality from the >> port >> but in some places where there is common functionality needd by both, AIX >> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I >> don't think this is a real problem and it helps us to keep our internel >> sources in sync with the OpenJDK port. That said, I think I've removed all >> the references to OS/400 now. >> >> > From valerie.peng at oracle.com Mon Nov 25 22:49:50 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Mon, 25 Nov 2013 22:49:50 +0000 Subject: hg: jdk8/tl/jdk: 7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init() Message-ID: <20131125225013.32D1362839@hg.openjdk.java.net> Changeset: 8d5a9245b9ca Author: valeriep Date: 2013-11-25 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d5a9245b9ca 7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init() Summary: Add key length checks to P11Signature class Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/Token.java + test/sun/security/pkcs11/Signature/TestDSAKeyLength.java From philip.race at oracle.com Mon Nov 25 23:24:15 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Nov 2013 15:24:15 -0800 Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: <5293DC1F.4060205@oracle.com> Hi, I see you've already received a ton of good feedback on this v2. I have just a few things to add. I don't know what symlinks might exist on AIX but it seems odd to me that you have :- 138 static char *fullAixFontPath[] = { 139 "/usr/lpp/X11/lib/X11/fonts/Type1", .. but the paths in the new file aix.fontconfig.properties look like this :- /usr/lib/X11/fonts/Type1/cour.pfa Also for the build to pick up a file called *src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties *it seems like you should have added a section to handle this path to jdk/makefiles/gendata/GenDataFontConfig.gmk That seems to be where the new build handles such files. Are you seeing the .bfc and .src files created ? At runtime it'll get picked up so so long as System.getProperty("os.name") returns "aix" (all lower-case) so I think that's OK. Its the build time part I'd expect to see but don't. -phil. On 11/20/2013 10:26 AM, Volker Simonis wrote: > Hi, > > this is the second review round for "8024854: Basic changes and files > to build the class library on AIX > ". The previous > reviews can be found at the end of this mail in the references section. > > I've tried to address all the comments and suggestions from the first > round and to further streamline the patch (it perfectly builds on > Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). > The biggest change compared to the first review round is the new > "aix/" subdirectory which I've now created under "jdk/src" and which > contains AIX-only code. > > The webrev is against our > http://hg.openjdk.java.net/ppc-aix-port/stage repository which has > been recently synchronised with the jdk8 master: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > > > Below (and in the webrev) you can find some comments which explain the > changes to each file. In order to be able to push this big change, I > need the approval of reviewers from the lib, net, svc, 2d, awt and sec > groups. So please don't hesitate to jump at it - there are enough > changes for everybody:) > > Thank you and best regards, > Volker > > *References:* > > The following reviews have been posted so far (thanks Iris for > collecting them :) > > - Alan Bateman (lib): Initial comments (16 Sep [2]) > - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) > - Michael McMahon (net): Initial comments (20 Sept [4]) > - Steffan Larsen (svc): APPROVED (20 Sept [5]) > - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments > (15 Oct [7]) > - Sean Mullan (sec): Initial comments (26 Sept [8]) > > [2]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html > [3]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html > [4]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html > [5]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html > [6]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html > [7]: > http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html > [8]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html > > > *Detailed change description:* > > The new "jdk/src/aix" subdirectory contains the following new and > AIX-specific files for now: > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileStore.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/classes/sun/nio/fs/AixFileSystemProvider.java > src/aix/classes/sun/nio/fs/AixNativeDispatcher.java > src/aix/classes/sun/tools/attach/AixAttachProvider.java > src/aix/classes/sun/tools/attach/AixVirtualMachine.java > src/aix/native/java/net/aix_close.c > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/sun/nio/fs/AixNativeDispatcher.c > src/aix/native/sun/tools/attach/AixVirtualMachine.c > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > * Added these two files for AIX relevant utility code. > * Currently these files only contain an implementation of |dladdr| > which is not available on AIX. > * In the first review round the existing |dladdr| users in the code > either called the version from the HotSpot on AIX > (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private > copy of the whole implementation > (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not > necessary any more. > > The new file layout required some small changes to the makefiles to > make them aware of the new directory locations: > > > makefiles/CompileDemos.gmk > > * Add an extra argument to |SetupJVMTIDemo| which can be used to > pass additional source locations. > * Currently this is only used on AIX for the AIX porting utilities > which are required by hprof. > > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/ServiceabilityLibraries.gmk > > * On AIX add the sources of the AIX porting utilities to the build. > They are required by > |src/solaris/native/sun/awt/awt_LoadLibrary.c| and > |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is not > available on AIX. > > > makefiles/lib/NioLibraries.gmk > > * Make the AIX-build aware of the new NIO source locations under > |src/aix/native/sun/nio/|. > > > makefiles/lib/NetworkingLibraries.gmk > > * Make the AIX-build aware of the new |aix_close.c| source location > under |src/aix/native/java/net/|. > > > src/share/bin/jli_util.h > > * Define |JLI_Lseek| on AIX. > > > src/share/lib/security/java.security-aix > > * Provide default |java.security-aix| for AIX based on the latest > Linux version as suggested by Sean Mullan. > > > src/share/native/common/check_code.c > > * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which > is legal, but the code in |check_code.c| does not handles this > properly. So we wrap the two methods on AIX and return a non-NULL > pointer even if we allocate 0 bytes. > > > src/share/native/sun/awt/medialib/mlib_sys.c > > * |malloc| always returns 8-byte aligned pointers on AIX as well. > > > src/share/native/sun/awt/medialib/mlib_types.h > > * Add AIX to the list of known platforms. > > > src/share/native/sun/font/layout/KernTable.cpp > > * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is > too common and may be defined in other headers as well as on the > command line and |xlc| bails out on macro redefinitions with a > different value. > > > src/share/native/sun/security/ec/impl/ecc_impl.h > > * Define required types and macros on AIX. > > > src/solaris/back/exec_md.c > > * AIX behaves like Linux in this case so check for it in the Linux > branch. > > > src/solaris/bin/java_md_solinux.c, > src/solaris/bin/java_md_solinux.h > > * On AIX |LD_LIBRARY_PATH| is called |LIBPATH| > * Always use |LD_LIBRARY_PATH| macro instead of using the string > "|LD_LIBRARY_PATH|" directly to cope with different library path > names. > * Add |jre/lib//jli| to the standard library search path on > AIX because the AIX linker doesn't support the |-rpath| option. > * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in > this case, AIX behaves like Linux. > * Removed the definition of |JVM_DLL|, |JAVA_DLL| and > |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are > redefined in the corresponding |.c| files anyway. > > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > * Provide basic |fontconfig.properties|for AIX. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix, > src/aix/classes/sun/tools/attach/AixAttachProvider.java, > src/aix/classes/sun/tools/attach/AixVirtualMachine.java, > src/aix/native/sun/tools/attach/AixVirtualMachine.c > > * Provide AIX specific Java versions, mostly based on the > corresponding Linux versions. > > > src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java > src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java > > * Detect AIX operating system and return the corresponding channel > and file system providers. > > > src/solaris/classes/sun/nio/ch/Port.java > > * Add a callback function |unregisterImpl(int fd)| for > implementations that need special handling when |fd| is removed > and call it from |unregister(int fd)|. By default the > implementation of |unregisterImpl(int fd)| is empty except for the > derived |AixPollPort| class on AIX. > > > src/solaris/demo/jvmti/hprof/hprof_md.c > > * Add AIX support. AIX mostly behaves like Linux, with the one > exception that it has no |dladdr| functionality. > * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX. > > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c > > * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory). > > > src/solaris/native/common/jdk_util_md.h > > * Add AIX definitions of the |ISNANF| and |ISNAND| macros. > > > src/solaris/native/java/io/io_util_md.c > > * AIX behaves like Linux in this case so check for it in the Linux > branch. > > > src/solaris/native/java/lang/UNIXProcess_md.c > > * AIX behaves mostly like Solraris in this case so adjust the ifdefs > accordingly. > > > src/solaris/native/java/lang/childproc.c > > * AIX does not understand '/proc/self' - it requires the real > process ID to query the proc file system for the current process. > > > src/solaris/native/java/net/NetworkInterface.c > > * Add AIX support into the Linux branch because AIX mostly behaves > like AIX for IPv4. > * AIX needs a special function to enumerate IPv6 interfaces and to > query the MAC address. > * Moved the declaration of |siocgifconfRequest| to the beginning a > the function (as recommend by Michael McMahon) to remain C89 > compatible. > > > src/solaris/native/java/net/PlainSocketImpl.c > > * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL| > if the socket is closed. The default error message is then confusing. > > > src/aix/native/java/net/aix_close.c, > src/share/native/java/net/net_util.c > > * As recommended by Michael McMahon and Alan Bateman I've move an > adapted version of |linux_close.c| to > |src/aix/native/java/net/aix_close.c| because we also need the > file and socket wrappers on AIX. > * Compared to the Linux version, we've added the initialization of > some previously uninitialized data structures. > * Also, on AIX we don't have |__attribute((constructor))| so we need > to initialize manually (from |JNI_OnLoad()| in > |src/share/native/java/net/net_util.c|. > > > src/solaris/native/java/net/net_util_md.h > > * AIX needs the same workaround for I/O cancellation like Linux and > MacOSX. > > > src/solaris/native/java/net/net_util_md.c > > * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX. > * On AIX we have to ignore failures due to |ENOBUFS| when setting > the |SO_SNDBUF|/|SO_RCVBUF| socket options. > > > src/solaris/native/java/util/TimeZone_md.c > > * Currently on AIX the only way to get the platform time zone is to > read it from the |TZ| environment variable. > > > src/solaris/native/sun/awt/awt_LoadLibrary.c > > * Use the |dladdr| from |porting_aix.{c,h}| on AIX. > > > src/solaris/native/sun/awt/fontpath.c > > * Changed some macros from |if !defined(__linux__)| to |if > defined(__solaris__)| because that's their real meaning. > * Add AIX specific fontpath settings and library search paths for > |libfontconfig.so|. > > > src/solaris/native/sun/java2d/x11/X11SurfaceData.c > > * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to > avoid name clashes (|MIN| and |MAX| are much too common and thexy > are already defined in some AIX system headers). > > > src/solaris/native/sun/java2d/x11/XRBackendNative.c > > * Handle AIX like Solaris. > > > src/solaris/native/sun/nio/ch/Net.c > > * Add AIX-specific includes and constant definitions. > * On AIX "socket extensions for multicast source filters" support > depends on the OS version. Check for this and throw appropriate > exceptions if it is requested but not supported. This is needed to > pass > JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast > > > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > > * On AIX |strerror()| is not thread-safe so we have to use > |strerror_r()| instead. > * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to > NULL for the directory stream end. Otherwise, 'errno' will contain > the error code. > * Handle some AIX corner cases for the results of the |statvfs64()| > call. > * On AIX |getgrgid_r()| returns ESRCH if group does not exist. > > > src/solaris/native/sun/security/pkcs11/j2secmod_md.c > > * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX. > > > test/java/lang/ProcessBuilder/Basic.java > test/java/lang/ProcessBuilder/DestroyTest.java > > * Port this test to AIX and make it more robust (i.e. recognize the > "C" locale as |isEnglish()|, ignore VM-warnings in the output, > make sure the "grandchild" processes created by the test don't run > too long (60s vs. 6666s) because in the case of test problems > these processes will pollute the process space, make sure the test > fails with an error and doesn't hang indefinitley in the case of a > problem). > > *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this > intended? > > Well, |_AIX| is defined in some system headers while |AIX| is defined > by the build system. This is already used inconsistently (i.e. > |__linux__| vs. |LINUX|) and in general I try to be consistent with > the style of the file where I the changes are. That said, I changes > most of the occurences of |AIX| to |_AIX|. > > *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, > are they supposed to be there? > > We currently don't support OS/400 (later renamed into i5/OS and > currently called IBM i) in our OpenJDK port but we do support it in > our internel, SAP JVM build. We stripped out all the extra OS/400 > functionality from the port but in some places where there is common > functionality needd by both, AIX and OS/400 the OS/400 support may > still be visible in the OpenJDK port. I don't think this is a real > problem and it helps us to keep our internel sources in sync with the > OpenJDK port. That said, I think I've removed all the references to > OS/400 now. > > From huizhe.wang at oracle.com Tue Nov 26 00:58:34 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 26 Nov 2013 00:58:34 +0000 Subject: hg: jdk8/tl/jdk: 8027973: javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) Message-ID: <20131126005849.E0B5E62846@hg.openjdk.java.net> Changeset: 0bf3a58a1783 Author: joehw Date: 2013-11-25 16:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bf3a58a1783 8027973: javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) Reviewed-by: alanb, dfuchs, joehw Contributed-by: patrick.zhang at oracle.com + test/javax/xml/jaxp/transform/8004476/SecureProcessingTest.xml + test/javax/xml/jaxp/transform/8004476/TestBase.java + test/javax/xml/jaxp/transform/8004476/XPathExFuncTest.java + test/javax/xml/jaxp/transform/8004476/XSLTExFuncTest.java + test/javax/xml/jaxp/transform/8004476/tokenize.xml + test/javax/xml/jaxp/transform/8004476/tokenize.xsl - test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml - test/javax/xml/jaxp/transform/jdk8004476/TestBase.java - test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java - test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java - test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml - test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl From john.r.rose at oracle.com Tue Nov 26 01:29:22 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Nov 2013 17:29:22 -0800 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: On Nov 25, 2013, at 1:49 AM, Paul Sandoz wrote: > Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? Unsafe is used everywhere, including from some of the preloaded classes. Thus it will be preloaded even if it is not on the JVM's preload list, so there's no harm in naming it this way from the JVM. And thus we get to the Naming Question... As a class, Unsafe is a stable, non-public name space, and is (unusually) tightly coupled to the JVM. It has no other qualifications specific to this new use. We don't already have "sun.misc.InternalMethods", but it's not something we want to invent, just for this method. David has noted that introducing a new class would complicate backporting. ? John From jonathan.gibbons at oracle.com Tue Nov 26 01:45:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 26 Nov 2013 01:45:23 +0000 Subject: hg: jdk8/tl/langtools: 8028318: [doclint] doclint will reject existing user-written doc comments using custom tags that follow the recommended rules Message-ID: <20131126014526.64AEE62847@hg.openjdk.java.net> Changeset: a78f51d6bd5e Author: jjg Date: 2013-11-25 17:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a78f51d6bd5e 8028318: [doclint] doclint will reject existing user-written doc comments using custom tags that follow the recommended rules Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! test/tools/doclint/CustomTagTest.java ! test/tools/doclint/CustomTagTest.out ! test/tools/doclint/CustomTagTestWithOption.out From david.holmes at oracle.com Tue Nov 26 02:18:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 12:18:59 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: <52940513.6010503@oracle.com> On 26/11/2013 11:29 AM, John Rose wrote: > On Nov 25, 2013, at 1:49 AM, Paul Sandoz wrote: > >> Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? > > Unsafe is used everywhere, including from some of the preloaded classes. Thus it will be preloaded even if it is not on the JVM's preload list, so there's no harm in naming it this way from the JVM. Not quite. Unsafe is needed during system class initialization, but it is not needed during class pre-loading. So this change will be loading it earlier, but that is harmless AFAICS. Non of the other pre-loaded classes are really suitable in any case. > And thus we get to the Naming Question... > > As a class, Unsafe is a stable, non-public name space, and is (unusually) tightly coupled to the JVM. It has no other qualifications specific to this new use. > > We don't already have "sun.misc.InternalMethods", but it's not something we want to invent, just for this method. David has noted that introducing a new class would complicate backporting. We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? Overall this approach kind of makes me cringe anyway. Cheers, David H. > ? John > From stuart.marks at oracle.com Tue Nov 26 02:36:19 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 25 Nov 2013 18:36:19 -0800 Subject: =?UTF-8?B?562U5aSNOiBSRlIgZm9yIEpESy03MTkwMTA2IFJNSSBiZW5jaG0=?= =?UTF-8?B?YXJrIGZhaWxzIGludGVybWl0dGVudGx5IGJlY2F1c2Ugb2YgdXNlIG9mIGZpeGU=?= =?UTF-8?B?ZCBwb3J0?= In-Reply-To: <528D2E57.1070001@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> <09ed5de7-e061-45b3-9f09-936a624dce1b@default> <528D2E57.1070001@oracle.com> Message-ID: <52940923.8000903@oracle.com> Hi Tristan, Finally getting back to this. Again, sorry for the delay. The changes look much better now. I've listed a bunch of items below, but they're all comparatively minor, even nitpicky. But there are a few things that should be cleaned up before we integrate this. Items listed below. ** bench/serial/Main.java - The description should simply be "The Serialization benchmark test". This test has nothing to do with RMI, even though it's under the java/rmi hierarchy in the filesystem. - parseArgs() uses strings-in-switch! Good, but put "break" on its own line instead of following the close-brace of the catch clause. (rmi/Main.java doesn't have this issue.) ** bench/rmi/Main.java - Imports of java.util.logging.Level and Logger are unused? - Missing "-server" line from usage(). - Interesting use of enum. Note by convention an enum is like a class and names are in mixed case, thus use OutputFormat instead of OUTPUT_FORMAT. Also note that the enum doesn't buy much, at least in terms of lines of code, since the enum declaration and enum instance overrides add about as much code as the case statement that got removed from setupReporter(). It does buy a bit of type-safety, though, so might as well leave it in. - Enum instance HTML should be on a new line, like XML. - Reflection code can be chained instead of declaring several locals. This is mainly a matter of taste, but to my eye it's cleaner. The main advantage is avoiding the need to come up with names for intermediate locals. For example: port = (int) Class.forName("TestLibrary") .getMethod("getUnusedRandomPort") .invoke(null); - Catch clause at 389 can be of ReflectiveOperationException. This covers everything except IllegalArgumentException, which is unchecked, so you don't need to catch it. (Not sure why Method.invoke is declared to throw IllegalArgumentException, since generally only checked exceptions are declared in the throws clause.) - Line 416, no need to mention RMISecurityManager in a comment, just make the change to use SecurityManager. - It's kind of surprising that TEST_SRC_PATH appends the file separator to the test.src property. At line 241 test.src has to be fetched again to use it without the file separator. - Line 234, instead of the java.home property, use the test.jdk property. This will use the JDK under test instead of the JDK that's running jtreg. In practice it's unclear whether this makes any actual difference today, but it's good to try to keep this separation. Also, use file separators here instead of appending "/bin/java". (Hmmm. I observe that the RMI testlibrary invokes JVM subprocesses using java.home.) Thanks, s'marks On 11/20/13 1:49 PM, Stuart Marks wrote: > Hi, sorry about the delay, I'm still backlogged from traveling. I'll get to this > soon. > > s'marks > > On 11/19/13 6:27 PM, Tristan Yan wrote: >> Hi Stuart >> Did you get chance to review it again. >> Let me know if you have any new comments or suggestions. >> Thanks >> Tristan >> >> -----????----- >> ???: Tristan Yan >> ????: Thursday, November 14, 2013 11:09 PM >> ???: Stuart Marks >> ??: core-libs-dev at openjdk.java.net >> ??: ??: RFR for JDK-7190106 RMI benchmark fails intermittently because of >> use of fixed port >> >> Thank you Stuart >> It took me a little time to correct the code. sorry be late. This is new >> webrev for the code change. Please help to review it again. >> >> Description: >> 1. Convert shell script test to Java program test. >> 2. Using random server port by reusing Darryl Mocek's >> work(TestLibrary.getUnusedRandomPort) to replace fixed server port. >> 3. Because TestLibrary doesn't have package. Here is using reflection to call >> TestLibrary.getUnusedRandomPort. This is going to change when TestLibrary >> moves to named package. >> 4. Using java Process class to start client process. Client and server are >> sharing IO. >> 5. Also convert other shell script test runSerialBench.sh to java program test >> also. >> 6. ProblemList has been changed to get back >> java/rmi/reliability/benchmark/runRmiBench.sh test. >> >> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >> >> Thank you so much >> Tristan >> >> >> -----????----- >> ???: Stuart Marks >> ????: Tuesday, November 12, 2013 11:38 PM >> ???: Tristan Yan >> ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline >> ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of >> use of fixed port >> >> Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI >> tests, since RMI's TestLibrary.getUnusedRandomPort() respects a "reserved" >> port range that's used by some RMI tests that have to used fixed ports. >> >> s'marks >> >> On 11/11/13 2:39 PM, Tristan Yan wrote: >>> Hi Stuart >>> Also there is one more solution, which is there is one >>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same >>> function as >>> TestLibrary.getUnusedRandomPort() and it has named package. Do you >>> mind I use this one? >>> Since these two functions provide same functionality. Maybe we should >>> think about to merge them at the same time. >>> Thank you >>> Tristan >>> >>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>> Hi Stuart >>>> I tried your suggestion but unfortunately all the benchmarks have >>>> dependencies to Main class because they need get stub from server. I >>>> suggest we move the benchmark tests to unnamed package unless we do >>>> want to put TestLibrary into a named package right now. >>>> Please let me know if you have objection on this. >>>> Thank you >>>> Tristan >>>> >>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>> Hi Tristan, >>>>> >>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>> unnamed package. Classes in a named package cannot import classes >>>>> from the unnamed package. We've run into problems with this before. >>>>> Eventually, we should move TestLibrary a named package. >>>>> >>>>> I think it's possible to work around this without too much >>>>> difficulty. Note that classes in the unnamed package can import classes >>>>> from named packages. >>>>> So, perhaps you can put the RmiBench main class in the unnamed >>>>> package so it has access to TestLibrary. Then have the benchmarks >>>>> themselves in the bench.rmi package. The config file already >>>>> references the benchmarks by fully qualified class name (e.g., >>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be able to >>>>> get this to work. >>>>> >>>>> s'marks >>>>> >>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>> Thank you, Stuart >>>>>> There is one review point I want to ask you opinion. Which is the >>>>>> reason that I moved from >>>>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>>>> class, I couldn't find a way to let a class which has Package to access >>>>>> the class without package. Do you have suggestion on that? >>>>>> Thank you so much. >>>>>> Tristan >>>>>> >>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>> >>>>>>> >>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>> Hi Everyone >>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>> >>>>>>>> Description: >>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>>>> replace fixed server port. >>>>>>>> 3. Using java Process class to start client process. >>>>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>>>> program test also >>>>>>> >>>>>>> Hi Tristan, >>>>>>> >>>>>>> Several comments on this webrev. >>>>>>> >>>>>>> >>>>>>> ** The original arrangement within the >>>>>>> test/java/rmi/reliability/benchmark >>>>>>> directory had the main benchmark files (scripts) at the top, some >>>>>>> benchmark framework files in the "bench" subdirectory, and the >>>>>>> actual RMI and serialization benchmarks in bench/rmi and bench/serial >>>>>>> subdirectories. >>>>>>> >>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>> directory but leaves the serial benchmarks in bench/serial. The >>>>>>> RMI benchmarks are now all cluttering the top directory, but the >>>>>>> main serial benchmark test is now buried in the bench/serial >>>>>>> directory. The nice organization that was there before is now >>>>>>> spoiled. Is this rearrangement necessary in order to convert the scripts >>>>>>> to Java? I would prefer the original arrangement be left in place. >>>>>>> >>>>>>> >>>>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>>>> >>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>>>>> -c config >>>>>>> >>>>>>> There is a subtle but serious problem here: the -server option is >>>>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>>>> The main() method gets neither a -server nor a -client argument, >>>>>>> so its default "run mode" as defined by the benchmark itself is >>>>>>> SAMEVM. This runs the client and server in the same JVM, which is >>>>>>> different from the shell script, which ran separate client and server JVMs. >>>>>>> >>>>>>> >>>>>>> ** The logic to process the -server argument still expects to take >>>>>>> a port, even though the port is assigned automatically. So the >>>>>>> obvious fix to the above, >>>>>>> >>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>>>>> -c config >>>>>>> >>>>>>> doesn't work, since a port is missing. The logic to increment the >>>>>>> argument index to collect the port argument should be removed. >>>>>>> Also, the -server line should be restored to the usage message, but >>>>>>> without the port argument. >>>>>>> >>>>>>> >>>>>>> ** After this is done, the client's command line is constructed improperly. >>>>>>> The command line ends up looking something like this: >>>>>>> >>>>>>> java client -cp Main client localhost:58583 -c >>>>>>> config >>>>>>> >>>>>>> The word "client" appears twice, but what's really required is >>>>>>> "-client" to appear as an argument after Main. >>>>>>> >>>>>>> >>>>>>> ** The client is run using ProcessBuilder, which by default sends >>>>>>> stdout and stderr to pipes to be read by the parent. But the >>>>>>> parent never reads them, thus any messages from the client are >>>>>>> never seen. The client is the one that emits the benchmark report, >>>>>>> so its output needs to be seen. It might be sufficient to have the >>>>>>> client inherit the parent's stdout and stderr. This might intermix >>>>>>> the client's and server's output, but it's better than nothing. >>>>>>> >>>>>>> >>>>>>> ** The config file is checked with the following code: >>>>>>> >>>>>>> try { >>>>>>> confFile = args[i]; >>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>> } catch (IOException e) { >>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>> } >>>>>>> >>>>>>> This is potentially misleading, as the message doesn't print the >>>>>>> actual filename that was attempted to be opened. >>>>>>> >>>>>>> This is important, as the test.src property doesn't exist in the client JVM. >>>>>>> >>>>>>> Note that the original shell script passed full pathnames for the >>>>>>> config file to both the client and the server. The new @run tag >>>>>>> merely says "-c config" which redefines the config filename to be >>>>>>> relative to the test.src directory. You could pass -Dtest.src=... >>>>>>> to the client, but it seems like there should be something better than >>>>>>> can be done. >>>>>>> >>>>>>> >>>>>>> ** The client needs to have its security policy set up. This is >>>>>>> missing from the construction of the client's command line. >>>>>>> >>>>>>> >>>>>>> ** ProcessBuilder takes a List for its command; there is >>>>>>> no need to turn the list into an array. >>>>>>> >>>>>>> >>>>>>> ** In the benchmark main methods, code of the form, >>>>>>> >>>>>>> while (true) { >>>>>>> runBenchmarks(); >>>>>>> if (exitRequested) { >>>>>>> System.exit(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> was replaced with >>>>>>> >>>>>>> while (!exitRequested) { >>>>>>> runBenchmarks(); >>>>>>> } >>>>>>> >>>>>>> This is a subtle logic change, in that the former code always >>>>>>> executed the loop at least once. It seems unlikely, but it's >>>>>>> possible that a timer could set exitRequested before loop entry, >>>>>>> resulting in the benchmark running zero times. I guess, if you >>>>>>> really want to clean this up (we do need to avoid System.exit in jtreg >>>>>>> tests), use a do-while loop instead. >>>>>>> >>>>>>> >>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>>>> ProblemList.txt. >>>>>>> >>>>>>> >>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>> RMISecurityManager last week.) :-) >>>>>>> >>>>>>> >>>>>>> It would be good if you could fix up these issues and post another webrev. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> s'marks >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thank you >>>>>>>> Tristan >>>>>>>> >>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>> I am working on bug >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my >>>>>>>>>> research, it looks like the issue of fixed port was already >>>>>>>>>> addressed by Stuart Marks in other RMI tests which are Java based. I >>>>>>>>>> would like to reuse his solution, however it does not work for shell >>>>>>>>>> based tests. >>>>>>>>> >>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>> >>>>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>>>> through. Most OpenJDK mailing lists strip off attachments before >>>>>>>>> forwarding Hi Stuart Also there is one more solution, which is >>>>>>>>> there is one >>>>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>>>>> same function as TestLibrary.getUnusedRandomPort() and it has named >>>>>>>>> package. >>>>>>>>> Do you mind I use this one? >>>>>>>>> Since these two function provide same functionality. Maybe we >>>>>>>>> should think about to merge them. >>>>>>>>> Thank you >>>>>>>>> Tristan >>>>>>>>> >>>>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>>>> Hi Stuart >>>>>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>>>>> have dependencies to Main class because they need get stub from >>>>>>>>>> server. I suggest we move the benchmark tests to unnamed >>>>>>>>>> package unless we do want to put TestLibrary into a named package >>>>>>>>>> right now. >>>>>>>>>> Please let me know if you have objection on this. >>>>>>>>>> Thank you >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>>>> Hi Tristan, >>>>>>>>>>> >>>>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>>>>> this before. Eventually, we should move TestLibrary a named package. >>>>>>>>>>> >>>>>>>>>>> I think it's possible to work around this without too much difficulty. >>>>>>>>>>> Note that classes in the unnamed package can import classes >>>>>>>>>>> from named packages. So, perhaps you can put the RmiBench main >>>>>>>>>>> class in the unnamed package so it has access to TestLibrary. >>>>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>>>> qualified class name (e.g., >>>>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>>>>> be able to get this to work. >>>>>>>>>>> >>>>>>>>>>> s'marks >>>>>>>>>>> >>>>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>>>> Thank you, Stuart >>>>>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>>>>> the reason that I moved from >>>>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way to >>>>>>>>>>>> let a class which has Package to access the class without package. >>>>>>>>>>>> Do you have suggestion on that? >>>>>>>>>>>> Thank you so much. >>>>>>>>>>>> Tristan >>>>>>>>>>>> >>>>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>>>> Hi Everyone >>>>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Description: >>>>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>>>>> to replace fixed server port. >>>>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh >>>>>>>>>>>>>> to java program test also >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>>> >>>>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>>>>> RMI and serialization benchmarks in bench/rmi and bench/serial >>>>>>>>>>>>> subdirectories. >>>>>>>>>>>>> >>>>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>>>>> but the main serial benchmark test is now buried in the >>>>>>>>>>>>> bench/serial directory. >>>>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>>>> scripts to Java? I would prefer the original arrangement be left in >>>>>>>>>>>>> place. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>>>>>> form, >>>>>>>>>>>>> >>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server >>>>>>>>>>>>> Main -c config >>>>>>>>>>>>> >>>>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>>>> option is passed to the >>JVM<< and not as an argument to the >>>>>>>>>>>>> main() method. >>>>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>>>> argument, so its default "run mode" as defined by the benchmark >>>>>>>>>>>>> itself is SAMEVM. >>>>>>>>>>>>> This runs the client and server in the same JVM, which is >>>>>>>>>>>>> different from the shell script, which ran separate client and >>>>>>>>>>>>> server JVMs. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** The logic to process the -server argument still expects >>>>>>>>>>>>> to take a port, even though the port is assigned >>>>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>>>> >>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>>>>> -server -c config >>>>>>>>>>>>> >>>>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>>>> increment the argument index to collect the port argument >>>>>>>>>>>>> should be removed. Also, the -server line should be restored >>>>>>>>>>>>> to the usage message, but without the port argument. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>>>> constructed improperly. The command line ends up looking something >>>>>>>>>>>>> like this: >>>>>>>>>>>>> >>>>>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>>>>> -c config >>>>>>>>>>>>> >>>>>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>>>> But the parent never reads them, thus any messages from the client >>>>>>>>>>>>> are never seen. >>>>>>>>>>>>> The client is the one that emits the benchmark report, so >>>>>>>>>>>>> its output needs to be seen. It might be sufficient to have >>>>>>>>>>>>> the client inherit the parent's stdout and stderr. This >>>>>>>>>>>>> might intermix the client's and server's output, but it's better >>>>>>>>>>>>> than nothing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>>>> >>>>>>>>>>>>> try { >>>>>>>>>>>>> confFile = args[i]; >>>>>>>>>>>>> confstr = new FileInputStream(System.getProperty("test.src") >>>>>>>>>>>>> + System.getProperty("file.separator") + confFile); >>>>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>>>>> >>>>>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>>>>> the client JVM. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that the original shell script passed full pathnames >>>>>>>>>>>>> for the config file to both the client and the server. The >>>>>>>>>>>>> new @run tag merely says "-c config" which redefines the >>>>>>>>>>>>> config filename to be relative to the test.src directory. >>>>>>>>>>>>> You could pass -Dtest.src=... to the client, but it seems >>>>>>>>>>>>> like there should be something better than can be done. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>>>>> is missing from the construction of the client's command line. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>>>> >>>>>>>>>>>>> while (true) { >>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>> if (exitRequested) { >>>>>>>>>>>>> System.exit(); >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> was replaced with >>>>>>>>>>>>> >>>>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>>>> always executed the loop at least once. It seems unlikely, >>>>>>>>>>>>> but it's possible that a timer could set exitRequested >>>>>>>>>>>>> before loop entry, resulting in the benchmark running zero >>>>>>>>>>>>> times. I guess, if you really want to clean this up (we do >>>>>>>>>>>>> need to avoid System.exit in jtreg tests), use a do-while loop >>>>>>>>>>>>> instead. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>>>>> from ProblemList.txt. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>>>>> another webrev. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> s'marks >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>> Tristan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests >>>>>>>>>>>>>>>> which are Java based. I would like to reuse his solution, >>>>>>>>>>>>>>>> however it does not work for shell based tests. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>>>>> get through. Most OpenJDK mailing lists strip off >>>>>>>>>>>>>>> attachments before forwarding the message to the >>>>>>>>>>>>>>> recipients. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>>>> script test into Java based test and re-use the dynamic >>>>>>>>>>>>>>>> port allocation solution by Stuart Marks to address the >>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>>>>> shell script. In the past there have been sync issues >>>>>>>>>>>>>>>> between server/client which caused the test to fail. If >>>>>>>>>>>>>>>> we convert the shell script into Java based test, it >>>>>>>>>>>>>>>> would avoid using "sleep 10" mechanism to allow for >>>>>>>>>>>>>>>> server and client to start up and also give us better >>>>>>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>>>>> quite difficult to make reliable shell tests, especially >>>>>>>>>>>>>>> for multi-process tests like this one. >>>>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>>>> issue of how long for the client to wait until the server >>>>>>>>>>>>>>> is ready. Error handling is also a problem, for example, >>>>>>>>>>>>>>> if one of the JVMs gets an unexpected exception, it's easy >>>>>>>>>>>>>>> for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>>>> erroneously report success. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) >>>>>>>>>>>>>>> and then post a link to it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> the message to >>>>>>>>> the recipients. >>>>>>>>> >>>>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>>>> into Java based test and re-use the dynamic port allocation >>>>>>>>>> solution by Stuart Marks to address the issue >>>>>>>>>> >>>>>>>>>> 3. Also this test was written with server/client mode in shell script. >>>>>>>>>> In the >>>>>>>>>> past there have been sync issues between server/client which >>>>>>>>>> caused the test to fail. If we convert the shell script into >>>>>>>>>> Java based test, it would avoid using "sleep 10" mechanism to >>>>>>>>>> allow for server and client to start up and also give us better >>>>>>>>>> control in synchronizing server and client. >>>>>>>>> >>>>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>>>> difficult to make reliable shell tests, especially for >>>>>>>>> multi-process tests like this one. >>>>>>>>> There is the unique port issue, and there is also the issue of >>>>>>>>> how long for the client to wait until the server is ready. Error >>>>>>>>> handling is also a problem, for example, if one of the JVMs gets >>>>>>>>> an unexpected exception, it's easy for shell tests to mishandle >>>>>>>>> this case. They might hang or erroneously report success. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>>>> upload it somewhere (e.g., cr.openjdk.java.net) and then post a link to >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>> >>>>>> >>>>> >>>> >>> From mike.duigou at oracle.com Tue Nov 26 04:32:36 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Nov 2013 20:32:36 -0800 Subject: RFR: 8029055: Map.merge must refuse null values In-Reply-To: <52929A59.20204@oracle.com> References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> <52929A59.20204@oracle.com> Message-ID: <63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com> On Nov 24 2013, at 16:31 , David Holmes wrote: > Hi Mike, > > There is still no clear spec for what should happen if the param value is null. I feel very uncomfortable the status quo of with null being ignored, used for a sentinel and also as value. The relations between null and values in this method are just too complicated. Currently: - The provided value may be either null or non-null. Is null a legal value? It depends upon: - Is there an existing value? - Does the Map allow null values? - Does the function allow null values? - Existing null values are treated as absent. - If a null value is passed should we remove this mapping or add it to the map? - null might not be accepted by the map - The associated value would still be regarded as absent for future operations. - The function may return null to signal "remove". In particular I dislike adding a null entry to the map if there is no current mapping (or mapped to null). It seems like it should be invariant whether we end up with an associated value. If null is used to signify "remove" then map.contains(key) will return variable results depending upon the initial state. Having the behaviour vary based upon whether the map allows null values would be even worse. So I would like to suggest that we require value to be non-null. I have provisionally updated the spec and impls accordingly. > The parenthesized part is wrong. I think that's overzealous copying from compute(). I have removed it. > > Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading. I will correct this. More changes were made than I originally expected. New synopsis will be "Map.merge implementations should refuse null value param" I have updated the webrev. http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/ Thanks, Mike > > Thanks, > David > > On 23/11/2013 10:25 AM, Mike Duigou wrote: >> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. >> >> I've posted a webrev here: >> >> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ >> >> There is an identical change in ConcurrentMap's merge(). >> >> Mike >> >> On Nov 22 2013, at 16:01 , Henry Jen wrote: >> >>> >>> On 11/21/2013 06:33 PM, David Holmes wrote: >>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>>>> While I agree that case should be specified, I'm not certain I follow why >>>>> that's what's going on here. >>>>> >>>>> The weird condition is that if oldValue is null, not value; oldValue >>>>> is the >>>>> old result of map.get(key). The Javadoc seems not just unspecified, but >>>>> actively wrong. Here's a worked example: >>>>> >>>>> Map map = new HashMap<>(); >>>>> map.merge("foo", 3, Integer::plus); >>>>> Integer fooValue = map.get("foo"); >>>>> >>>>> Going through the Javadoc-specified default implementation: >>>>> >>>>> V oldValue = map.get(key); // oldValue is null >>>>> V newValue = (oldValue == null) ? value : >>>>> remappingFunction.apply(oldValue, value); >>>>> // newValue is set to value, which is 3 >>>>> if (newValue == null) // newValue is nonnull, branch not taken >>>>> map.remove(key); >>>>> else if (oldValue == null) // oldValue is null, branch taken >>>>> map.remove(key); // removes the entry from the map >>>>> else // else if was already triggered, branch not taken >>>>> map.put(key, newValue); >>>>> >>> >>> Seems like a document bug to me, we should fix this @implSpec. >>> >>> Cheers, >>> Henry >>> >> From tristan.yan at oracle.com Tue Nov 26 05:12:30 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 26 Nov 2013 13:12:30 +0800 Subject: =?UTF-8?B?562U5aSNOiBSRlIgZm9yIEpESy03MTkwMTA2IFJNSSBiZW5jaG0=?= =?UTF-8?B?YXJrIGZhaWxzIGludGVybWl0dGVudGx5IGJlY2F1c2Ugb2YgdXNlIG9mIGZpeGU=?= =?UTF-8?B?ZCBwb3J0?= In-Reply-To: <52940923.8000903@oracle.com> References: <5273CFA5.4070803@oracle.com> <5273D448.2050808@oracle.com> <5279A059.9010304@oracle.com> <527CC45E.5050902@oracle.com> <527D2D58.1010703@oracle.com> <527EFB4B.1010502@oracle.com> <5280DE1A.4040708@oracle.com> <52824B59.9020406@oracle.com> <09ed5de7-e061-45b3-9f09-936a624dce1b@default> <528D2E57.1070001@oracle.com> <52940923.8000903@oracle.com> Message-ID: <52942DBE.5050801@oracle.com> Hi Stuart Thanks for your code review. I updated the webrev according your suggestion. Could you review it again? http://cr.openjdk.java.net/~ewang/tristan/JDK-7190106/webrev.00/ Tristan On 11/26/2013 10:36 AM, Stuart Marks wrote: > Hi Tristan, > > Finally getting back to this. Again, sorry for the delay. > > The changes look much better now. I've listed a bunch of items below, > but they're all comparatively minor, even nitpicky. But there are a > few things that should be cleaned up before we integrate this. > > Items listed below. > > > ** bench/serial/Main.java > > > - The description should simply be "The Serialization benchmark > test". This test has nothing to do with RMI, even though it's under > the java/rmi hierarchy in the filesystem. > > - parseArgs() uses strings-in-switch! Good, but put "break" on its > own line instead of following the close-brace of the catch clause. > (rmi/Main.java doesn't have this issue.) > > > ** bench/rmi/Main.java > > > - Imports of java.util.logging.Level and Logger are unused? > > - Missing "-server" line from usage(). > > - Interesting use of enum. Note by convention an enum is like a class > and names are in mixed case, thus use OutputFormat instead of > OUTPUT_FORMAT. Also note that the enum doesn't buy much, at least in > terms of lines of code, since the enum declaration and enum instance > overrides add about as much code as the case statement that got > removed from setupReporter(). It does buy a bit of type-safety, > though, so might as well leave it in. > > - Enum instance HTML should be on a new line, like XML. > > - Reflection code can be chained instead of declaring several locals. > This is mainly a matter of taste, but to my eye it's cleaner. The main > advantage is avoiding the need to come up with names for intermediate > locals. For example: > > port = (int) Class.forName("TestLibrary") > .getMethod("getUnusedRandomPort") > .invoke(null); > > - Catch clause at 389 can be of ReflectiveOperationException. This > covers everything except IllegalArgumentException, which is unchecked, > so you don't need to catch it. > > (Not sure why Method.invoke is declared to throw > IllegalArgumentException, since generally only checked exceptions are > declared in the throws clause.) > > - Line 416, no need to mention RMISecurityManager in a comment, just > make the change to use SecurityManager. > > - It's kind of surprising that TEST_SRC_PATH appends the file > separator to the test.src property. At line 241 test.src has to be > fetched again to use it without the file separator. > > - Line 234, instead of the java.home property, use the test.jdk > property. This will use the JDK under test instead of the JDK that's > running jtreg. In practice it's unclear whether this makes any actual > difference today, but it's good to try to keep this separation. Also, > use file separators here instead of appending "/bin/java". > > (Hmmm. I observe that the RMI testlibrary invokes JVM subprocesses > using java.home.) > > > Thanks, > > > s'marks > > > On 11/20/13 1:49 PM, Stuart Marks wrote: >> Hi, sorry about the delay, I'm still backlogged from traveling. I'll >> get to this >> soon. >> >> s'marks >> >> On 11/19/13 6:27 PM, Tristan Yan wrote: >>> Hi Stuart >>> Did you get chance to review it again. >>> Let me know if you have any new comments or suggestions. >>> Thanks >>> Tristan >>> >>> -----????----- >>> ???: Tristan Yan >>> ????: Thursday, November 14, 2013 11:09 PM >>> ???: Stuart Marks >>> ??: core-libs-dev at openjdk.java.net >>> ??: ??: RFR for JDK-7190106 RMI benchmark fails intermittently >>> because of >>> use of fixed port >>> >>> Thank you Stuart >>> It took me a little time to correct the code. sorry be late. This is >>> new >>> webrev for the code change. Please help to review it again. >>> >>> Description: >>> 1. Convert shell script test to Java program test. >>> 2. Using random server port by reusing Darryl Mocek's >>> work(TestLibrary.getUnusedRandomPort) to replace fixed server port. >>> 3. Because TestLibrary doesn't have package. Here is using >>> reflection to call >>> TestLibrary.getUnusedRandomPort. This is going to change when >>> TestLibrary >>> moves to named package. >>> 4. Using java Process class to start client process. Client and >>> server are >>> sharing IO. >>> 5. Also convert other shell script test runSerialBench.sh to java >>> program test >>> also. >>> 6. ProblemList has been changed to get back >>> java/rmi/reliability/benchmark/runRmiBench.sh test. >>> >>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>> >>> Thank you so much >>> Tristan >>> >>> >>> -----????----- >>> ???: Stuart Marks >>> ????: Tuesday, November 12, 2013 11:38 PM >>> ???: Tristan Yan >>> ??: core-libs-dev at openjdk.java.net; Alexandre (Shura) Iline >>> ??: Re: RFR for JDK-7190106 RMI benchmark fails intermittently >>> because of >>> use of fixed port >>> >>> Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for >>> the RMI >>> tests, since RMI's TestLibrary.getUnusedRandomPort() respects a >>> "reserved" >>> port range that's used by some RMI tests that have to used fixed ports. >>> >>> s'marks >>> >>> On 11/11/13 2:39 PM, Tristan Yan wrote: >>>> Hi Stuart >>>> Also there is one more solution, which is there is one >>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same >>>> function as >>>> TestLibrary.getUnusedRandomPort() and it has named package. Do you >>>> mind I use this one? >>>> Since these two functions provide same functionality. Maybe we should >>>> think about to merge them at the same time. >>>> Thank you >>>> Tristan >>>> >>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>> Hi Stuart >>>>> I tried your suggestion but unfortunately all the benchmarks have >>>>> dependencies to Main class because they need get stub from server. I >>>>> suggest we move the benchmark tests to unnamed package unless we do >>>>> want to put TestLibrary into a named package right now. >>>>> Please let me know if you have objection on this. >>>>> Thank you >>>>> Tristan >>>>> >>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>> Hi Tristan, >>>>>> >>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>> unnamed package. Classes in a named package cannot import classes >>>>>> from the unnamed package. We've run into problems with this before. >>>>>> Eventually, we should move TestLibrary a named package. >>>>>> >>>>>> I think it's possible to work around this without too much >>>>>> difficulty. Note that classes in the unnamed package can import >>>>>> classes >>>>>> from named packages. >>>>>> So, perhaps you can put the RmiBench main class in the unnamed >>>>>> package so it has access to TestLibrary. Then have the benchmarks >>>>>> themselves in the bench.rmi package. The config file already >>>>>> references the benchmarks by fully qualified class name (e.g., >>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to be >>>>>> able to >>>>>> get this to work. >>>>>> >>>>>> s'marks >>>>>> >>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>> Thank you, Stuart >>>>>>> There is one review point I want to ask you opinion. Which is the >>>>>>> reason that I moved from >>>>>>> test/java/rmi/reliability/benchmark/bench/rmi to >>>>>>> test/java/rmi/reliability/benchmark is Main.java need access class >>>>>>> TestLibrary for supporting random port. TestLibrary is a unpackage >>>>>>> class, I couldn't find a way to let a class which has Package to >>>>>>> access >>>>>>> the class without package. Do you have suggestion on that? >>>>>>> Thank you so much. >>>>>>> Tristan >>>>>>> >>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>> Hi Everyone >>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>> >>>>>>>>> Description: >>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work to >>>>>>>>> replace fixed server port. >>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>> 4. Also convert other shell script test runSerialBench.sh to java >>>>>>>>> program test also >>>>>>>> >>>>>>>> Hi Tristan, >>>>>>>> >>>>>>>> Several comments on this webrev. >>>>>>>> >>>>>>>> >>>>>>>> ** The original arrangement within the >>>>>>>> test/java/rmi/reliability/benchmark >>>>>>>> directory had the main benchmark files (scripts) at the top, some >>>>>>>> benchmark framework files in the "bench" subdirectory, and the >>>>>>>> actual RMI and serialization benchmarks in bench/rmi and >>>>>>>> bench/serial >>>>>>>> subdirectories. >>>>>>>> >>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>> directory but leaves the serial benchmarks in bench/serial. The >>>>>>>> RMI benchmarks are now all cluttering the top directory, but the >>>>>>>> main serial benchmark test is now buried in the bench/serial >>>>>>>> directory. The nice organization that was there before is now >>>>>>>> spoiled. Is this rearrangement necessary in order to convert >>>>>>>> the scripts >>>>>>>> to Java? I would prefer the original arrangement be left in place. >>>>>>>> >>>>>>>> >>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the form, >>>>>>>> >>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 -server Main >>>>>>>> -c config >>>>>>>> >>>>>>>> There is a subtle but serious problem here: the -server option is >>>>>>>> passed to the >>JVM<< and not as an argument to the main() method. >>>>>>>> The main() method gets neither a -server nor a -client argument, >>>>>>>> so its default "run mode" as defined by the benchmark itself is >>>>>>>> SAMEVM. This runs the client and server in the same JVM, which is >>>>>>>> different from the shell script, which ran separate client and >>>>>>>> server JVMs. >>>>>>>> >>>>>>>> >>>>>>>> ** The logic to process the -server argument still expects to take >>>>>>>> a port, even though the port is assigned automatically. So the >>>>>>>> obvious fix to the above, >>>>>>>> >>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main -server >>>>>>>> -c config >>>>>>>> >>>>>>>> doesn't work, since a port is missing. The logic to increment the >>>>>>>> argument index to collect the port argument should be removed. >>>>>>>> Also, the -server line should be restored to the usage message, >>>>>>>> but >>>>>>>> without the port argument. >>>>>>>> >>>>>>>> >>>>>>>> ** After this is done, the client's command line is constructed >>>>>>>> improperly. >>>>>>>> The command line ends up looking something like this: >>>>>>>> >>>>>>>> java client -cp Main client localhost:58583 -c >>>>>>>> config >>>>>>>> >>>>>>>> The word "client" appears twice, but what's really required is >>>>>>>> "-client" to appear as an argument after Main. >>>>>>>> >>>>>>>> >>>>>>>> ** The client is run using ProcessBuilder, which by default sends >>>>>>>> stdout and stderr to pipes to be read by the parent. But the >>>>>>>> parent never reads them, thus any messages from the client are >>>>>>>> never seen. The client is the one that emits the benchmark report, >>>>>>>> so its output needs to be seen. It might be sufficient to have the >>>>>>>> client inherit the parent's stdout and stderr. This might intermix >>>>>>>> the client's and server's output, but it's better than nothing. >>>>>>>> >>>>>>>> >>>>>>>> ** The config file is checked with the following code: >>>>>>>> >>>>>>>> try { >>>>>>>> confFile = args[i]; >>>>>>>> confstr = new >>>>>>>> FileInputStream(System.getProperty("test.src") >>>>>>>> + System.getProperty("file.separator") + >>>>>>>> confFile); >>>>>>>> } catch (IOException e) { >>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>> } >>>>>>>> >>>>>>>> This is potentially misleading, as the message doesn't print the >>>>>>>> actual filename that was attempted to be opened. >>>>>>>> >>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>> the client JVM. >>>>>>>> >>>>>>>> Note that the original shell script passed full pathnames for the >>>>>>>> config file to both the client and the server. The new @run tag >>>>>>>> merely says "-c config" which redefines the config filename to be >>>>>>>> relative to the test.src directory. You could pass -Dtest.src=... >>>>>>>> to the client, but it seems like there should be something >>>>>>>> better than >>>>>>>> can be done. >>>>>>>> >>>>>>>> >>>>>>>> ** The client needs to have its security policy set up. This is >>>>>>>> missing from the construction of the client's command line. >>>>>>>> >>>>>>>> >>>>>>>> ** ProcessBuilder takes a List for its command; there is >>>>>>>> no need to turn the list into an array. >>>>>>>> >>>>>>>> >>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>> >>>>>>>> while (true) { >>>>>>>> runBenchmarks(); >>>>>>>> if (exitRequested) { >>>>>>>> System.exit(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> was replaced with >>>>>>>> >>>>>>>> while (!exitRequested) { >>>>>>>> runBenchmarks(); >>>>>>>> } >>>>>>>> >>>>>>>> This is a subtle logic change, in that the former code always >>>>>>>> executed the loop at least once. It seems unlikely, but it's >>>>>>>> possible that a timer could set exitRequested before loop entry, >>>>>>>> resulting in the benchmark running zero times. I guess, if you >>>>>>>> really want to clean this up (we do need to avoid System.exit >>>>>>>> in jtreg >>>>>>>> tests), use a do-while loop instead. >>>>>>>> >>>>>>>> >>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry from >>>>>>>> ProblemList.txt. >>>>>>>> >>>>>>>> >>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>> RMISecurityManager last week.) :-) >>>>>>>> >>>>>>>> >>>>>>>> It would be good if you could fix up these issues and post >>>>>>>> another webrev. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> s'marks >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thank you >>>>>>>>> Tristan >>>>>>>>> >>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>> I am working on bug >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based on my >>>>>>>>>>> research, it looks like the issue of fixed port was already >>>>>>>>>>> addressed by Stuart Marks in other RMI tests which are Java >>>>>>>>>>> based. I >>>>>>>>>>> would like to reuse his solution, however it does not work >>>>>>>>>>> for shell >>>>>>>>>>> based tests. >>>>>>>>>> >>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>> >>>>>>>>>> Was the patch attached to your message? If so, it didn't get >>>>>>>>>> through. Most OpenJDK mailing lists strip off attachments before >>>>>>>>>> forwarding Hi Stuart Also there is one more solution, which is >>>>>>>>>> there is one >>>>>>>>>> jdk.testlibrary.Utils.getFreePort() method under test/lib. It's >>>>>>>>>> same function as TestLibrary.getUnusedRandomPort() and it has >>>>>>>>>> named >>>>>>>>>> package. >>>>>>>>>> Do you mind I use this one? >>>>>>>>>> Since these two function provide same functionality. Maybe we >>>>>>>>>> should think about to merge them. >>>>>>>>>> Thank you >>>>>>>>>> Tristan >>>>>>>>>> >>>>>>>>>> On 11/10/2013 11:19 AM, Tristan Yan wrote: >>>>>>>>>>> Hi Stuart >>>>>>>>>>> I tried your suggestion but unfortunately all the benchmarks >>>>>>>>>>> have dependencies to Main class because they need get stub from >>>>>>>>>>> server. I suggest we move the benchmark tests to unnamed >>>>>>>>>>> package unless we do want to put TestLibrary into a named >>>>>>>>>>> package >>>>>>>>>>> right now. >>>>>>>>>>> Please let me know if you have objection on this. >>>>>>>>>>> Thank you >>>>>>>>>>> Tristan >>>>>>>>>>> >>>>>>>>>>> On 11/09/2013 02:28 AM, Stuart Marks wrote: >>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>> >>>>>>>>>>>> Yes, it's kind of a problem that the RMI TestLibrary is in the >>>>>>>>>>>> unnamed package. Classes in a named package cannot import >>>>>>>>>>>> classes from the unnamed package. We've run into problems with >>>>>>>>>>>> this before. Eventually, we should move TestLibrary a named >>>>>>>>>>>> package. >>>>>>>>>>>> >>>>>>>>>>>> I think it's possible to work around this without too much >>>>>>>>>>>> difficulty. >>>>>>>>>>>> Note that classes in the unnamed package can import classes >>>>>>>>>>>> from named packages. So, perhaps you can put the RmiBench main >>>>>>>>>>>> class in the unnamed package so it has access to TestLibrary. >>>>>>>>>>>> Then have the benchmarks themselves in the bench.rmi package. >>>>>>>>>>>> The config file already references the benchmarks by fully >>>>>>>>>>>> qualified class name (e.g., >>>>>>>>>>>> "bench.rmi.NullCalls") so with a bit of tinkering you ought to >>>>>>>>>>>> be able to get this to work. >>>>>>>>>>>> >>>>>>>>>>>> s'marks >>>>>>>>>>>> >>>>>>>>>>>> On 11/8/13 3:00 AM, Tristan Yan wrote: >>>>>>>>>>>>> Thank you, Stuart >>>>>>>>>>>>> There is one review point I want to ask you opinion. Which is >>>>>>>>>>>>> the reason that I moved from >>>>>>>>>>>>> test/java/rmi/reliability/benchmark/bench/rmi >>>>>>>>>>>>> to test/java/rmi/reliability/benchmark is Main.java need >>>>>>>>>>>>> access class TestLibrary for supporting random port. >>>>>>>>>>>>> TestLibrary is a unpackage class, I couldn't find a way to >>>>>>>>>>>>> let a class which has Package to access the class without >>>>>>>>>>>>> package. >>>>>>>>>>>>> Do you have suggestion on that? >>>>>>>>>>>>> Thank you so much. >>>>>>>>>>>>> Tristan >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/06/2013 09:50 AM, Stuart Marks wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/1/13 9:18 AM, Tristan Yan wrote: >>>>>>>>>>>>>>> Hi Everyone >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Description: >>>>>>>>>>>>>>> 1. Convert shell script test to Java program test. >>>>>>>>>>>>>>> 2. Using random server port by reusing Darryl Mocek's work >>>>>>>>>>>>>>> to replace fixed server port. >>>>>>>>>>>>>>> 3. Using java Process class to start client process. >>>>>>>>>>>>>>> 4. Also convert other shell script test runSerialBench.sh >>>>>>>>>>>>>>> to java program test also >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Tristan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Several comments on this webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** The original arrangement within the >>>>>>>>>>>>>> test/java/rmi/reliability/benchmark directory had the main >>>>>>>>>>>>>> benchmark files (scripts) at the top, some benchmark >>>>>>>>>>>>>> framework files in the "bench" subdirectory, and the actual >>>>>>>>>>>>>> RMI and serialization benchmarks in bench/rmi and >>>>>>>>>>>>>> bench/serial >>>>>>>>>>>>>> subdirectories. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The webrev moves all the RMI benchmarks to the top benchmark >>>>>>>>>>>>>> directory but leaves the serial benchmarks in bench/serial. >>>>>>>>>>>>>> The RMI benchmarks are now all cluttering the top directory, >>>>>>>>>>>>>> but the main serial benchmark test is now buried in the >>>>>>>>>>>>>> bench/serial directory. >>>>>>>>>>>>>> The nice organization that was there before is now spoiled. >>>>>>>>>>>>>> Is this rearrangement necessary in order to convert the >>>>>>>>>>>>>> scripts to Java? I would prefer the original arrangement >>>>>>>>>>>>>> be left in >>>>>>>>>>>>>> place. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** The RMI benchmark Main.java file has a @run tag of the >>>>>>>>>>>>>> form, >>>>>>>>>>>>>> >>>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 >>>>>>>>>>>>>> -server >>>>>>>>>>>>>> Main -c config >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is a subtle but serious problem here: the -server >>>>>>>>>>>>>> option is passed to the >>JVM<< and not as an argument to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> main() method. >>>>>>>>>>>>>> The main() method gets neither a -server nor a -client >>>>>>>>>>>>>> argument, so its default "run mode" as defined by the >>>>>>>>>>>>>> benchmark >>>>>>>>>>>>>> itself is SAMEVM. >>>>>>>>>>>>>> This runs the client and server in the same JVM, which is >>>>>>>>>>>>>> different from the shell script, which ran separate >>>>>>>>>>>>>> client and >>>>>>>>>>>>>> server JVMs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** The logic to process the -server argument still expects >>>>>>>>>>>>>> to take a port, even though the port is assigned >>>>>>>>>>>>>> automatically. So the obvious fix to the above, >>>>>>>>>>>>>> >>>>>>>>>>>>>> @run main/othervm/policy=policy.all/timeout=1800 Main >>>>>>>>>>>>>> -server -c config >>>>>>>>>>>>>> >>>>>>>>>>>>>> doesn't work, since a port is missing. The logic to >>>>>>>>>>>>>> increment the argument index to collect the port argument >>>>>>>>>>>>>> should be removed. Also, the -server line should be restored >>>>>>>>>>>>>> to the usage message, but without the port argument. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** After this is done, the client's command line is >>>>>>>>>>>>>> constructed improperly. The command line ends up looking >>>>>>>>>>>>>> something >>>>>>>>>>>>>> like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> java client -cp Main client localhost:58583 >>>>>>>>>>>>>> -c config >>>>>>>>>>>>>> >>>>>>>>>>>>>> The word "client" appears twice, but what's really required >>>>>>>>>>>>>> is "-client" to appear as an argument after Main. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** The client is run using ProcessBuilder, which by default >>>>>>>>>>>>>> sends stdout and stderr to pipes to be read by the parent. >>>>>>>>>>>>>> But the parent never reads them, thus any messages from >>>>>>>>>>>>>> the client >>>>>>>>>>>>>> are never seen. >>>>>>>>>>>>>> The client is the one that emits the benchmark report, so >>>>>>>>>>>>>> its output needs to be seen. It might be sufficient to have >>>>>>>>>>>>>> the client inherit the parent's stdout and stderr. This >>>>>>>>>>>>>> might intermix the client's and server's output, but it's >>>>>>>>>>>>>> better >>>>>>>>>>>>>> than nothing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** The config file is checked with the following code: >>>>>>>>>>>>>> >>>>>>>>>>>>>> try { >>>>>>>>>>>>>> confFile = args[i]; >>>>>>>>>>>>>> confstr = new >>>>>>>>>>>>>> FileInputStream(System.getProperty("test.src") >>>>>>>>>>>>>> + System.getProperty("file.separator") + >>>>>>>>>>>>>> confFile); >>>>>>>>>>>>>> } catch (IOException e) { >>>>>>>>>>>>>> die("Error: unable to open \"" + args[i] + "\""); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is potentially misleading, as the message doesn't print >>>>>>>>>>>>>> the actual filename that was attempted to be opened. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is important, as the test.src property doesn't exist in >>>>>>>>>>>>>> the client JVM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that the original shell script passed full pathnames >>>>>>>>>>>>>> for the config file to both the client and the server. The >>>>>>>>>>>>>> new @run tag merely says "-c config" which redefines the >>>>>>>>>>>>>> config filename to be relative to the test.src directory. >>>>>>>>>>>>>> You could pass -Dtest.src=... to the client, but it seems >>>>>>>>>>>>>> like there should be something better than can be done. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** The client needs to have its security policy set up. This >>>>>>>>>>>>>> is missing from the construction of the client's command >>>>>>>>>>>>>> line. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** ProcessBuilder takes a List for its command; >>>>>>>>>>>>>> there is no need to turn the list into an array. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** In the benchmark main methods, code of the form, >>>>>>>>>>>>>> >>>>>>>>>>>>>> while (true) { >>>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>>> if (exitRequested) { >>>>>>>>>>>>>> System.exit(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> was replaced with >>>>>>>>>>>>>> >>>>>>>>>>>>>> while (!exitRequested) { >>>>>>>>>>>>>> runBenchmarks(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a subtle logic change, in that the former code >>>>>>>>>>>>>> always executed the loop at least once. It seems unlikely, >>>>>>>>>>>>>> but it's possible that a timer could set exitRequested >>>>>>>>>>>>>> before loop entry, resulting in the benchmark running zero >>>>>>>>>>>>>> times. I guess, if you really want to clean this up (we do >>>>>>>>>>>>>> need to avoid System.exit in jtreg tests), use a do-while >>>>>>>>>>>>>> loop >>>>>>>>>>>>>> instead. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** Don't forget to remove the 7190106/runRmiBench.sh entry >>>>>>>>>>>>>> from ProblemList.txt. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ** Remove the references to RMISecurityManager and just use >>>>>>>>>>>>>> SecurityManager. This is just general cleanup. (I deprecated >>>>>>>>>>>>>> RMISecurityManager last week.) :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> It would be good if you could fix up these issues and post >>>>>>>>>>>>>> another webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you >>>>>>>>>>>>>>> Tristan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 01/11/2013 23:58, Stuart Marks wrote: >>>>>>>>>>>>>>>> On 10/31/13 10:22 PM, Tristan Yan wrote: >>>>>>>>>>>>>>>>> I am working on bug >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7190106. Based >>>>>>>>>>>>>>>>> on my research, it looks like the issue of fixed port was >>>>>>>>>>>>>>>>> already addressed by Stuart Marks in other RMI tests >>>>>>>>>>>>>>>>> which are Java based. I would like to reuse his solution, >>>>>>>>>>>>>>>>> however it does not work for shell based tests. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (Darryl Mocek did the unique port work for the RMI tests.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Was the patch attached to your message? If so, it didn't >>>>>>>>>>>>>>>> get through. Most OpenJDK mailing lists strip off >>>>>>>>>>>>>>>> attachments before forwarding the message to the >>>>>>>>>>>>>>>> recipients. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. My recommendation would be to convert this shell >>>>>>>>>>>>>>>>> script test into Java based test and re-use the dynamic >>>>>>>>>>>>>>>>> port allocation solution by Stuart Marks to address the >>>>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>>>>>>>> shell script. In the past there have been sync issues >>>>>>>>>>>>>>>>> between server/client which caused the test to fail. If >>>>>>>>>>>>>>>>> we convert the shell script into Java based test, it >>>>>>>>>>>>>>>>> would avoid using "sleep 10" mechanism to allow for >>>>>>>>>>>>>>>>> server and client to start up and also give us better >>>>>>>>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (Background for interested readers.) In general, yes, it's >>>>>>>>>>>>>>>> quite difficult to make reliable shell tests, especially >>>>>>>>>>>>>>>> for multi-process tests like this one. >>>>>>>>>>>>>>>> There is the unique port issue, and there is also the >>>>>>>>>>>>>>>> issue of how long for the client to wait until the server >>>>>>>>>>>>>>>> is ready. Error handling is also a problem, for example, >>>>>>>>>>>>>>>> if one of the JVMs gets an unexpected exception, it's easy >>>>>>>>>>>>>>>> for shell tests to mishandle this case. They might hang or >>>>>>>>>>>>>>>> erroneously report success. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If this is a rewrite, it's probably fairly large, so you >>>>>>>>>>>>>>>> need to upload it somewhere (e.g., cr.openjdk.java.net) >>>>>>>>>>>>>>>> and then post a link to it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> s'marks >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the message to >>>>>>>>>> the recipients. >>>>>>>>>> >>>>>>>>>>> 2. My recommendation would be to convert this shell script test >>>>>>>>>>> into Java based test and re-use the dynamic port allocation >>>>>>>>>>> solution by Stuart Marks to address the issue >>>>>>>>>>> >>>>>>>>>>> 3. Also this test was written with server/client mode in >>>>>>>>>>> shell script. >>>>>>>>>>> In the >>>>>>>>>>> past there have been sync issues between server/client which >>>>>>>>>>> caused the test to fail. If we convert the shell script into >>>>>>>>>>> Java based test, it would avoid using "sleep 10" mechanism to >>>>>>>>>>> allow for server and client to start up and also give us better >>>>>>>>>>> control in synchronizing server and client. >>>>>>>>>> >>>>>>>>>> (Background for interested readers.) In general, yes, it's quite >>>>>>>>>> difficult to make reliable shell tests, especially for >>>>>>>>>> multi-process tests like this one. >>>>>>>>>> There is the unique port issue, and there is also the issue of >>>>>>>>>> how long for the client to wait until the server is ready. Error >>>>>>>>>> handling is also a problem, for example, if one of the JVMs gets >>>>>>>>>> an unexpected exception, it's easy for shell tests to mishandle >>>>>>>>>> this case. They might hang or erroneously report success. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> If this is a rewrite, it's probably fairly large, so you need to >>>>>>>>>> upload it somewhere (e.g., cr.openjdk.java.net) and then post >>>>>>>>>> a link to >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> s'marks >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> From yuka.kamiya at oracle.com Tue Nov 26 05:51:08 2013 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Tue, 26 Nov 2013 05:51:08 +0000 Subject: hg: jdk8/tl/jdk: 8029057: test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError Message-ID: <20131126055121.962F06284F@hg.openjdk.java.net> Changeset: 4d9078b1f25b Author: peytoia Date: 2013-11-26 14:49 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d9078b1f25b 8029057: test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError Reviewed-by: okutsu - test/java/text/Bidi/Bug6665028.java From volker.simonis at gmail.com Tue Nov 26 09:57:17 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Nov 2013 10:57:17 +0100 Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <5293DC1F.4060205@oracle.com> References: <5293DC1F.4060205@oracle.com> Message-ID: Hi Phil, thanks a lot for the review. Please find my comments inline: On Tue, Nov 26, 2013 at 12:24 AM, Phil Race wrote: > Hi, > I see you've already received a ton of good feedback on this v2. > > I have just a few things to add. > I don't know what symlinks might exist on AIX but it seems odd to > me that you have :- > > 138 static char *fullAixFontPath[] = { > 139 "/usr/lpp/X11/lib/X11/fonts/Type1", > .. > > but the paths in the new file aix.fontconfig.properties look like this :- > > /usr/lib/X11/fonts/Type1/cour.pfa > > You're absolutely right. I've updated 'aix.fontconfig.properties' to contain the same absolute path like 'fontpath.c'. I've also added a comment which describes to which AIX-package the fonts belong to and to which locations they are sym-linked to. Also for the build to pick up a file called > *src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > *it seems like you should have added a section to handle this path to > jdk/makefiles/gendata/GenDataFontConfig.gmk > > That seems to be where the new build handles such files. > > Are you seeing the .bfc and .src files created ? > > You're right. But that was already added by the general AIX-build change "8024900: PPC64: Enable new build on AIX (jdk part)" ( http://hg.openjdk.java.net/ppc-aix-port/stage/jdk/diff/3ac08cd5e2e8/makefiles/GendataFontConfig.gmk ). And yes, the .bfc and .src files are created and copied to the right places. > At runtime it'll get picked up so so long as System.getProperty("os.name") > returns "aix" (all lower-case) so I think that's OK. Its the build time > part > I'd expect to see but don't. > > I did split the AIX change into several changes and the build changes have been reviewed separately: 8024265: PPC64: Enable new build on AIX ( https://bugs.openjdk.java.net/browse/JDK-8024265) 8024900: PPC64: Enable new build on AIX (jdk part) ( https://bugs.openjdk.java.net/browse/JDK-8024900) This change only contains the additional make changes which became necessary after I started to move AIX-specific files into their own jdk/src/aix/ directory. Everything else is already in place. I'll prepare and test a finaly webrev with all the changes from this review round today. Thanks a lot, Volker > -phil. > > > On 11/20/2013 10:26 AM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on AIX > net/browse/JDK-8024854>". The previous reviews can be found at the end >> of this mail in the references section. >> >> >> I've tried to address all the comments and suggestions from the first >> round and to further streamline the patch (it perfectly builds on >> Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The >> biggest change compared to the first review round is the new "aix/" >> subdirectory which I've now created under "jdk/src" and which contains >> AIX-only code. >> >> The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ < >> http://cr.openjdk.java.net/%7Esimonis/webrevs/8024854.v2/> >> >> >> Below (and in the webrev) you can find some comments which explain the >> changes to each file. In order to be able to push this big change, I need >> the approval of reviewers from the lib, net, svc, 2d, awt and sec groups. >> So please don't hesitate to jump at it - there are enough changes for >> everybody:) >> >> Thank you and best regards, >> Volker >> >> *References:* >> >> >> The following reviews have been posted so far (thanks Iris for collecting >> them :) >> >> - Alan Bateman (lib): Initial comments (16 Sep [2]) >> - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) >> - Michael McMahon (net): Initial comments (20 Sept [4]) >> - Steffan Larsen (svc): APPROVED (20 Sept [5]) >> - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments >> (15 Oct [7]) >> - Sean Mullan (sec): Initial comments (26 Sept [8]) >> >> [2]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001045.html >> [3]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001078.html >> [4]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001079.html >> [5]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001077.html >> [6]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001069.html >> [7]: http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/ >> 003826.html >> [8]: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/ >> 2013-September/001081.html >> >> >> *Detailed change description:* >> >> >> The new "jdk/src/aix" subdirectory contains the following new and >> AIX-specific files for now: >> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties >> src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/classes/sun/nio/fs/AixFileStore.java >> src/aix/classes/sun/nio/fs/AixFileSystem.java >> src/aix/classes/sun/nio/fs/AixFileSystemProvider.java >> src/aix/classes/sun/nio/fs/AixNativeDispatcher.java >> src/aix/classes/sun/tools/attach/AixAttachProvider.java >> src/aix/classes/sun/tools/attach/AixVirtualMachine.java >> src/aix/native/java/net/aix_close.c >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/sun/nio/fs/AixNativeDispatcher.c >> src/aix/native/sun/tools/attach/AixVirtualMachine.c >> src/aix/porting/porting_aix.c >> src/aix/porting/porting_aix.h >> >> >> src/aix/porting/porting_aix.c >> src/aix/porting/porting_aix.h >> >> * Added these two files for AIX relevant utility code. >> * Currently these files only contain an implementation of |dladdr| >> >> which is not available on AIX. >> * In the first review round the existing |dladdr| users in the code >> >> either called the version from the HotSpot on AIX >> (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a private >> >> copy of the whole implementation >> (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not >> >> necessary any more. >> >> The new file layout required some small changes to the makefiles to make >> them aware of the new directory locations: >> >> >> makefiles/CompileDemos.gmk >> >> * Add an extra argument to |SetupJVMTIDemo| which can be used to >> pass additional source locations. >> * Currently this is only used on AIX for the AIX porting utilities >> >> which are required by hprof. >> >> >> makefiles/lib/Awt2dLibraries.gmk >> makefiles/lib/ServiceabilityLibraries.gmk >> >> * On AIX add the sources of the AIX porting utilities to the build. >> >> They are required by >> |src/solaris/native/sun/awt/awt_LoadLibrary.c| and >> |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is not >> available on AIX. >> >> >> makefiles/lib/NioLibraries.gmk >> >> * Make the AIX-build aware of the new NIO source locations under >> |src/aix/native/sun/nio/|. >> >> >> makefiles/lib/NetworkingLibraries.gmk >> >> * Make the AIX-build aware of the new |aix_close.c| source location >> under |src/aix/native/java/net/|. >> >> >> src/share/bin/jli_util.h >> >> * Define |JLI_Lseek| on AIX. >> >> >> src/share/lib/security/java.security-aix >> >> * Provide default |java.security-aix| for AIX based on the latest >> >> Linux version as suggested by Sean Mullan. >> >> >> src/share/native/common/check_code.c >> >> * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which >> >> is legal, but the code in |check_code.c| does not handles this >> properly. So we wrap the two methods on AIX and return a non-NULL >> pointer even if we allocate 0 bytes. >> >> >> src/share/native/sun/awt/medialib/mlib_sys.c >> >> * |malloc| always returns 8-byte aligned pointers on AIX as well. >> >> >> src/share/native/sun/awt/medialib/mlib_types.h >> >> * Add AIX to the list of known platforms. >> >> >> src/share/native/sun/font/layout/KernTable.cpp >> >> * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is >> >> too common and may be defined in other headers as well as on the >> command line and |xlc| bails out on macro redefinitions with a >> different value. >> >> >> src/share/native/sun/security/ec/impl/ecc_impl.h >> >> * Define required types and macros on AIX. >> >> >> src/solaris/back/exec_md.c >> >> * AIX behaves like Linux in this case so check for it in the Linux >> branch. >> >> >> src/solaris/bin/java_md_solinux.c, >> src/solaris/bin/java_md_solinux.h >> >> * On AIX |LD_LIBRARY_PATH| is called |LIBPATH| >> * Always use |LD_LIBRARY_PATH| macro instead of using the string >> >> "|LD_LIBRARY_PATH|" directly to cope with different library path >> names. >> * Add |jre/lib//jli| to the standard library search path on >> >> AIX because the AIX linker doesn't support the |-rpath| option. >> * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in >> >> this case, AIX behaves like Linux. >> * Removed the definition of |JVM_DLL|, |JAVA_DLL| and >> >> |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros are >> redefined in the corresponding |.c| files anyway. >> >> >> src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties >> >> * Provide basic |fontconfig.properties|for AIX. >> >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix, >> src/aix/classes/sun/tools/attach/AixAttachProvider.java, >> src/aix/classes/sun/tools/attach/AixVirtualMachine.java, >> src/aix/native/sun/tools/attach/AixVirtualMachine.c >> >> * Provide AIX specific Java versions, mostly based on the >> >> corresponding Linux versions. >> >> >> src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProv >> ider.java >> src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java >> >> * Detect AIX operating system and return the corresponding channel >> >> and file system providers. >> >> >> src/solaris/classes/sun/nio/ch/Port.java >> >> * Add a callback function |unregisterImpl(int fd)| for >> >> implementations that need special handling when |fd| is removed >> and call it from |unregister(int fd)|. By default the >> >> implementation of |unregisterImpl(int fd)| is empty except for the >> derived |AixPollPort| class on AIX. >> >> >> src/solaris/demo/jvmti/hprof/hprof_md.c >> >> * Add AIX support. AIX mostly behaves like Linux, with the one >> >> exception that it has no |dladdr| functionality. >> * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX. >> >> >> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c >> >> * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory). >> >> >> src/solaris/native/common/jdk_util_md.h >> >> * Add AIX definitions of the |ISNANF| and |ISNAND| macros. >> >> >> src/solaris/native/java/io/io_util_md.c >> >> * AIX behaves like Linux in this case so check for it in the Linux >> branch. >> >> >> src/solaris/native/java/lang/UNIXProcess_md.c >> >> * AIX behaves mostly like Solraris in this case so adjust the ifdefs >> accordingly. >> >> >> src/solaris/native/java/lang/childproc.c >> >> * AIX does not understand '/proc/self' - it requires the real >> >> process ID to query the proc file system for the current process. >> >> >> src/solaris/native/java/net/NetworkInterface.c >> >> * Add AIX support into the Linux branch because AIX mostly behaves >> like AIX for IPv4. >> * AIX needs a special function to enumerate IPv6 interfaces and to >> query the MAC address. >> * Moved the declaration of |siocgifconfRequest| to the beginning a >> >> the function (as recommend by Michael McMahon) to remain C89 >> compatible. >> >> >> src/solaris/native/java/net/PlainSocketImpl.c >> >> * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL| >> >> if the socket is closed. The default error message is then confusing. >> >> >> src/aix/native/java/net/aix_close.c, >> src/share/native/java/net/net_util.c >> >> * As recommended by Michael McMahon and Alan Bateman I've move an >> >> adapted version of |linux_close.c| to >> |src/aix/native/java/net/aix_close.c| because we also need the >> file and socket wrappers on AIX. >> * Compared to the Linux version, we've added the initialization of >> >> some previously uninitialized data structures. >> * Also, on AIX we don't have |__attribute((constructor))| so we need >> >> to initialize manually (from |JNI_OnLoad()| in >> |src/share/native/java/net/net_util.c|. >> >> >> src/solaris/native/java/net/net_util_md.h >> >> * AIX needs the same workaround for I/O cancellation like Linux and >> MacOSX. >> >> >> src/solaris/native/java/net/net_util_md.c >> >> * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX. >> * On AIX we have to ignore failures due to |ENOBUFS| when setting >> the |SO_SNDBUF|/|SO_RCVBUF| socket options. >> >> >> src/solaris/native/java/util/TimeZone_md.c >> >> * Currently on AIX the only way to get the platform time zone is to >> >> read it from the |TZ| environment variable. >> >> >> src/solaris/native/sun/awt/awt_LoadLibrary.c >> >> * Use the |dladdr| from |porting_aix.{c,h}| on AIX. >> >> >> src/solaris/native/sun/awt/fontpath.c >> >> * Changed some macros from |if !defined(__linux__)| to |if >> >> defined(__solaris__)| because that's their real meaning. >> * Add AIX specific fontpath settings and library search paths for >> |libfontconfig.so|. >> >> >> src/solaris/native/sun/java2d/x11/X11SurfaceData.c >> >> * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| to >> avoid name clashes (|MIN| and |MAX| are much too common and thexy >> >> are already defined in some AIX system headers). >> >> >> src/solaris/native/sun/java2d/x11/XRBackendNative.c >> >> * Handle AIX like Solaris. >> >> >> src/solaris/native/sun/nio/ch/Net.c >> >> * Add AIX-specific includes and constant definitions. >> * On AIX "socket extensions for multicast source filters" support >> >> depends on the OS version. Check for this and throw appropriate >> exceptions if it is requested but not supported. This is needed to >> pass >> JCK-api/java_nio/channels/DatagramChannel/ >> DatagramChannel.html#Multicast >> >> >> src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c >> >> * On AIX |strerror()| is not thread-safe so we have to use >> |strerror_r()| instead. >> * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets 'result' to >> >> NULL for the directory stream end. Otherwise, 'errno' will contain >> the error code. >> * Handle some AIX corner cases for the results of the |statvfs64()| >> call. >> * On AIX |getgrgid_r()| returns ESRCH if group does not exist. >> >> >> src/solaris/native/sun/security/pkcs11/j2secmod_md.c >> >> * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX. >> >> >> test/java/lang/ProcessBuilder/Basic.java >> test/java/lang/ProcessBuilder/DestroyTest.java >> >> * Port this test to AIX and make it more robust (i.e. recognize the >> "C" locale as |isEnglish()|, ignore VM-warnings in the output, >> >> make sure the "grandchild" processes created by the test don't run >> too long (60s vs. 6666s) because in the case of test problems >> these processes will pollute the process space, make sure the test >> fails with an error and doesn't hang indefinitley in the case of a >> problem). >> >> *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this >> intended? >> >> Well, |_AIX| is defined in some system headers while |AIX| is defined by >> the build system. This is already used inconsistently (i.e. |__linux__| vs. >> |LINUX|) and in general I try to be consistent with the style of the file >> where I the changes are. That said, I changes most of the occurences of >> |AIX| to |_AIX|. >> >> *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are >> they supposed to be there? >> >> >> We currently don't support OS/400 (later renamed into i5/OS and currently >> called IBM i) in our OpenJDK port but we do support it in our internel, SAP >> JVM build. We stripped out all the extra OS/400 functionality from the port >> but in some places where there is common functionality needd by both, AIX >> and OS/400 the OS/400 support may still be visible in the OpenJDK port. I >> don't think this is a real problem and it helps us to keep our internel >> sources in sync with the OpenJDK port. That said, I think I've removed all >> the references to OS/400 now. >> >> >> > From david.r.chase at oracle.com Tue Nov 26 11:56:23 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 06:56:23 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <52940513.6010503@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> Message-ID: <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> On 2013-11-25, at 9:18 PM, David Holmes wrote: > We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? Does anyone have any problems with sun.misc.VM as a choice? I have to do a minor revision to the hotspot commit anyway. Is sun.misc.VM also loaded very early anyway? David From david.holmes at oracle.com Tue Nov 26 12:12:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 22:12:11 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> Message-ID: <5294901B.3080207@oracle.com> On 26/11/2013 9:56 PM, David Chase wrote: > > On 2013-11-25, at 9:18 PM, David Holmes wrote: >> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? > > Does anyone have any problems with sun.misc.VM as a choice? > I have to do a minor revision to the hotspot commit anyway. > Is sun.misc.VM also loaded very early anyway? No you would have to add it as for Unsafe. David > David > From david.r.chase at oracle.com Tue Nov 26 12:16:13 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 07:16:13 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5294901B.3080207@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> Message-ID: <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> On 2013-11-26, at 7:12 AM, David Holmes wrote: > On 26/11/2013 9:56 PM, David Chase wrote: >> >> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >> >> Does anyone have any problems with sun.misc.VM as a choice? >> I have to do a minor revision to the hotspot commit anyway. >> Is sun.misc.VM also loaded very early anyway? > > No you would have to add it as for Unsafe. But it's loaded early anyway as a normal consequence of other class loading, right? David From david.holmes at oracle.com Tue Nov 26 12:32:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 22:32:23 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> Message-ID: <529494D7.3080109@oracle.com> On 26/11/2013 10:16 PM, David Chase wrote: > > On 2013-11-26, at 7:12 AM, David Holmes wrote: >> On 26/11/2013 9:56 PM, David Chase wrote: >>> >>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>> >>> Does anyone have any problems with sun.misc.VM as a choice? >>> I have to do a minor revision to the hotspot commit anyway. >>> Is sun.misc.VM also loaded very early anyway? >> >> No you would have to add it as for Unsafe. > > But it's loaded early anyway as a normal consequence of other class loading, right? What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. David > David > From joel.franck at oracle.com Tue Nov 26 12:41:42 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 26 Nov 2013 12:41:42 +0000 Subject: hg: jdk8/tl/langtools: 8028428: strictfp allowed as annotation element modifier Message-ID: <20131126124146.5D77562860@hg.openjdk.java.net> Changeset: 3ea55d523981 Author: jfranck Date: 2013-11-26 13:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ea55d523981 8028428: strictfp allowed as annotation element modifier Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java + test/tools/javac/annotations/AnnotationTypeElementModifiers.java + test/tools/javac/annotations/AnnotationTypeElementModifiers.out From tristan.yan at oracle.com Tue Nov 26 12:47:13 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 26 Nov 2013 20:47:13 +0800 Subject: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java In-Reply-To: <96fe0ea6-4c0b-4e90-9c58-24e244a8cc15@default> References: <96fe0ea6-4c0b-4e90-9c58-24e244a8cc15@default> Message-ID: <52949851.9000407@oracle.com> Hi Alan Could you sponsor this small change for me if you're ok with this change. Thank you very much. Tristan On 11/20/2013 12:45 PM, Tristan Yan wrote: > Hi Everyone > > We have a test > java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that > was put into ProblemList because of bug JDK-6933803, this test has > been fixed in > http://hg.openjdk.java.net/jdk8/tl/jdk/diff/cb3ecb5e4ce5/test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java. > We have run a 1000 times loop test for making sure there is no issue > in this test anymore and we don't see any failure . I think it's good > time to bring this test back from ProblemList. > http://cr.openjdk.java.net/~ewang/tristan/JDK-6933803/webrev.00/test/ProblemList.txt.sdiff.html > > > Please let me know if you have comment on this. > Thank you. > > /Tristan Yan(Haibo Yan)/ From david.r.chase at oracle.com Tue Nov 26 13:12:40 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 08:12:40 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <529494D7.3080109@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> Message-ID: <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> On 2013-11-26, at 7:32 AM, David Holmes wrote: > On 26/11/2013 10:16 PM, David Chase wrote: >> >> On 2013-11-26, at 7:12 AM, David Holmes wrote: >>> On 26/11/2013 9:56 PM, David Chase wrote: >>>> >>>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>>> >>>> Does anyone have any problems with sun.misc.VM as a choice? >>>> I have to do a minor revision to the hotspot commit anyway. >>>> Is sun.misc.VM also loaded very early anyway? >>> >>> No you would have to add it as for Unsafe. >> >> But it's loaded early anyway as a normal consequence of other class loading, right? > > What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. 120 is earlier than 135, so by that measure it is superior. Do you see any other problems with the change? The method's not at all "Unsafe" in the technical sense of the word, so it is just a matter of choosing a good home. David From scolebourne at joda.org Tue Nov 26 13:20:21 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 26 Nov 2013 13:20:21 +0000 Subject: Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge must refuse null values] Message-ID: I took a quick look, but jumped back in horror at the start of the Javadoc for the new methods in Map. A Javadoc description should start with the positive, not the negative. I had to read the code to figure out what they are supposed to do. Here are the four poor Javadocs and some proposed enhacements: merge() "If the specified key is not already associated with ..." should be "Updates the value for an existing key merging the existing value with the specified value." "

" "....more detailed user-level explanation..." "

" "....now the more spec/edge case part..." ("if" is a terrible way to start the docs. Say what it does!) computeIfAbsent() "If the specified key is not already associated with a value (or is mapped..." should be "Associates the key with a value computed on demand if the key is not currently present." "

" "....more detailed user-level explanation..." "

" "....now the more spec/edge case part..." computeIfPresent() "If the value for the specified key is present and non-null," should be "Updates the value for an existing key." "

" "....more detailed user-level explanation..." "

" "....now the more spec/edge case part..." compute() "Attempts to compute a mapping for the specified key..." should be "Updates the value for a key, adding a new mapping if necessary." "

" "....more detailed user-level explanation..." "

" "....now the more spec/edge case part..." (attempts is negative, not positive) Similar problems seem to exist for "putIfAbsent". also... I have to say that I don't overly like the method name. "map.merge(...)" sounds like a bulk operation affecting the whole map (ie. like putAll). Assuming that the method cannot be renamed, it could be improved just by changing the method parameter names.: default V merge(K key, V valueToMerge, BiFunction mergeFunction) { "valueToMerge" implies that action will occur to the parameter. "mergeFunction" is much more meaningful that "remapping Function". Similar parameter name change, "mappingFunction" -> "valueCreationFunction" default V computeIfAbsent( K key, Function valueCreationFunction) { Similar parameter name change, "remappingFunction" -> "valueUpdateFunction" default V computeIfPresent( K key, BiFunction valueUpdateFunction) { Similar parameter name change, "remappingFunction" -> "valueUpdateFunction" default V compute( K key, BiFunction valueUpdateFunction) { also... Can you use HashSet::new in the example code? In general, all these new methods are written in a spec style, rather than a user friendly style, and I'm afraid I don't think thats sufficient. Stephen On 26 November 2013 04:32, Mike Duigou wrote: > > On Nov 24 2013, at 16:31 , David Holmes wrote: > >> Hi Mike, >> >> There is still no clear spec for what should happen if the param value is null. > > I feel very uncomfortable the status quo of with null being ignored, used for a sentinel and also as value. The relations between null and values in this method are just too complicated. > > Currently: > > - The provided value may be either null or non-null. Is null a legal value? It depends upon: > - Is there an existing value? > - Does the Map allow null values? > - Does the function allow null values? > - Existing null values are treated as absent. > - If a null value is passed should we remove this mapping or add it to the map? > - null might not be accepted by the map > - The associated value would still be regarded as absent for future operations. > - The function may return null to signal "remove". > > In particular I dislike adding a null entry to the map if there is no current mapping (or mapped to null). It seems like it should be invariant whether we end up with an associated value. If null is used to signify "remove" then map.contains(key) will return variable results depending upon the initial state. Having the behaviour vary based upon whether the map allows null values would be even worse. > > So I would like to suggest that we require value to be non-null. I have provisionally updated the spec and impls accordingly. > >> The parenthesized part is wrong. > > I think that's overzealous copying from compute(). I have removed it. > >> >> Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading. > > I will correct this. More changes were made than I originally expected. New synopsis will be "Map.merge implementations should refuse null value param" > > I have updated the webrev. > > http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/ > > Thanks, > > Mike > >> >> Thanks, >> David >> >> On 23/11/2013 10:25 AM, Mike Duigou wrote: >>> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. >>> >>> I've posted a webrev here: >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ >>> >>> There is an identical change in ConcurrentMap's merge(). >>> >>> Mike >>> >>> On Nov 22 2013, at 16:01 , Henry Jen wrote: >>> >>>> >>>> On 11/21/2013 06:33 PM, David Holmes wrote: >>>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>>>>> While I agree that case should be specified, I'm not certain I follow why >>>>>> that's what's going on here. >>>>>> >>>>>> The weird condition is that if oldValue is null, not value; oldValue >>>>>> is the >>>>>> old result of map.get(key). The Javadoc seems not just unspecified, but >>>>>> actively wrong. Here's a worked example: >>>>>> >>>>>> Map map = new HashMap<>(); >>>>>> map.merge("foo", 3, Integer::plus); >>>>>> Integer fooValue = map.get("foo"); >>>>>> >>>>>> Going through the Javadoc-specified default implementation: >>>>>> >>>>>> V oldValue = map.get(key); // oldValue is null >>>>>> V newValue = (oldValue == null) ? value : >>>>>> remappingFunction.apply(oldValue, value); >>>>>> // newValue is set to value, which is 3 >>>>>> if (newValue == null) // newValue is nonnull, branch not taken >>>>>> map.remove(key); >>>>>> else if (oldValue == null) // oldValue is null, branch taken >>>>>> map.remove(key); // removes the entry from the map >>>>>> else // else if was already triggered, branch not taken >>>>>> map.put(key, newValue); >>>>>> >>>> >>>> Seems like a document bug to me, we should fix this @implSpec. >>>> >>>> Cheers, >>>> Henry >>>> >>> > From thomas.stuefe at gmail.com Tue Nov 26 13:27:32 2013 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 26 Nov 2013 14:27:32 +0100 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) Message-ID: Hello, My name is Thomas Stuefe, I'm with SAP and working on the SAP JVM. I'd like to propose a fix for https://bugs.openjdk.java.net/browse/JDK-8028804 . This may also be related to https://bugs.openjdk.java.net/browse/JDK-8028216. The problem: The following call sequence: Deflater.deflate() Deflater.setLevel() / Deflater.setStrategy() Deflater.deflate() will cause at C level in Deflater.c: zlib deflate() zlib deflateParams() zlib deflate() . Zlib's deflateParams() has the following issue: if the stream has unflushed data, it will attempt to flush it. It will do this by calling - once, a single time - deflate(..., Z_BLOCK). After that it will change the compression parameters for the stream, which may switch the compression function used for the next call to deflate(). If the output buffer was too small to hold the whole output, output will not have been completely flushed before compression function is changed. As a result the compressed block may be corrupted. As a reprocase, see the jtreg test in the webrev below or the repro case attached to the bug report: http://cr.openjdk.java.net/~simonis/webrevs/8028804/ This is a bug we encountered when dealing with Apache's FlushableGZIPOutputStream ( http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/coyote/http11/filters/FlushableGZIPOutputStream.html), which in older versions implements flushing by switching the compression level. The real problem is that zlib deflateParams(), unlike zlib deflate(), does not handle output-buffer-too-small correctly. The workaround is to fully flush the stream before calling deflateParams(), so that the deflate() call inside deflateParams() becomes a noop. This fix consists of several parts: - Introduces a new function in the zlib: deflateParams2() which is a 1:1 copy of deflateParams() but behaves differently if the output buffer was too small. In that case it leaves the compression parameters unchanged and returns a newly introduced return code (Z_UNFINISHED_FLUSH). The caller would have to repeat the call to deflateParams2() with the same parameters and more output buffer (similar to how deflate() handles this situation). Note: I did not just change deflateParams() because I did not want to hunt down and change all callers. - In Deflate.c, Deflater.deflateBytes(), call deflateParams2() and handle Z_UNFINISHED_FLUSH by *not* resetting the flag Deflater.setParams; that way, on the next call to Deflater.deflateBytes(), deflateParams2() will be called again until the flush is completed. - Additionally, for the call to zlib deflateParams2(), I set the input to 0 (z_stream->avail_in). So I defer handing down any new input to the stream as long as the old input is not flushed. I do this for two reasons: 1) This would be the expected behaviour for any caller who calls "Deflater.setLevel", then "Deflater.deflate" and would expect the new input data to be compressed with the new level 2) It prevents "endless flushes" because we provide new input data on every call The intent of this fix is to transparently fix the Deflater for users of FlushableGZIPOutputStream and everyone else who changes the compression parameters in the middle of an unflushed block. Note that this is one way to fix it; it could also be fixed differently, by not changing the zlib at all, but this would make the code more difficult to read and introduce unnecessary flushes (zlib deflateParams only flushes if needed based on information we do not hanve in Deflater.c). I am curious what you think; do you think this is a valid fix? Kind Regards, Thomas From scolebourne at joda.org Tue Nov 26 13:35:47 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 26 Nov 2013 13:35:47 +0000 Subject: RFR: 8029055: Map.merge must refuse null values In-Reply-To: <63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com> References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> <52929A59.20204@oracle.com> <63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com> Message-ID: See the new thread for the general Javadoc issues. I'll focus on null here. Given a map {"Key" -> null} I find the notion that putIfAbsent() or computeIfAbsent() ignore the existing mapping just plain wrong. While I can rationalise it (just) it is a horrible reworking of the meaning of "absent". Similarly, for "computeIfPresent()", my expectation is that the mapping is present, and that the null should be an input to the function. Yes, I get that nulls in collections are a pain, but trying to redefine the meaning of "absent" is more of a pain. I'm aware that ConcurrentMap makes things interesting, but these two just look wrong. So, my rules would be - if an existing mapping has a null value, then the mapping is "present" and not "absent" (only affects methods with those words in their name) - none of these methods should try to add/update a mapping with a null value - null returned from a function means remove (or is invalid) - a null value parameter is invalid - merge where the existing mapping has a null value should not pass the null to the function Stephen On 26 November 2013 04:32, Mike Duigou wrote: > > On Nov 24 2013, at 16:31 , David Holmes wrote: > >> Hi Mike, >> >> There is still no clear spec for what should happen if the param value is null. > > I feel very uncomfortable the status quo of with null being ignored, used for a sentinel and also as value. The relations between null and values in this method are just too complicated. > > Currently: > > - The provided value may be either null or non-null. Is null a legal value? It depends upon: > - Is there an existing value? > - Does the Map allow null values? > - Does the function allow null values? > - Existing null values are treated as absent. > - If a null value is passed should we remove this mapping or add it to the map? > - null might not be accepted by the map > - The associated value would still be regarded as absent for future operations. > - The function may return null to signal "remove". > > In particular I dislike adding a null entry to the map if there is no current mapping (or mapped to null). It seems like it should be invariant whether we end up with an associated value. If null is used to signify "remove" then map.contains(key) will return variable results depending upon the initial state. Having the behaviour vary based upon whether the map allows null values would be even worse. > > So I would like to suggest that we require value to be non-null. I have provisionally updated the spec and impls accordingly. > >> The parenthesized part is wrong. > > I think that's overzealous copying from compute(). I have removed it. > >> >> Also you have changed the method implementation not just the implDoc so the bug synopsis is somewhat misleading. > > I will correct this. More changes were made than I originally expected. New synopsis will be "Map.merge implementations should refuse null value param" > > I have updated the webrev. > > http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/ > > Thanks, > > Mike > >> >> Thanks, >> David >> >> On 23/11/2013 10:25 AM, Mike Duigou wrote: >>> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue. >>> >>> I've posted a webrev here: >>> >>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ >>> >>> There is an identical change in ConcurrentMap's merge(). >>> >>> Mike >>> >>> On Nov 22 2013, at 16:01 , Henry Jen wrote: >>> >>>> >>>> On 11/21/2013 06:33 PM, David Holmes wrote: >>>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: >>>>>> While I agree that case should be specified, I'm not certain I follow why >>>>>> that's what's going on here. >>>>>> >>>>>> The weird condition is that if oldValue is null, not value; oldValue >>>>>> is the >>>>>> old result of map.get(key). The Javadoc seems not just unspecified, but >>>>>> actively wrong. Here's a worked example: >>>>>> >>>>>> Map map = new HashMap<>(); >>>>>> map.merge("foo", 3, Integer::plus); >>>>>> Integer fooValue = map.get("foo"); >>>>>> >>>>>> Going through the Javadoc-specified default implementation: >>>>>> >>>>>> V oldValue = map.get(key); // oldValue is null >>>>>> V newValue = (oldValue == null) ? value : >>>>>> remappingFunction.apply(oldValue, value); >>>>>> // newValue is set to value, which is 3 >>>>>> if (newValue == null) // newValue is nonnull, branch not taken >>>>>> map.remove(key); >>>>>> else if (oldValue == null) // oldValue is null, branch taken >>>>>> map.remove(key); // removes the entry from the map >>>>>> else // else if was already triggered, branch not taken >>>>>> map.put(key, newValue); >>>>>> >>>> >>>> Seems like a document bug to me, we should fix this @implSpec. >>>> >>>> Cheers, >>>> Henry >>>> >>> > From Alan.Bateman at oracle.com Tue Nov 26 13:55:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Nov 2013 13:55:43 +0000 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) In-Reply-To: References: Message-ID: <5294A85F.2090903@oracle.com> On 26/11/2013 13:27, Thomas St?fe wrote: > : > > The real problem is that zlib deflateParams(), unlike zlib deflate(), does > not handle output-buffer-too-small correctly. The workaround is to fully > flush the stream before calling deflateParams(), so that the deflate() call > inside deflateParams() becomes a noop. > I think you're right but I wonder if this is something that needs to be brought upstream to the zlib project in order to get the support in deflateParams (or a new function). My concern with having a dependency on a patched zlib is that I don't know how it will work when using the system libz (the default on Mac, or on Linux if you configure with --with-zlib=system). -Alan. From thomas.stuefe at gmail.com Tue Nov 26 14:06:42 2013 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 26 Nov 2013 15:06:42 +0100 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) In-Reply-To: <5294A85F.2090903@oracle.com> References: <5294A85F.2090903@oracle.com> Message-ID: Hi Alan, On 26 November 2013 14:55, Alan Bateman wrote: > I think you're right but I wonder if this is something that needs to be > brought upstream to the zlib project in order to get the support in > deflateParams (or a new function). > I reported this bug to the authors of the zlib and they confirmed the bug and the workaround. But even if they fix the current zlib, the jdk uses an older version, so this will not help us now, or? > > > My concern with having a dependency on a patched zlib is that I don't know > how it will work when using the system libz (the default on Mac, or on > Linux if you configure with --with-zlib=system). That would break. Probably just prevents libzip.so from loading because of missing imports. Okay, I can try to build a different workaround which leaves the zlib alone. ..Thomas From thomas.stuefe at gmail.com Tue Nov 26 14:18:18 2013 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Tue, 26 Nov 2013 15:18:18 +0100 Subject: Why are assertions in zlib on Unix switched off? Message-ID: Hi everyone, When building the zlib on Unix platforms, zlib assertions are switched off explicitly using -UDEBUG: 84 ifeq ($(PLATFORM), windows) 87 else 88 CPPFLAGS += -UDEBUG 89 endif This switches off assertions inside the zlib (see zutil.h, zutil,c inside the zlib). Does anyone know why this was done? And why not for windows? Background: I investigate a case where we get a zlib assert on Windows and I wondered why this did not show up on Unix. Kind Regards, Thomas From Alan.Bateman at oracle.com Tue Nov 26 14:24:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Nov 2013 14:24:06 +0000 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) In-Reply-To: References: <5294A85F.2090903@oracle.com> Message-ID: <5294AF06.1050502@oracle.com> On 26/11/2013 14:06, Thomas St?fe wrote: > Hi Alan, > > On 26 November 2013 14:55, Alan Bateman > wrote: > > I think you're right but I wonder if this is something that needs > to be brought upstream to the zlib project in order to get the > support in deflateParams (or a new function). > > > I reported this bug to the authors of the zlib and they confirmed the > bug and the workaround. But even if they fix the current zlib, the jdk > uses an older version, so this will not help us now, or? My personal view is that we should link to libz where possible (already so on Mac, but not the default on Linux or Solaris). Clearly we still have to allow for platforms where it doesn't exist (Windows only I think) and in that case we should periodically update it (as we did in both JDK 7 and JDK 8). It may be time to look at upgrading it again (for JDK 9 as this is not something to touch in the end-game of a release). -Alan From jan.lahoda at oracle.com Tue Nov 26 14:40:55 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 26 Nov 2013 14:40:55 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20131126144102.1944F62864@hg.openjdk.java.net> Changeset: 8acb838c9b79 Author: jlahoda Date: 2013-11-26 15:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8acb838c9b79 8026374: javac accepts void as a method parameter Summary: Changing Check.validate to reject void types. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/declaration/method/MethodVoidParameter.java + test/tools/javac/declaration/method/MethodVoidParameter.out Changeset: 756ae3791c45 Author: jlahoda Date: 2013-11-26 15:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/756ae3791c45 8027789: Access method for Outer.super.m() references indirect superclass Summary: Internally convert the qualified super access to an equivalent of an unqualified super access inside the access method. Reviewed-by: vromero, jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/expression/_super/NonDirectSuper/Base.java + test/tools/javac/expression/_super/NonDirectSuper/NonDirectSuper.java + test/tools/javac/expression/_super/NonDirectSuper/Target11.java From chris.hegarty at oracle.com Tue Nov 26 15:16:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 26 Nov 2013 15:16:41 +0000 Subject: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java In-Reply-To: <52949851.9000407@oracle.com> References: <96fe0ea6-4c0b-4e90-9c58-24e244a8cc15@default> <52949851.9000407@oracle.com> Message-ID: Tristan, The removal of this test from the ProblemList.txt looks like the right thing to do. I can push this for you. -Chris. On 26 Nov 2013, at 12:47, Tristan Yan wrote: > Hi Alan > Could you sponsor this small change for me if you're ok with this change. > Thank you very much. > Tristan > > On 11/20/2013 12:45 PM, Tristan Yan wrote: >> Hi Everyone >> >> We have a test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that was put into ProblemList because of bug JDK-6933803, this test has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/diff/cb3ecb5e4ce5/test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java. We have run a 1000 times loop test for making sure there is no issue in this test anymore and we don't see any failure . I think it's good time to bring this test back from ProblemList. >> http://cr.openjdk.java.net/~ewang/tristan/JDK-6933803/webrev.00/test/ProblemList.txt.sdiff.html >> >> Please let me know if you have comment on this. >> Thank you. >> >> /Tristan Yan(Haibo Yan)/ > From tristan.yan at oracle.com Tue Nov 26 15:47:39 2013 From: tristan.yan at oracle.com (Tristan Yan) Date: Tue, 26 Nov 2013 23:47:39 +0800 Subject: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java In-Reply-To: References: <96fe0ea6-4c0b-4e90-9c58-24e244a8cc15@default> <52949851.9000407@oracle.com> Message-ID: <5294C29B.4010502@oracle.com> Thank you. Chris. Tristan On 11/26/2013 11:16 PM, Chris Hegarty wrote: > Tristan, > > The removal of this test from the ProblemList.txt looks like the right thing to do. I can push this for you. > > -Chris. > > On 26 Nov 2013, at 12:47, Tristan Yan wrote: > >> Hi Alan >> Could you sponsor this small change for me if you're ok with this change. >> Thank you very much. >> Tristan >> >> On 11/20/2013 12:45 PM, Tristan Yan wrote: >>> Hi Everyone >>> >>> We have a test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that was put into ProblemList because of bug JDK-6933803, this test has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/diff/cb3ecb5e4ce5/test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java. We have run a 1000 times loop test for making sure there is no issue in this test anymore and we don't see any failure . I think it's good time to bring this test back from ProblemList. >>> http://cr.openjdk.java.net/~ewang/tristan/JDK-6933803/webrev.00/test/ProblemList.txt.sdiff.html >>> >>> Please let me know if you have comment on this. >>> Thank you. >>> >>> /Tristan Yan(Haibo Yan)/ From Alan.Bateman at oracle.com Tue Nov 26 16:09:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Nov 2013 16:09:03 +0000 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5293C676.7020304@oracle.com> References: <5293C676.7020304@oracle.com> Message-ID: <5294C79F.1080907@oracle.com> On 25/11/2013 21:51, huizhe wang wrote: > Hi, > > This is a patch to fix an error in StAX factories' newFactory(String > factoryId, ClassLoader classLoader). In the 3 step of the > documentation, it should have stated that the specified ClassLoader is > used. > > http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/webrev/ The change looks good to me in that it makes these strange factory methods somewhat usable. -Alan From david.r.chase at oracle.com Tue Nov 26 16:16:19 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 11:16:19 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> Message-ID: <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> On 2013-11-26, at 8:12 AM, David Chase wrote: > On 2013-11-26, at 7:32 AM, David Holmes wrote: >> On 26/11/2013 10:16 PM, David Chase wrote: >>> >>> On 2013-11-26, at 7:12 AM, David Holmes wrote: >>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>> >>>>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>>>> >>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>> I have to do a minor revision to the hotspot commit anyway. >>>>> Is sun.misc.VM also loaded very early anyway? >>>> >>>> No you would have to add it as for Unsafe. >>> >>> But it's loaded early anyway as a normal consequence of other class loading, right? >> >> What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. > > 120 is earlier than 135, so by that measure it is superior. > Do you see any other problems with the change? > The method's not at all "Unsafe" in the technical sense of the word, so it is just a matter of choosing a good home. On further investigation, change to sun.misc.VM would be the first time that hotspot knows of the existence of sun.misc.VM; sun.misc.Unsafe is already filled with methods that the runtime knows about (intrinsics, etc). I think Unsafe is better. David From volker.simonis at gmail.com Tue Nov 26 16:23:37 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Nov 2013 17:23:37 +0100 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: Hi, thanks to everybody for the prompt and helpful reviews. Here comes the final webrev which incorporates all the corrections and suggestions from the second review round: http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ I've successfully build (and run some smoke tests) with these changes on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, MacOSX and AIX (5.3, 7.1). So if nobody vetoes these changes are ready for push into our staging repository. @Vladimir: can I push them or do you want to run them trough JPRT? Thank you and best regards, Volker PS: compared to the last webrev ( http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/), I've slightly changed the following files: makefiles/lib/Awt2dLibraries.gmk makefiles/lib/NetworkingLibraries.gmk makefiles/Setup.gmk src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties src/aix/classes/sun/nio/ch/AixPollPort.java src/aix/classes/sun/nio/fs/AixFileSystem.java src/aix/native/java/net/aix_close.c src/aix/porting/porting_aix.c src/share/native/java/net/net_util.c src/share/native/java/net/net_util.h src/share/native/sun/awt/medialib/mlib_sys.c src/solaris/bin/java_md_solinux.c src/solaris/classes/sun/nio/ch/Port.java src/solaris/native/java/net/net_util_md.c src/solaris/native/sun/java2d/x11/XRBackendNative.c src/solaris/native/sun/management/OperatingSystemImpl.c src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c src/windows/native/java/net/net_util_md.c Most of the changes are cosmetic, except the ones in: src/share/native/java/net/net_util.c src/share/native/java/net/net_util.h src/solaris/native/java/net/net_util_md.c src/windows/native/java/net/net_util_md.c where I renamed 'initLocalAddrTable()' to 'platformInit()'. For AIX, this method will now call 'aix_close_init()' as suggested by Alan. The changes to src/solaris/native/com/sun/ management/UnixOperatingSystem_md.c are now in src/solaris/native/sun/management/OperatingSystemImpl.c because that file was moved by an upstream change. On Wed, Nov 20, 2013 at 7:26 PM, Volker Simonis wrote: > Hi, > > this is the second review round for "8024854: Basic changes and files to > build the class library on AIX". > The previous reviews can be found at the end of this mail in the references > section. > > I've tried to address all the comments and suggestions from the first > round and to further streamline the patch (it perfectly builds on > Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The > biggest change compared to the first review round is the new "aix/" > subdirectory which I've now created under "jdk/src" and which contains > AIX-only code. > > The webrev is against our http://hg.openjdk.java.net/ppc-aix-port/stagerepository which has been recently synchronised with the jdk8 master: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > > Below (and in the webrev) you can find some comments which explain the > changes to each file. In order to be able to push this big change, I need > the approval of reviewers from the lib, net, svc, 2d, awt and sec groups. > So please don't hesitate to jump at it - there are enough changes for > everybody:) > > Thank you and best regards, > Volker > > *References:* > > The following reviews have been posted so far (thanks Iris for collecting > them :) > > - Alan Bateman (lib): Initial comments (16 Sep [2]) > - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) > - Michael McMahon (net): Initial comments (20 Sept [4]) > - Steffan Larsen (svc): APPROVED (20 Sept [5]) > - Phil Race (2d): Initial comments (18 Sept [6]); Additional comments > (15 Oct [7]) > - Sean Mullan (sec): Initial comments (26 Sept [8]) > > [2]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html > [3]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html > [4]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html > [5]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html > [6]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html > [7]: > http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html > [8]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html > > > *Detailed change description:* > > The new "jdk/src/aix" subdirectory contains the following new and > AIX-specific files for now: > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileStore.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/classes/sun/nio/fs/AixFileSystemProvider.java > src/aix/classes/sun/nio/fs/AixNativeDispatcher.java > src/aix/classes/sun/tools/attach/AixAttachProvider.java > src/aix/classes/sun/tools/attach/AixVirtualMachine.java > src/aix/native/java/net/aix_close.c > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/sun/nio/fs/AixNativeDispatcher.c > src/aix/native/sun/tools/attach/AixVirtualMachine.c > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > - Added these two files for AIX relevant utility code. > - Currently these files only contain an implementation of dladdr which > is not available on AIX. > - In the first review round the existing dladdr users in the code > either called the version from the HotSpot on AIX ( > src/solaris/native/sun/awt/awt_LoadLibrary.c) or had a private copy of > the whole implementation (src/solaris/demo/jvmti/hprof/hprof_md.c). > This is now not necessary any more. > > The new file layout required some small changes to the makefiles to make > them aware of the new directory locations: > > makefiles/CompileDemos.gmk > > - Add an extra argument to SetupJVMTIDemo which can be used to pass > additional source locations. > - Currently this is only used on AIX for the AIX porting utilities > which are required by hprof. > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/ServiceabilityLibraries.gmk > > - On AIX add the sources of the AIX porting utilities to the build. > They are required by src/solaris/native/sun/awt/awt_LoadLibrary.c and > src/solaris/demo/jvmti/hprof/hprof_md.c because dladdr is not > available on AIX. > > makefiles/lib/NioLibraries.gmk > > - Make the AIX-build aware of the new NIO source locations under > src/aix/native/sun/nio/. > > makefiles/lib/NetworkingLibraries.gmk > > - Make the AIX-build aware of the new aix_close.c source location > under src/aix/native/java/net/. > > src/share/bin/jli_util.h > > - Define JLI_Lseek on AIX. > > src/share/lib/security/java.security-aix > > - Provide default java.security-aix for AIX based on the latest Linux > version as suggested by Sean Mullan. > > src/share/native/common/check_code.c > > - On AIX malloc(0) and calloc(0, ...) return a NULL pointer, which is > legal, but the code in check_code.c does not handles this properly. So > we wrap the two methods on AIX and return a non-NULL pointer even if we > allocate 0 bytes. > > src/share/native/sun/awt/medialib/mlib_sys.c > > - malloc always returns 8-byte aligned pointers on AIX as well. > > src/share/native/sun/awt/medialib/mlib_types.h > > - Add AIX to the list of known platforms. > > src/share/native/sun/font/layout/KernTable.cpp > > - Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too > common and may be defined in other headers as well as on the command line > and xlc bails out on macro redefinitions with a different value. > > src/share/native/sun/security/ec/impl/ecc_impl.h > > - Define required types and macros on AIX. > > src/solaris/back/exec_md.c > > - AIX behaves like Linux in this case so check for it in the Linux > branch. > > src/solaris/bin/java_md_solinux.c, > src/solaris/bin/java_md_solinux.h > > - On AIX LD_LIBRARY_PATH is called LIBPATH > - Always use LD_LIBRARY_PATH macro instead of using the string " > LD_LIBRARY_PATH" directly to cope with different library path names. > - Add jre/lib//jli to the standard library search path on AIX > because the AIX linker doesn't support the -rpath option. > - Replace #ifdef __linux__ by #ifndef __solaris__ because in this > case, AIX behaves like Linux. > - Removed the definition of JVM_DLL, JAVA_DLL and LD_LIBRARY_PATH from > java_md_solinux.h because the macros are redefined in the > corresponding .c files anyway. > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > - Provide basic fontconfig.propertiesfor AIX. > > src/solaris/classes/java/lang/UNIXProcess.java.aix, > src/aix/classes/sun/tools/attach/AixAttachProvider.java, > src/aix/classes/sun/tools/attach/AixVirtualMachine.java, > src/aix/native/sun/tools/attach/AixVirtualMachine.c > > - Provide AIX specific Java versions, mostly based on the > corresponding Linux versions. > > src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java > src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java > > - Detect AIX operating system and return the corresponding channel and > file system providers. > > src/solaris/classes/sun/nio/ch/Port.java > > - Add a callback function unregisterImpl(int fd) for implementations > that need special handling when fd is removed and call it from unregister(int > fd). By default the implementation of unregisterImpl(int fd) is empty > except for the derived AixPollPort class on AIX. > > src/solaris/demo/jvmti/hprof/hprof_md.c > > - Add AIX support. AIX mostly behaves like Linux, with the one > exception that it has no dladdr functionality. > - Use the dladdr implementation from porting_aix.{c,h} on AIX. > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c > > - Adapt for AIX (i.e. use libperfstat on AIX to query OS memory). > > src/solaris/native/common/jdk_util_md.h > > - Add AIX definitions of the ISNANF and ISNAND macros. > > src/solaris/native/java/io/io_util_md.c > > - AIX behaves like Linux in this case so check for it in the Linux > branch. > > src/solaris/native/java/lang/UNIXProcess_md.c > > - AIX behaves mostly like Solraris in this case so adjust the ifdefs > accordingly. > > src/solaris/native/java/lang/childproc.c > > - AIX does not understand '/proc/self' - it requires the real process > ID to query the proc file system for the current process. > > src/solaris/native/java/net/NetworkInterface.c > > - Add AIX support into the Linux branch because AIX mostly behaves > like AIX for IPv4. > - AIX needs a special function to enumerate IPv6 interfaces and to > query the MAC address. > - Moved the declaration of siocgifconfRequest to the beginning a the > function (as recommend by Michael McMahon) to remain C89 compatible. > > src/solaris/native/java/net/PlainSocketImpl.c > > - On AIX (like on Solaris) setsockopt will set errno to EINVAL if the > socket is closed. The default error message is then confusing. > > src/aix/native/java/net/aix_close.c, > src/share/native/java/net/net_util.c > > - As recommended by Michael McMahon and Alan Bateman I've move an > adapted version of linux_close.c to src/aix/native/java/net/aix_close.cbecause we also need the file and socket wrappers on AIX. > - Compared to the Linux version, we've added the initialization of > some previously uninitialized data structures. > - Also, on AIX we don't have __attribute((constructor)) so we need to > initialize manually (from JNI_OnLoad() in > src/share/native/java/net/net_util.c. > > src/solaris/native/java/net/net_util_md.h > > - AIX needs the same workaround for I/O cancellation like Linux and > MacOSX. > > src/solaris/native/java/net/net_util_md.c > > - SO_REUSEADDR is called SO_REUSEPORT on AIX. > - On AIX we have to ignore failures due to ENOBUFS when setting the > SO_SNDBUF/SO_RCVBUF socket options. > > src/solaris/native/java/util/TimeZone_md.c > > - Currently on AIX the only way to get the platform time zone is to > read it from the TZ environment variable. > > src/solaris/native/sun/awt/awt_LoadLibrary.c > > - Use the dladdr from porting_aix.{c,h} on AIX. > > src/solaris/native/sun/awt/fontpath.c > > - Changed some macros from if !defined(__linux__) to if > defined(__solaris__) because that's their real meaning. > - Add AIX specific fontpath settings and library search paths for > libfontconfig.so. > > src/solaris/native/sun/java2d/x11/X11SurfaceData.c > > - Rename the MIN and MAX macros to XSD_MIN and XSD_MAX to avoid name > clashes (MIN and MAX are much too common and thexy are already defined > in some AIX system headers). > > src/solaris/native/sun/java2d/x11/XRBackendNative.c > > - Handle AIX like Solaris. > > src/solaris/native/sun/nio/ch/Net.c > > - Add AIX-specific includes and constant definitions. > - On AIX "socket extensions for multicast source filters" support > depends on the OS version. Check for this and throw appropriate exceptions > if it is requested but not supported. This is needed to pass > JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast > > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > > - On AIX strerror() is not thread-safe so we have to use strerror_r()instead. > - On AIX readdir_r() returns EBADF (i.e. '9') and sets 'result' to > NULL for the directory stream end. Otherwise, 'errno' will contain the > error code. > - Handle some AIX corner cases for the results of the statvfs64() call. > - On AIX getgrgid_r() returns ESRCH if group does not exist. > > src/solaris/native/sun/security/pkcs11/j2secmod_md.c > > - Use RTLD_LAZY instead of RTLD_NOLOAD on AIX. > > test/java/lang/ProcessBuilder/Basic.java > test/java/lang/ProcessBuilder/DestroyTest.java > > - Port this test to AIX and make it more robust (i.e. recognize the > "C" locale as isEnglish(), ignore VM-warnings in the output, make sure > the "grandchild" processes created by the test don't run too long (60s vs. > 6666s) because in the case of test problems these processes will pollute > the process space, make sure the test fails with an error and doesn't hang > indefinitley in the case of a problem). > > *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is this > intended? > > Well, _AIX is defined in some system headers while AIX is defined by the > build system. This is already used inconsistently (i.e. __linux__ vs. > LINUX) and in general I try to be consistent with the style of the file > where I the changes are. That said, I changes most of the occurences of > AIX to _AIX. > > *Q (Alan Bateman):* There are a few changes for OS/400 in the patch, are > they supposed to be there? > > We currently don't support OS/400 (later renamed into i5/OS and currently > called IBM i) in our OpenJDK port but we do support it in our internel, SAP > JVM build. We stripped out all the extra OS/400 functionality from the port > but in some places where there is common functionality needd by both, AIX > and OS/400 the OS/400 support may still be visible in the OpenJDK port. I > don't think this is a real problem and it helps us to keep our internel > sources in sync with the OpenJDK port. That said, I think I've removed all > the references to OS/400 now. > > From Alan.Bateman at oracle.com Tue Nov 26 17:03:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Nov 2013 17:03:15 +0000 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: <5294D453.5050402@oracle.com> On 26/11/2013 16:23, Volker Simonis wrote: > Hi, > > thanks to everybody for the prompt and helpful reviews. Here comes the > final webrev which incorporates all the corrections and suggestions from > the second review round: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ > > I've successfully build (and run some smoke tests) with these changes on > Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, MacOSX and > AIX (5.3, 7.1). > I've skimmed over the last webrev with focus on: NetworkingLibraries.gmk where I see this is now fixed for all platforms. net_util.* and the platform specific net_util_md.* where I see you've added platformInit so it's much cleaner. UnixNativeDispatcher.c where the error translation is now removed (and looks fine). So overall it looks good to me and should be pushed to the staging forest once you hear from others that commented previously. -Alan From martinrb at google.com Tue Nov 26 17:35:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Nov 2013 09:35:58 -0800 Subject: Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge must refuse null values] In-Reply-To: References: Message-ID: I haven't looked in depth, but I agree with Stephen's analysis. This API and its javadoc needs work. E.g. It's not clear that the purpose of Map.compute is to *update* the mapping for key in the map. Getting these right is hard; you have the "null" value/sentinel confusion and the confusion that a single method may (or may not) either add or remove a mapping for key. Instead of "The default implementation makes no guarantees about synchronization or atomicity properties of this method." we should boldly say that the default implementation is *not* atomic, even if the underlying map is. On Tue, Nov 26, 2013 at 5:20 AM, Stephen Colebourne wrote: > I took a quick look, but jumped back in horror at the start of the > Javadoc for the new methods in Map. A Javadoc description should start > with the positive, not the negative. I had to read the code to figure > out what they are supposed to do. Here are the four poor Javadocs and > some proposed enhacements: > > merge() > "If the specified key is not already associated with ..." > should be > "Updates the value for an existing key merging the existing value with > the specified value." > "

" > "....more detailed user-level explanation..." > "

" > "....now the more spec/edge case part..." > ("if" is a terrible way to start the docs. Say what it does!) > > > computeIfAbsent() > "If the specified key is not already associated with a value (or is > mapped..." > should be > "Associates the key with a value computed on demand if the key is not > currently present." > "

" > "....more detailed user-level explanation..." > "

" > "....now the more spec/edge case part..." > > > computeIfPresent() > "If the value for the specified key is present and non-null," > should be > "Updates the value for an existing key." > "

" > "....more detailed user-level explanation..." > "

" > "....now the more spec/edge case part..." > > > compute() > "Attempts to compute a mapping for the specified key..." > should be > "Updates the value for a key, adding a new mapping if necessary." > "

" > "....more detailed user-level explanation..." > "

" > "....now the more spec/edge case part..." > (attempts is negative, not positive) > > Similar problems seem to exist for "putIfAbsent". > > also... > > I have to say that I don't overly like the method name. > "map.merge(...)" sounds like a bulk operation affecting the whole map > (ie. like putAll). Assuming that the method cannot be renamed, it > could be improved just by changing the method parameter names.: > > default V merge(K key, V valueToMerge, > BiFunction mergeFunction) { > > "valueToMerge" implies that action will occur to the parameter. > "mergeFunction" is much more meaningful that "remapping Function". > > Similar parameter name change, "mappingFunction" -> "valueCreationFunction" > default V computeIfAbsent( > K key, > Function valueCreationFunction) { > > Similar parameter name change, "remappingFunction" -> "valueUpdateFunction" > default V computeIfPresent( > K key, > BiFunction valueUpdateFunction) { > > Similar parameter name change, "remappingFunction" -> "valueUpdateFunction" > default V compute( > K key, > BiFunction valueUpdateFunction) { > > > also... > Can you use HashSet::new in the example code? > > > In general, all these new methods are written in a spec style, rather > than a user friendly style, and I'm afraid I don't think thats > sufficient. > Stephen > > > > On 26 November 2013 04:32, Mike Duigou wrote: > > > > On Nov 24 2013, at 16:31 , David Holmes wrote: > > > >> Hi Mike, > >> > >> There is still no clear spec for what should happen if the param value > is null. > > > > I feel very uncomfortable the status quo of with null being ignored, > used for a sentinel and also as value. The relations between null and > values in this method are just too complicated. > > > > Currently: > > > > - The provided value may be either null or non-null. Is null a legal > value? It depends upon: > > - Is there an existing value? > > - Does the Map allow null values? > > - Does the function allow null values? > > - Existing null values are treated as absent. > > - If a null value is passed should we remove this mapping or add > it to the map? > > - null might not be accepted by the map > > - The associated value would still be regarded as absent > for future operations. > > - The function may return null to signal "remove". > > > > In particular I dislike adding a null entry to the map if there is no > current mapping (or mapped to null). It seems like it should be invariant > whether we end up with an associated value. If null is used to signify > "remove" then map.contains(key) will return variable results depending upon > the initial state. Having the behaviour vary based upon whether the map > allows null values would be even worse. > > > > So I would like to suggest that we require value to be non-null. I have > provisionally updated the spec and impls accordingly. > > > >> The parenthesized part is wrong. > > > > I think that's overzealous copying from compute(). I have removed it. > > > >> > >> Also you have changed the method implementation not just the implDoc so > the bug synopsis is somewhat misleading. > > > > I will correct this. More changes were made than I originally expected. > New synopsis will be "Map.merge implementations should refuse null value > param" > > > > I have updated the webrev. > > > > http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/ > > > > Thanks, > > > > Mike > > > >> > >> Thanks, > >> David > >> > >> On 23/11/2013 10:25 AM, Mike Duigou wrote: > >>> We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for > this issue. > >>> > >>> I've posted a webrev here: > >>> > >>> http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/ > >>> > >>> There is an identical change in ConcurrentMap's merge(). > >>> > >>> Mike > >>> > >>> On Nov 22 2013, at 16:01 , Henry Jen wrote: > >>> > >>>> > >>>> On 11/21/2013 06:33 PM, David Holmes wrote: > >>>>> On 22/11/2013 5:02 AM, Louis Wasserman wrote: > >>>>>> While I agree that case should be specified, I'm not certain I > follow why > >>>>>> that's what's going on here. > >>>>>> > >>>>>> The weird condition is that if oldValue is null, not value; oldValue > >>>>>> is the > >>>>>> old result of map.get(key). The Javadoc seems not just > unspecified, but > >>>>>> actively wrong. Here's a worked example: > >>>>>> > >>>>>> Map map = new HashMap<>(); > >>>>>> map.merge("foo", 3, Integer::plus); > >>>>>> Integer fooValue = map.get("foo"); > >>>>>> > >>>>>> Going through the Javadoc-specified default implementation: > >>>>>> > >>>>>> V oldValue = map.get(key); // oldValue is null > >>>>>> V newValue = (oldValue == null) ? value : > >>>>>> remappingFunction.apply(oldValue, value); > >>>>>> // newValue is set to value, which is 3 > >>>>>> if (newValue == null) // newValue is nonnull, branch not taken > >>>>>> map.remove(key); > >>>>>> else if (oldValue == null) // oldValue is null, branch taken > >>>>>> map.remove(key); // removes the entry from the map > >>>>>> else // else if was already triggered, branch not taken > >>>>>> map.put(key, newValue); > >>>>>> > >>>> > >>>> Seems like a document bug to me, we should fix this @implSpec. > >>>> > >>>> Cheers, > >>>> Henry > >>>> > >>> > > > From sebastian.sickelmann at gmx.de Tue Nov 26 17:44:16 2013 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 26 Nov 2013 18:44:16 +0100 Subject: Access Checking for MethodHandles.Lookup broken? In-Reply-To: <95B973DF-86E5-4C68-85C6-1CAA64B0E184@oracle.com> References: <528F08BF.2030100@gmx.de> <5291D033.7070106@gmx.de> <95B973DF-86E5-4C68-85C6-1CAA64B0E184@oracle.com> Message-ID: <5294DDF0.4030808@gmx.de> Hi, A few days ago I thought I had found a bug in MethodHandles.Lookup.findGetter/findSetter[0] , but i was wrong it seemed to be fixed in the latest JDK7 and JDK8 versions. I search the Bugdatabase for a ticket relating my issue and didn't found one. So i looked at the regressiontests for java/lang/invoke in the jdk repository. I found some test but it doesn't seem to produce the error i had expected on my old jdk7-version. So i decided to add some additional regressiontests. See patch[1] for more information of it. Everything is fine. It chrashes multiple times with my old jdk7 and it runs almost with 1.7.0_45 and 1.8.0-ea-b109. But unfortunatly it runs only almost. The last testcase in testFindPrivate() chrashes on jdk7 and jdk8. checkIllegalAccessException(new CTROE(){ public void run() throws ReflectiveOperationException{ PRIV_SUBCLASS.findVirtual(SubExample.class, "pri_v0",MethodType.methodType(void.class)); }}); The code tries to access the private method Example.pri_v0 from an lookup instance of a subclass of Example. I expect that there should be an IllegalAccessException, but unfortunatly it works. Sorry for cross-posting. But i think it is more related to core-libs-dev. I would love to work on a fix of this. But it will take some days for me to take a closer look to the implementation. -- Sebastian [0] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010148.html [1] https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/hgexport_0.txt Am 26.11.2013 03:03, schrieb John Rose: > On Nov 24, 2013, at 2:08 AM, Sebastian Sickelmann > > wrote: > >> I am sorry. Due to a configuration failure in my IDE had run with >> 1.7.0_16 >> >> Checked this again with 1.7.0_45 and 1.8.0-ea-b109 and everything is >> fine. >> >> Sorry for the mailing-list noise. > > If a MethodHandles.Lookup call allows more access to a method than its > corresponding bytecode behavior, that is definitely a bug. > > Recent updates to the javadoc for Lookup (in JDK 8) emphasize this > correspondence principle strongly. If it breaks, we want to know > about it. > > Thanks for the report and the double-check. > > ? John From john.r.rose at oracle.com Tue Nov 26 18:04:37 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Nov 2013 10:04:37 -0800 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: On Nov 22, 2013, at 11:07 AM, David Chase wrote: > Webrev(s): > http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ > http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ Excellent work. Count me as reviewer, please. ? John From iris.clark at oracle.com Tue Nov 26 18:08:51 2013 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 26 Nov 2013 10:08:51 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <5294D453.5050402@oracle.com> References: <5294D453.5050402@oracle.com> Message-ID: > So overall it looks good to me and should be pushed to the staging > forest once you hear from others that commented previously. I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov. Alan, please correct me if I'm wrong. Thanks, iris -----Original Message----- From: Alan Bateman Sent: Tuesday, November 26, 2013 9:03 AM To: Volker Simonis Cc: Vladimir Kozlov; 2d-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; security-dev; ppc-aix-port-dev at openjdk.java.net; awt-dev at openjdk.java.net; Java Core Libs; net-dev Subject: Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX On 26/11/2013 16:23, Volker Simonis wrote: > Hi, > > thanks to everybody for the prompt and helpful reviews. Here comes the > final webrev which incorporates all the corrections and suggestions > from the second review round: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ > > I've successfully build (and run some smoke tests) with these changes > on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, > MacOSX and AIX (5.3, 7.1). > I've skimmed over the last webrev with focus on: NetworkingLibraries.gmk where I see this is now fixed for all platforms. net_util.* and the platform specific net_util_md.* where I see you've added platformInit so it's much cleaner. UnixNativeDispatcher.c where the error translation is now removed (and looks fine). So overall it looks good to me and should be pushed to the staging forest once you hear from others that commented previously. -Alan From martinrb at google.com Tue Nov 26 18:15:19 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Nov 2013 10:15:19 -0800 Subject: Request to review JDK-8028094 In-Reply-To: <528DFBE9.60003@oracle.com> References: <528B57BA.3060102@oracle.com> <528CD120.3050101@oracle.com> <528DFBE9.60003@oracle.com> Message-ID: I dredged up some more memories about this part of ProcessBuilder and this part of Basic.java. As the comment indicates, there are remaining issues (might even call it a "bug") where the grandchild can keep a file descriptor open and thus cause a hang in the java process. Which is very hard to fix; I advise you not to try, unless perhaps your name is Alan Bateman. But here's an improvement to Basic.java which should kill off the sleep if pkill is available, not fail if pkill is not available, and keep the wakeupJeff-protected code working as intended until some brave soul tries to tackle the lingering bug in ProcessBuilder. https://www.youtube.com/watch?v=XP7q2o1Z0w8 --- a/test/java/lang/ProcessBuilder/Basic.java +++ b/test/java/lang/ProcessBuilder/Basic.java @@ -2017,7 +2017,6 @@ && new File("/bin/bash").exists() && new File("/bin/sleep").exists()) { final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep 6666)" }; - final String[] cmdkill = { "/bin/bash", "-c", "(/usr/bin/pkill -f \"sleep 6666\")" }; final ProcessBuilder pb = new ProcessBuilder(cmd); final Process p = pb.start(); final InputStream stdout = p.getInputStream(); @@ -2045,13 +2044,13 @@ stdout.close(); stderr.close(); stdin.close(); - new ProcessBuilder(cmdkill).start(); //---------------------------------------------------------- // There remain unsolved issues with asynchronous close. // Here's a highly non-portable experiment to demonstrate: //---------------------------------------------------------- if (Boolean.getBoolean("wakeupJeff!")) { System.out.println("wakeupJeff!"); + long startTime = System.nanoTime(); // Initialize signal handler for INTERRUPT_SIGNAL. new FileInputStream("/bin/sleep").getChannel().close(); // Send INTERRUPT_SIGNAL to every thread in this java. @@ -2064,8 +2063,18 @@ }; new ProcessBuilder(wakeupJeff).start().waitFor(); // If wakeupJeff worked, reader probably got EBADF. - reader.join(); + long timeout = 60L * 1000L; + reader.join(timeout); + long elapsedTimeMillis = + (System.nanoTime() - startTime) / (1024L * 1024L); + check(elapsedTimeMillis < timeout); + check(!reader.isAlive()); } + // Try to clean up the sleep process, but don't fret about it. + try { + new ProcessBuilder("/usr/bin/pkill", "-f", "sleep 6666") + .start(); + } catch (IOException noPkillCommandInstalled) { } } } catch (Throwable t) { unexpected(t); } On Thu, Nov 21, 2013 at 4:26 AM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > Hi Martin, > > > > > + check(elapsedTimeMillis < timeout); > > + *check(!reader.isAlive());* > > > The line check(!reader.isAlive()) is causing the test failure > when the pkill command is not available. Any idea ? The > test is passing with check(reader.isAlive()). > > > The modified test is passing when the pkill command is > available. > > > When the pkill command is not available, the test is/was > failing without try block around > new ProcessBuilder(cmdkill).start(). > > So, without placing the above line under try block was a > mistake. I will make the correction. > > > Thanks > Balchandra > > > > On 11/20/13 03:11 PM, Balchandra Vaidya wrote: > > > Thanks Martin. I will incorporate your suggested improvements, and > will send out another webrev. > > Regards > Balchandra > > On 19/11/2013 22:53, Martin Buchholz wrote: > > I see this is already submitted. > > I thought I could do better than using pkill, but no - there is no > convenient communication from the java process to the grandchild. This is > a hairy test! > > Nevertheless, I would like you to incorporate the following improvements: > - invoke pkill directly > - do some extra checking > - join with reader thread > - don't fail if pkill is not available > > --- a/test/java/lang/ProcessBuilder/Basic.java > +++ b/test/java/lang/ProcessBuilder/Basic.java > @@ -2016,7 +2016,7 @@ > && new File("/bin/bash").exists() > && new File("/bin/sleep").exists()) { > final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep > 6666)" }; > - final String[] cmdkill = { "/bin/bash", "-c", > "(/usr/bin/pkill -f \"sleep 6666\")" }; > + final String[] cmdkill = { "/usr/bin/pkill", "-f", "sleep > 6666" }; > final ProcessBuilder pb = new ProcessBuilder(cmd); > final Process p = pb.start(); > final InputStream stdout = p.getInputStream(); > @@ -2044,7 +2044,9 @@ > stdout.close(); > stderr.close(); > stdin.close(); > - new ProcessBuilder(cmdkill).start(); > + // Try to clean up the sleep process, but don't fret > about it. > + try { new ProcessBuilder(cmdkill).start(); } > + catch (IOException noPkillCommandInstalled) { } > > //---------------------------------------------------------- > // There remain unsolved issues with asynchronous close. > // Here's a highly non-portable experiment to demonstrate: > @@ -2063,8 +2065,14 @@ > }; > new ProcessBuilder(wakeupJeff).start().waitFor(); > // If wakeupJeff worked, reader probably got EBADF. > - reader.join(); > } > + long startTime = System.nanoTime(); > + long timeout = 60L * 1000L; > + reader.join(timeout); > + long elapsedTimeMillis = > + (System.nanoTime() - startTime) / (1024L * 1024L); > + check(elapsedTimeMillis < timeout); > + check(!reader.isAlive()); > } > } catch (Throwable t) { unexpected(t); } > > > > > On Tue, Nov 19, 2013 at 4:21 AM, Balchandra Vaidya < > balchandra.vaidya at oracle.com> wrote: > >> >> Hi, >> >> Here is one possible solution for the issue JDK-8028094. >> http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ >> >> I am not sure pkill is available in all Unix flavor at /usr/bin directory, >> but it is present in Solaris and OEL 6. I have tested on Solaris >> and OEL and "sleep 6666" is no longer left over. >> >> >> Thanks >> Balchandra >> >> >> > > > From huizhe.wang at oracle.com Tue Nov 26 18:38:15 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 26 Nov 2013 10:38:15 -0800 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5294C79F.1080907@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> Message-ID: <5294EA97.4060804@oracle.com> Hi all, Here's revised webrev, as Alan suggested, including the implementation. http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ Thanks, Joe On 11/26/2013 8:09 AM, Alan Bateman wrote: > On 25/11/2013 21:51, huizhe wang wrote: >> Hi, >> >> This is a patch to fix an error in StAX factories' newFactory(String >> factoryId, ClassLoader classLoader). In the 3 step of the >> documentation, it should have stated that the specified ClassLoader >> is used. >> >> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/webrev/ > The change looks good to me in that it makes these strange factory > methods somewhat usable. > > -Alan From martinrb at google.com Tue Nov 26 18:39:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Nov 2013 10:39:58 -0800 Subject: RFR: 8029055: Map.merge must refuse null values In-Reply-To: References: <528E568D.8020909@oracle.com> <528EC28B.6040002@oracle.com> <528FF062.9030800@oracle.com> <52929A59.20204@oracle.com> <63CE95FF-EBA9-4003-AFC2-4F8EBED9B807@oracle.com> Message-ID: On Tue, Nov 26, 2013 at 5:35 AM, Stephen Colebourne wrote: > See the new thread for the general Javadoc issues. I'll focus on null here. > > Given a map {"Key" -> null} I find the notion that putIfAbsent() or > computeIfAbsent() ignore the existing mapping just plain wrong. While > I can rationalise it (just) it is a horrible reworking of the meaning > of "absent". > > Similarly, for "computeIfPresent()", my expectation is that the > mapping is present, and that the null should be an input to the > function. > This is also very much my expectation for computeIfPresent. I can see why the current semantics may have been chosen, because the obvious implementation choice needs just one call to map.get without a call to map.containsKey. But it seems OK to disambiguate using containsKey when get returns null. Concurrent maps don't have problems implementing this either way because they don't allow nulls. From kustos at gmx.net Tue Nov 26 18:45:11 2013 From: kustos at gmx.net (Philippe Marschall) Date: Tue, 26 Nov 2013 19:45:11 +0100 Subject: ArrayStoreException in Class#getAnnotations In-Reply-To: <5293C8C9.80006@oracle.com> References: <5292324D.5080805@gmx.net> <5293C8C9.80006@oracle.com> Message-ID: <5294EC37.3020002@gmx.net> On 25.11.2013 23:01, Alan Bateman wrote: > On 24/11/2013 17:07, Philippe Marschall wrote: >> Hi >> >> The following issue was been bothering me for a while: >> When you have an annotation with a value that is an array of classes >> [1] and one of those classes can't be loaded with the class loader of >> defining class of the element the annotation is defined on you get a >> ArrayStoreException (stack trace below). > See JDK-7183985 [1]. I see, JDK 9 if we're lucky. >> : >> >> I would like to take a moment to lament the fact that you no longer >> offer fastdebug builds and no longer include sources for non-API >> classes. Things like this were much easier to debug in the good old >> JDK 6 days. This is double annoying when your marketing honchos are >> always touting increased developer productivity. > I'm curious what you mean by "no longer include source for non-API > classes". If you mean src.zip then I thought it only ever contained the > classes for the API classes. At least the initial JDK 6 releases included sources for com.sun and sunw. Ok, wouldn't have helped in this case. Cheers Philippe From iris.clark at oracle.com Tue Nov 26 19:18:19 2013 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 26 Nov 2013 11:18:19 -0800 (PST) Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <5294EDB7.8020408@oracle.com> References: <5294D453.5050402@oracle.com> <5294EDB7.8020408@oracle.com> Message-ID: <20bfb263-7e01-484f-b7b2-94d6516141bd@default> Hi. >> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ > + src/solaris/classes/java/lang/UNIXProcess.java.aix > 2 * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. > 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Oracle copyright in acceptable location and uses correct format. > + src/aix/porting/porting_aix.h > 2 * Copyright 2012, 2013 SAP AG. All rights reserved. > 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. SAP copyright in acceptable location. > + src/aix/native/sun/tools/attach/AixVirtualMachine.c > 2 * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved. > 3 * Copyright 2013 SAP AG. All rights reserved. > 4 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER Oracle and SAP copyrights in acceptable locations. Oracle format is correct. The licenses (GPL+CP) look fine to me. Thanks, iris -----Original Message----- From: Sergey Bylokhov Sent: Tuesday, November 26, 2013 10:52 AM To: Alan Bateman; Volker Simonis Cc: 2d-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; security-dev; ppc-aix-port-dev at openjdk.java.net; awt-dev at openjdk.java.net; Java Core Libs; net-dev Subject: Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX On 26.11.2013 21:03, Alan Bateman wrote: > On 26/11/2013 16:23, Volker Simonis wrote: >> Hi, >> >> thanks to everybody for the prompt and helpful reviews. Here comes >> the final webrev which incorporates all the corrections and >> suggestions from the second review round: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ >> >> I've successfully build (and run some smoke tests) with these changes >> on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, >> MacOSX and AIX (5.3, 7.1). >> > I've skimmed over the last webrev with focus on: > > NetworkingLibraries.gmk where I see this is now fixed for all platforms. > > net_util.* and the platform specific net_util_md.* where I see you've > added platformInit so it's much cleaner. I have a question about boolean_t in the [1]. Is it correct to skip it in the new block? http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/src/share/native/sun/security/ec/impl/ecc_impl.h.frames.html Also I have a question about headers in the added files. Looks like different templates are used: + src/solaris/classes/java/lang/UNIXProcess.java.aix 2 * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + src/aix/porting/porting_aix.h 2 * Copyright 2012, 2013 SAP AG. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + src/aix/native/sun/tools/attach/AixVirtualMachine.c 2 * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved. 3 * Copyright 2013 SAP AG. All rights reserved. 4 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. etc.. Do we have some rules about that? > > UnixNativeDispatcher.c where the error translation is now removed (and > looks fine). > > So overall it looks good to me and should be pushed to the staging > forest once you hear from others that commented previously. > > -Alan -- Best regards, Sergey. From philip.race at oracle.com Tue Nov 26 20:01:11 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 Nov 2013 12:01:11 -0800 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: Message-ID: <5294FE07.3060309@oracle.com> Looking only at what you needed to change this time round, all seems fine now. -phil. On 11/26/13 8:23 AM, Volker Simonis wrote: > Hi, > > thanks to everybody for the prompt and helpful reviews. Here comes the > final webrev which incorporates all the corrections and suggestions > from the second review round: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ > > > I've successfully build (and run some smoke tests) with these changes > on Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, Windows/x86_64, > MacOSX and AIX (5.3, 7.1). > > So if nobody vetoes these changes are ready for push into our staging > repository. > > @Vladimir: can I push them or do you want to run them trough JPRT? > > Thank you and best regards, > Volker > > PS: compared to the last webrev > (http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > ), I've > slightly changed the following files: > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/NetworkingLibraries.gmk > makefiles/Setup.gmk > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/native/java/net/aix_close.c > src/aix/porting/porting_aix.c > src/share/native/java/net/net_util.c > src/share/native/java/net/net_util.h > src/share/native/sun/awt/medialib/mlib_sys.c > src/solaris/bin/java_md_solinux.c > src/solaris/classes/sun/nio/ch/Port.java > src/solaris/native/java/net/net_util_md.c > src/solaris/native/sun/java2d/x11/XRBackendNative.c > src/solaris/native/sun/management/OperatingSystemImpl.c > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > src/windows/native/java/net/net_util_md.c > > Most of the changes are cosmetic, except the ones in: > > src/share/native/java/net/net_util.c > src/share/native/java/net/net_util.h > src/solaris/native/java/net/net_util_md.c > src/windows/native/java/net/net_util_md.c > > where I renamed 'initLocalAddrTable()' to 'platformInit()'. For AIX, > this method will now call 'aix_close_init()' as suggested by Alan. > > The changes to src/solaris/native/com/sun/ > management/UnixOperatingSystem_md.c are now in > src/solaris/native/sun/management/OperatingSystemImpl.c because that > file was moved by an upstream change. > > > > On Wed, Nov 20, 2013 at 7:26 PM, Volker Simonis > > wrote: > > Hi, > > this is the second review round for "8024854: Basic changes and > files to build the class library on AIX > ". The previous > reviews can be found at the end of this mail in the references > section. > > I've tried to address all the comments and suggestions from the > first round and to further streamline the patch (it perfectly > builds on Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and > Windows/x86_64). The biggest change compared to the first review > round is the new "aix/" subdirectory which I've now created under > "jdk/src" and which contains AIX-only code. > > The webrev is against our > http://hg.openjdk.java.net/ppc-aix-port/stage repository which has > been recently synchronised with the jdk8 master: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v2/ > > > Below (and in the webrev) you can find some comments which explain > the changes to each file. In order to be able to push this big > change, I need the approval of reviewers from the lib, net, svc, > 2d, awt and sec groups. So please don't hesitate to jump at it - > there are enough changes for everybody:) > > Thank you and best regards, > Volker > > *References:* > > The following reviews have been posted so far (thanks Iris for > collecting them :) > > - Alan Bateman (lib): Initial comments (16 Sep [2]) > - Chris Hegarty (lib/net): Initial comments (20 Sep [3]) > - Michael McMahon (net): Initial comments (20 Sept [4]) > - Steffan Larsen (svc): APPROVED (20 Sept [5]) > - Phil Race (2d): Initial comments (18 Sept [6]); Additional > comments (15 Oct [7]) > - Sean Mullan (sec): Initial comments (26 Sept [8]) > > [2]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001045.html > [3]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001078.html > [4]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001079.html > [5]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001077.html > [6]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001069.html > [7]: > http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003826.html > [8]: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-September/001081.html > > > *Detailed change description:* > > The new "jdk/src/aix" subdirectory contains the following new and > AIX-specific files for now: > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > src/aix/classes/sun/nio/ch/AixAsynchronousChannelProvider.java > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/classes/sun/nio/fs/AixFileStore.java > src/aix/classes/sun/nio/fs/AixFileSystem.java > src/aix/classes/sun/nio/fs/AixFileSystemProvider.java > src/aix/classes/sun/nio/fs/AixNativeDispatcher.java > src/aix/classes/sun/tools/attach/AixAttachProvider.java > src/aix/classes/sun/tools/attach/AixVirtualMachine.java > src/aix/native/java/net/aix_close.c > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/sun/nio/fs/AixNativeDispatcher.c > src/aix/native/sun/tools/attach/AixVirtualMachine.c > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > > src/aix/porting/porting_aix.c > src/aix/porting/porting_aix.h > > * Added these two files for AIX relevant utility code. > * Currently these files only contain an implementation of > |dladdr| which is not available on AIX. > * In the first review round the existing |dladdr| users in the > code either called the version from the HotSpot on AIX > (|src/solaris/native/sun/awt/awt_LoadLibrary.c|) or had a > private copy of the whole implementation > (|src/solaris/demo/jvmti/hprof/hprof_md.c|). This is now not > necessary any more. > > The new file layout required some small changes to the makefiles > to make them aware of the new directory locations: > > > makefiles/CompileDemos.gmk > > * Add an extra argument to |SetupJVMTIDemo| which can be used to > pass additional source locations. > * Currently this is only used on AIX for the AIX porting > utilities which are required by hprof. > > > makefiles/lib/Awt2dLibraries.gmk > makefiles/lib/ServiceabilityLibraries.gmk > > * On AIX add the sources of the AIX porting utilities to the > build. They are required by > |src/solaris/native/sun/awt/awt_LoadLibrary.c| and > |src/solaris/demo/jvmti/hprof/hprof_md.c| because |dladdr| is > not available on AIX. > > > makefiles/lib/NioLibraries.gmk > > * Make the AIX-build aware of the new NIO source locations under > |src/aix/native/sun/nio/|. > > > makefiles/lib/NetworkingLibraries.gmk > > * Make the AIX-build aware of the new |aix_close.c| source > location under |src/aix/native/java/net/|. > > > src/share/bin/jli_util.h > > * Define |JLI_Lseek| on AIX. > > > src/share/lib/security/java.security-aix > > * Provide default |java.security-aix| for AIX based on the > latest Linux version as suggested by Sean Mullan. > > > src/share/native/common/check_code.c > > * On AIX malloc(0) and calloc(0, ...) return a NULL pointer, > which is legal, but the code in |check_code.c| does not > handles this properly. So we wrap the two methods on AIX and > return a non-NULL pointer even if we allocate 0 bytes. > > > src/share/native/sun/awt/medialib/mlib_sys.c > > * |malloc| always returns 8-byte aligned pointers on AIX as well. > > > src/share/native/sun/awt/medialib/mlib_types.h > > * Add AIX to the list of known platforms. > > > src/share/native/sun/font/layout/KernTable.cpp > > * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| > is too common and may be defined in other headers as well as > on the command line and |xlc| bails out on macro redefinitions > with a different value. > > > src/share/native/sun/security/ec/impl/ecc_impl.h > > * Define required types and macros on AIX. > > > src/solaris/back/exec_md.c > > * AIX behaves like Linux in this case so check for it in the > Linux branch. > > > src/solaris/bin/java_md_solinux.c, > src/solaris/bin/java_md_solinux.h > > * On AIX |LD_LIBRARY_PATH| is called |LIBPATH| > * Always use |LD_LIBRARY_PATH| macro instead of using the string > "|LD_LIBRARY_PATH|" directly to cope with different library > path names. > * Add |jre/lib//jli| to the standard library search path > on AIX because the AIX linker doesn't support the |-rpath| option. > * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in > this case, AIX behaves like Linux. > * Removed the definition of |JVM_DLL|, |JAVA_DLL| and > |LD_LIBRARY_PATH| from |java_md_solinux.h| because the macros > are redefined in the corresponding |.c| files anyway. > > > src/aix/classes/sun/awt/fontconfigs/aix.fontconfig.properties > > * Provide basic |fontconfig.properties|for AIX. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix, > src/aix/classes/sun/tools/attach/AixAttachProvider.java, > src/aix/classes/sun/tools/attach/AixVirtualMachine.java, > src/aix/native/sun/tools/attach/AixVirtualMachine.c > > * Provide AIX specific Java versions, mostly based on the > corresponding Linux versions. > > > src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java > src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java > > * Detect AIX operating system and return the corresponding > channel and file system providers. > > > src/solaris/classes/sun/nio/ch/Port.java > > * Add a callback function |unregisterImpl(int fd)| for > implementations that need special handling when |fd| is > removed and call it from |unregister(int fd)|. By default the > implementation of |unregisterImpl(int fd)| is empty except for > the derived |AixPollPort| class on AIX. > > > src/solaris/demo/jvmti/hprof/hprof_md.c > > * Add AIX support. AIX mostly behaves like Linux, with the one > exception that it has no |dladdr| functionality. > * Use the |dladdr| implementation from |porting_aix.{c,h}| on AIX. > > > src/solaris/native/com/sun/management/UnixOperatingSystem_md.c > > * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory). > > > src/solaris/native/common/jdk_util_md.h > > * Add AIX definitions of the |ISNANF| and |ISNAND| macros. > > > src/solaris/native/java/io/io_util_md.c > > * AIX behaves like Linux in this case so check for it in the > Linux branch. > > > src/solaris/native/java/lang/UNIXProcess_md.c > > * AIX behaves mostly like Solraris in this case so adjust the > ifdefs accordingly. > > > src/solaris/native/java/lang/childproc.c > > * AIX does not understand '/proc/self' - it requires the real > process ID to query the proc file system for the current process. > > > src/solaris/native/java/net/NetworkInterface.c > > * Add AIX support into the Linux branch because AIX mostly > behaves like AIX for IPv4. > * AIX needs a special function to enumerate IPv6 interfaces and > to query the MAC address. > * Moved the declaration of |siocgifconfRequest| to the beginning > a the function (as recommend by Michael McMahon) to remain C89 > compatible. > > > src/solaris/native/java/net/PlainSocketImpl.c > > * On AIX (like on Solaris) |setsockopt| will set errno to > |EINVAL| if the socket is closed. The default error message is > then confusing. > > > src/aix/native/java/net/aix_close.c, > src/share/native/java/net/net_util.c > > * As recommended by Michael McMahon and Alan Bateman I've move > an adapted version of |linux_close.c| to > |src/aix/native/java/net/aix_close.c| because we also need the > file and socket wrappers on AIX. > * Compared to the Linux version, we've added the initialization > of some previously uninitialized data structures. > * Also, on AIX we don't have |__attribute((constructor))| so we > need to initialize manually (from |JNI_OnLoad()| in > |src/share/native/java/net/net_util.c|. > > > src/solaris/native/java/net/net_util_md.h > > * AIX needs the same workaround for I/O cancellation like Linux > and MacOSX. > > > src/solaris/native/java/net/net_util_md.c > > * |SO_REUSEADDR| is called |SO_REUSEPORT| on AIX. > * On AIX we have to ignore failures due to |ENOBUFS| when > setting the |SO_SNDBUF|/|SO_RCVBUF| socket options. > > > src/solaris/native/java/util/TimeZone_md.c > > * Currently on AIX the only way to get the platform time zone is > to read it from the |TZ| environment variable. > > > src/solaris/native/sun/awt/awt_LoadLibrary.c > > * Use the |dladdr| from |porting_aix.{c,h}| on AIX. > > > src/solaris/native/sun/awt/fontpath.c > > * Changed some macros from |if !defined(__linux__)| to |if > defined(__solaris__)| because that's their real meaning. > * Add AIX specific fontpath settings and library search paths > for |libfontconfig.so|. > > > src/solaris/native/sun/java2d/x11/X11SurfaceData.c > > * Rename the |MIN| and |MAX| macros to |XSD_MIN| and |XSD_MAX| > to avoid name clashes (|MIN| and |MAX| are much too common and > thexy are already defined in some AIX system headers). > > > src/solaris/native/sun/java2d/x11/XRBackendNative.c > > * Handle AIX like Solaris. > > > src/solaris/native/sun/nio/ch/Net.c > > * Add AIX-specific includes and constant definitions. > * On AIX "socket extensions for multicast source filters" > support depends on the OS version. Check for this and throw > appropriate exceptions if it is requested but not supported. > This is needed to pass > JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast > > > src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c > > * On AIX |strerror()| is not thread-safe so we have to use > |strerror_r()| instead. > * On AIX |readdir_r()| returns EBADF (i.e. '9') and sets > 'result' to NULL for the directory stream end. Otherwise, > 'errno' will contain the error code. > * Handle some AIX corner cases for the results of the > |statvfs64()| call. > * On AIX |getgrgid_r()| returns ESRCH if group does not exist. > > > src/solaris/native/sun/security/pkcs11/j2secmod_md.c > > * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX. > > > test/java/lang/ProcessBuilder/Basic.java > test/java/lang/ProcessBuilder/DestroyTest.java > > * Port this test to AIX and make it more robust (i.e. recognize > the "C" locale as |isEnglish()|, ignore VM-warnings in the > output, make sure the "grandchild" processes created by the > test don't run too long (60s vs. 6666s) because in the case of > test problems these processes will pollute the process space, > make sure the test fails with an error and doesn't hang > indefinitley in the case of a problem). > > *Q (Michael McMahon):* Seems to be two macros _AIX and AIX. Is > this intended? > > Well, |_AIX| is defined in some system headers while |AIX| is > defined by the build system. This is already used inconsistently > (i.e. |__linux__| vs. |LINUX|) and in general I try to be > consistent with the style of the file where I the changes are. > That said, I changes most of the occurences of |AIX| to |_AIX|. > > *Q (Alan Bateman):* There are a few changes for OS/400 in the > patch, are they supposed to be there? > > We currently don't support OS/400 (later renamed into i5/OS and > currently called IBM i) in our OpenJDK port but we do support it > in our internel, SAP JVM build. We stripped out all the extra > OS/400 functionality from the port but in some places where there > is common functionality needd by both, AIX and OS/400 the OS/400 > support may still be visible in the OpenJDK port. I don't think > this is a real problem and it helps us to keep our internel > sources in sync with the OpenJDK port. That said, I think I've > removed all the references to OS/400 now. > > > From Alan.Bateman at oracle.com Tue Nov 26 21:37:33 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Nov 2013 21:37:33 +0000 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5294EA97.4060804@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> Message-ID: <5295149D.6070206@oracle.com> On 26/11/2013 18:38, huizhe wang wrote: > Hi all, > > Here's revised webrev, as Alan suggested, including the implementation. > > http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ So is this handling the null case correctly? It is spec'ed to use the TCCL but it looks like it's going through to ServiceLoader.load where null means the system class loader. Maybe this needs to wait for tests as that it really the only way to check this. -Alan From roger.riggs at oracle.com Tue Nov 26 21:59:58 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 26 Nov 2013 16:59:58 -0500 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5295149D.6070206@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> Message-ID: <529519DE.6000700@oracle.com> Hi, I looked at that twice also. java.time had a similar situation. To get to the TCCL you need to call ServiceLoader.load(type). The FactoryFinder:348 findServiceProvider method should test if cl == null and call the original ServiceLoader function. Roger On 11/26/2013 4:37 PM, Alan Bateman wrote: > On 26/11/2013 18:38, huizhe wang wrote: >> Hi all, >> >> Here's revised webrev, as Alan suggested, including the implementation. >> >> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ > So is this handling the null case correctly? It is spec'ed to use the > TCCL but it looks like it's going through to ServiceLoader.load where > null means the system class loader. Maybe this needs to wait for tests > as that it really the only way to check this. > > -Alan From huizhe.wang at oracle.com Tue Nov 26 22:13:05 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 26 Nov 2013 14:13:05 -0800 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5295149D.6070206@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> Message-ID: <52951CF1.5060404@oracle.com> On 11/26/2013 1:37 PM, Alan Bateman wrote: > On 26/11/2013 18:38, huizhe wang wrote: >> Hi all, >> >> Here's revised webrev, as Alan suggested, including the implementation. >> >> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ > So is this handling the null case correctly? It is spec'ed to use the > TCCL but it looks like it's going through to ServiceLoader.load where > null means the system class loader. Maybe this needs to wait for tests > as that it really the only way to check this. Ah, I missed that. I took it for granted that since ServiceLoader.load(service) uses TCCL, load(service, null) would use TCCL. I've updated the webrev now: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ I've re-submitted a JPRT build, will send that to JCK. -Joe > > -Alan From daniel.fuchs at oracle.com Tue Nov 26 22:23:26 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Nov 2013 23:23:26 +0100 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <52951CF1.5060404@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> <52951CF1.5060404@oracle.com> Message-ID: <52951F5E.9090207@oracle.com> On 11/26/13 11:13 PM, huizhe wang wrote: > > On 11/26/2013 1:37 PM, Alan Bateman wrote: >> On 26/11/2013 18:38, huizhe wang wrote: >>> Hi all, >>> >>> Here's revised webrev, as Alan suggested, including the implementation. >>> >>> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ >> So is this handling the null case correctly? It is spec'ed to use the >> TCCL but it looks like it's going through to ServiceLoader.load where >> null means the system class loader. Maybe this needs to wait for tests >> as that it really the only way to check this. > > Ah, I missed that. I took it for granted that since > ServiceLoader.load(service) uses TCCL, load(service, null) would use > TCCL. I've updated the webrev now: > > http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ Hi Joe, This looks good. -- daniel > > I've re-submitted a JPRT build, will send that to JCK. > > -Joe > >> >> -Alan > From huizhe.wang at oracle.com Tue Nov 26 22:27:57 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 26 Nov 2013 14:27:57 -0800 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <529519DE.6000700@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> <529519DE.6000700@oracle.com> Message-ID: <5295206D.2030102@oracle.com> On 11/26/2013 1:59 PM, roger riggs wrote: > Hi, > > I looked at that twice also. java.time had a similar situation. > > To get to the TCCL you need to call ServiceLoader.load(type). > > The FactoryFinder:348 findServiceProvider method should test if cl == > null and call the original ServiceLoader function. Yes. I forgot that part. load(service, loader) treats null as the system class loader was one of the topics in the discussion of the spec. Joe > > Roger > > On 11/26/2013 4:37 PM, Alan Bateman wrote: >> On 26/11/2013 18:38, huizhe wang wrote: >>> Hi all, >>> >>> Here's revised webrev, as Alan suggested, including the implementation. >>> >>> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ >> So is this handling the null case correctly? It is spec'ed to use the >> TCCL but it looks like it's going through to ServiceLoader.load where >> null means the system class loader. Maybe this needs to wait for >> tests as that it really the only way to check this. >> >> -Alan > From Sergey.Bylokhov at oracle.com Tue Nov 26 22:32:08 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 Nov 2013 02:32:08 +0400 Subject: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: <5294D453.5050402@oracle.com> <5294EDB7.8020408@oracle.com> Message-ID: <52952168.1060704@oracle.com> HI, Volker. Thanks for clarification. The fix looks good. On 11/27/13 12:48 AM, Volker Simonis wrote: > Hi Sergey, > > on AIX, there's already a typedef for "boolean_t" in sys/types.h > that's why we have to omit it from ecc_impl.h to avoid compile errors. > > The question regarding the copyright headers has been already answered > by Iris (thanks Iris). > > Thank you and best regards, > Volker > > On Tuesday, November 26, 2013, Sergey Bylokhov wrote: > > On 26.11.2013 21:03, Alan Bateman wrote: > > On 26/11/2013 16:23, Volker Simonis wrote: > > Hi, > > thanks to everybody for the prompt and helpful reviews. > Here comes the > final webrev which incorporates all the corrections and > suggestions from > the second review round: > > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ > > > I've successfully build (and run some smoke tests) with > these changes on > Linux (x86_32, x86_64, ppc64), Solaris/sparcv9, > Windows/x86_64, MacOSX and > AIX (5.3, 7.1). > > I've skimmed over the last webrev with focus on: > > NetworkingLibraries.gmk where I see this is now fixed for all > platforms. > > net_util.* and the platform specific net_util_md.* where I see > you've added platformInit so it's much cleaner. > > I have a question about boolean_t in the [1]. Is it correct to > skip it in the new block? > http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/src/share/native/sun/security/ec/impl/ecc_impl.h.frames.html > > > Also I have a question about headers in the added files. Looks > like different templates are used: > > + src/solaris/classes/java/lang/UNIXProcess.java.aix > 2 * Copyright (c) 1995, 2013, Oracle and/or its affiliates. > All rights reserved. > 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + src/aix/porting/porting_aix.h > 2 * Copyright 2012, 2013 SAP AG. All rights reserved. > 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + src/aix/native/sun/tools/attach/AixVirtualMachine.c > 2 * Copyright (c) 2008, 2013, Oracle and/or its affiliates. > All rights reserved. > 3 * Copyright 2013 SAP AG. All rights reserved. > 4 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > etc.. > > Do we have some rules about that? > > > UnixNativeDispatcher.c where the error translation is now > removed (and looks fine). > > So overall it looks good to me and should be pushed to the > staging forest once you hear from others that commented > previously. > > -Alan > > > > -- > Best regards, Sergey. > -- Best regards, Sergey. From Lance.Andersen at oracle.com Tue Nov 26 22:37:11 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 26 Nov 2013 17:37:11 -0500 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5295206D.2030102@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> <529519DE.6000700@oracle.com> <5295206D.2030102@oracle.com> Message-ID: looks OK Joe On Nov 26, 2013, at 5:27 PM, huizhe wang wrote: > > On 11/26/2013 1:59 PM, roger riggs wrote: >> Hi, >> >> I looked at that twice also. java.time had a similar situation. >> >> To get to the TCCL you need to call ServiceLoader.load(type). >> >> The FactoryFinder:348 findServiceProvider method should test if cl == null and call the original ServiceLoader function. > > Yes. I forgot that part. load(service, loader) treats null as the system class loader was one of the topics in the discussion of the spec. > > Joe > >> >> Roger >> >> On 11/26/2013 4:37 PM, Alan Bateman wrote: >>> On 26/11/2013 18:38, huizhe wang wrote: >>>> Hi all, >>>> >>>> Here's revised webrev, as Alan suggested, including the implementation. >>>> >>>> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ >>> So is this handling the null case correctly? It is spec'ed to use the TCCL but it looks like it's going through to ServiceLoader.load where null means the system class loader. Maybe this needs to wait for tests as that it really the only way to check this. >>> >>> -Alan >> > -------------- next part -------------- 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.kozlov at oracle.com Tue Nov 26 23:13:38 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 26 Nov 2013 23:13:38 +0000 Subject: hg: jdk8/tl/jdk: 8016839: JSR292: AME instead of IAE when calling a method Message-ID: <20131126231350.CD08F6288D@hg.openjdk.java.net> Changeset: e822676cd3cd Author: jrose Date: 2013-11-26 17:16 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e822676cd3cd 8016839: JSR292: AME instead of IAE when calling a method Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null. Reviewed-by: acorn, jrose, coleenp Contributed-by: david.r.chase at oracle.com ! src/share/classes/sun/misc/Unsafe.java From mandy.chung at oracle.com Tue Nov 26 23:59:03 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 Nov 2013 15:59:03 -0800 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs Message-ID: <529535C7.8090403@oracle.com> This is a simple patch that adds a new jdeps -jdkinternals option to make it easier for developers to find dependencies on the JDK internal APIs: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ Mandy From lana.steuck at oracle.com Wed Nov 27 00:12:00 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Nov 2013 00:12:00 +0000 Subject: hg: jdk8/tl/hotspot: 15 new changesets Message-ID: <20131127001231.9F49462895@hg.openjdk.java.net> Changeset: 854a42db7069 Author: amurillo Date: 2013-11-15 07:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/854a42db7069 8028444: new hotspot build - hs25-b60 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 570aaefce624 Author: morris Date: 2013-11-18 12:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/570aaefce624 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Summary: Change _abstract_method_handler to return AbstractMethodError i2c, c2i and c2iv entries. Reviewed-by: kvn, vlivanov ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 938e1e64e28f Author: anoll Date: 2013-11-14 19:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/938e1e64e28f 8028306: nsk stress tests, CodeCache fills, then safepoint asserts Summary: Move handle_full_code_cache() out of block that forbids safepoints Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: fca8f4799229 Author: roland Date: 2013-11-20 12:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fca8f4799229 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop Summary: rbp not restored when stack overflow is thrown from deopt/uncommon trap blobs Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + test/compiler/uncommontrap/TestStackBangRbp.java Changeset: cdf20166ec45 Author: minqi Date: 2013-11-13 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cdf20166ec45 8025632: Remove all references to MagicLambdaImpl from Hotspot Summary: MagicLambdaImpl was removed from jdk side, this should be done in vm side too Reviewed-by: coleenp, hseigel, rdurbin ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 3edddbff4865 Author: minqi Date: 2013-11-13 16:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3edddbff4865 Merge Changeset: b03f33670080 Author: sla Date: 2013-11-14 19:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b03f33670080 6606002: jinfo doesn't detect dynamic vm flags changing Reviewed-by: coleenp, jbachorik, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java Changeset: 5280822ddfcd Author: sla Date: 2013-11-14 20:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5280822ddfcd 6626412: jstack using SA prints some info messages into err stream Reviewed-by: coleenp, farvidsson, jbachorik, dsamersoff, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java Changeset: 438fe38c63c8 Author: mgronlun Date: 2013-11-15 21:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/438fe38c63c8 Merge ! src/share/vm/runtime/globals.hpp Changeset: d61a1a166f44 Author: coleenp Date: 2013-11-15 17:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d61a1a166f44 8028347: Rewriter::scan_method asserts with array oob in RT_Baseline Summary: Fix reversing rewriting for invokespecial Reviewed-by: jrose, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp Changeset: 0b9ea9a72436 Author: sla Date: 2013-11-18 10:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b9ea9a72436 8027630: SIGSEGV in const char*Klass::external_name() Reviewed-by: coleenp, sspitsyn, mgronlun ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 396564992823 Author: sgabdura Date: 2013-11-18 08:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/396564992823 8028341: PSR:FUNC: SCOPE PARAMETER MISSING FROM THE -XX:+PRINTFLAGSFINAL Reviewed-by: dcubed, sla ! src/share/vm/runtime/globals.cpp Changeset: aa933e6b061d Author: mgronlun Date: 2013-11-22 20:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa933e6b061d Merge Changeset: abad3b2d905d Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abad3b2d905d Merge Changeset: c9f439732b18 Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9f439732b18 Added tag hs25-b60 for changeset abad3b2d905d ! .hgtags From lance.andersen at oracle.com Wed Nov 27 00:15:21 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 26 Nov 2013 19:15:21 -0500 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <529535C7.8090403@oracle.com> References: <529535C7.8090403@oracle.com> Message-ID: +1 Mandy 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 Sent from my iPad On Nov 26, 2013, at 6:59 PM, Mandy Chung wrote: > This is a simple patch that adds a new jdeps -jdkinternals option to make it easier for developers to find dependencies on the JDK internal APIs: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ > > Mandy From weijun.wang at oracle.com Wed Nov 27 01:57:12 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 27 Nov 2013 01:57:12 +0000 Subject: hg: jdk8/tl/jdk: 8029181: ts.sh generates invalid file after JDK-8027026 Message-ID: <20131127015726.CB73162897@hg.openjdk.java.net> Changeset: 1738dfb0c52a Author: weijun Date: 2013-11-27 09:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1738dfb0c52a 8029181: ts.sh generates invalid file after JDK-8027026 Reviewed-by: vinnie, mullan ! test/sun/security/tools/jarsigner/TimestampCheck.java From david.holmes at oracle.com Wed Nov 27 07:40:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 17:40:46 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> Message-ID: <5295A1FE.1020800@oracle.com> On 27/11/2013 2:16 AM, David Chase wrote: > > On 2013-11-26, at 8:12 AM, David Chase wrote: >> On 2013-11-26, at 7:32 AM, David Holmes wrote: >>> On 26/11/2013 10:16 PM, David Chase wrote: >>>> >>>> On 2013-11-26, at 7:12 AM, David Holmes wrote: >>>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>>> >>>>>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>>>>> >>>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>>> I have to do a minor revision to the hotspot commit anyway. >>>>>> Is sun.misc.VM also loaded very early anyway? >>>>> >>>>> No you would have to add it as for Unsafe. >>>> >>>> But it's loaded early anyway as a normal consequence of other class loading, right? >>> >>> What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. >> >> 120 is earlier than 135, so by that measure it is superior. >> Do you see any other problems with the change? >> The method's not at all "Unsafe" in the technical sense of the word, so it is just a matter of choosing a good home. > > On further investigation, change to sun.misc.VM would be the first time that hotspot knows of the existence of sun.misc.VM; sun.misc.Unsafe is already filled with methods that the runtime knows about (intrinsics, etc). I think Unsafe is better. Okay. David > David > From thomas.stuefe at gmail.com Wed Nov 27 08:33:59 2013 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Wed, 27 Nov 2013 09:33:59 +0100 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) In-Reply-To: <5294AF06.1050502@oracle.com> References: <5294A85F.2090903@oracle.com> <5294AF06.1050502@oracle.com> Message-ID: > > > My personal view is that we should link to libz where possible (already > so on Mac, but not the default on Linux or Solaris). Clearly we still have > to allow for platforms where it doesn't exist (Windows only I think) and in > that case we should periodically update it (as we did in both JDK 7 and JDK > 8). It may be time to look at upgrading it again (for JDK 9 as this is not > something to touch in the end-game of a release). > > I can see arguments for both sides (linking statically vs using the system zlib) and I'm leaning toward the former. Errors or incompatibilities in the zlib could be really harmful, and I rather use the zlib I ran all my tests with instead of the system zlib which may or may not be out of date or show regressions. So, if I were to recode this fix again to not change the zlib - which is not so trivial - do you think there is a chance that this fix gets examined and maybe pulled into the OpenJDK? ..Thomas From peter.levart at gmail.com Wed Nov 27 09:20:42 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Nov 2013 10:20:42 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5295A1FE.1020800@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> Message-ID: <5295B96A.6090902@gmail.com> 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 wrote: >>> On 2013-11-26, at 7:32 AM, David Holmes >>> wrote: >>>> On 26/11/2013 10:16 PM, David Chase wrote: >>>>> >>>>> On 2013-11-26, at 7:12 AM, David Holmes >>>>> wrote: >>>>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>>>> >>>>>>> On 2013-11-25, at 9:18 PM, David Holmes >>>>>>> wrote: >>>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as >>>>>>>> good a place as any - though maybe sun.misc.VM is marginally >>>>>>>> better? >>>>>>> >>>>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>>>> I have to do a minor revision to the hotspot commit anyway. >>>>>>> Is sun.misc.VM also loaded very early anyway? >>>>>> >>>>>> No you would have to add it as for Unsafe. >>>>> >>>>> But it's loaded early anyway as a normal consequence of other >>>>> class loading, right? >>>> >>>> What do you mean by "early"? It isn't a pre-loaded class but it >>>> will be loaded during system initialization. It is approx the 120th >>>> class to be loaded. Unsafe is about 135th. >>> >>> 120 is earlier than 135, so by that measure it is superior. >>> Do you see any other problems with the change? >>> The method's not at all "Unsafe" in the technical sense of the word, >>> so it is just a matter of choosing a good home. >> >> On further investigation, change to sun.misc.VM would be the first >> time that hotspot knows of the existence of sun.misc.VM; >> sun.misc.Unsafe is already filled with methods that the runtime knows >> about (intrinsics, etc). I think Unsafe is better. > > Okay. > > David Hi David(s), Excuse me for my ignorance, but does pre-loading the class involve it's initialization? Is static initializer called at that time? Even if it is not at that time, it surely should be called before first invocation of a method on that class (the throwIllegalAccessError() method in this case). You need a reference to this method very early - even before system initialization starts. How early do you expect first "faulty invocations" could occur that need to call this method? What if calling that method triggers non-trivial initialization which in turn encounters another faulty invocation? sun.misc.Unsafe has a non-trivial static initialization which involves "registerNatives()" native method invocation, and it also calls: sun.reflect.Reflection.registerMethodsToFilter(Unsafe.class, "getUnsafe"); ...which initializes hell lot of things (like java.util.HashMap for example, which in who knows which incarnation included random hash seed initialization which triggered random number generator initialization with gathering of random seed from various sources, ...) sun.misc.VM on the other hand, only has the following static initialization: private static final Object lock = new Object(); static { initialize(); } private native static void initialize(); Are you okay with all possible interactions of this initialization on all platforms? I think a new class with only this method would be a safer choice. Regarding back-porting, even if sun.misc.Unsafe is used as the holder for that method, this new method will have to be added to sun.misc.Unsafe on those legacy platforms in order to obtain this new Method *. If the method is not found, the VM would have to behave as before. Couldn't the pre-loading of classes be made such that some of them are optional? Regard, Peter > >> David >> From david.holmes at oracle.com Wed Nov 27 10:03:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 20:03:32 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5295B96A.6090902@gmail.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> <5295B96A.6090902@gmail.com> Message-ID: <5295C374.9010304@oracle.com> 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 wrote: >>>> On 2013-11-26, at 7:32 AM, David Holmes >>>> wrote: >>>>> On 26/11/2013 10:16 PM, David Chase wrote: >>>>>> On 2013-11-26, at 7:12 AM, David Holmes >>>>>> wrote: >>>>>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>>>>> On 2013-11-25, at 9:18 PM, David Holmes >>>>>>>> wrote: >>>>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as >>>>>>>>> good a place as any - though maybe sun.misc.VM is marginally >>>>>>>>> better? >>>>>>>> >>>>>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>>>>> I have to do a minor revision to the hotspot commit anyway. >>>>>>>> Is sun.misc.VM also loaded very early anyway? >>>>>>> >>>>>>> No you would have to add it as for Unsafe. >>>>>> >>>>>> But it's loaded early anyway as a normal consequence of other >>>>>> class loading, right? >>>>> >>>>> What do you mean by "early"? It isn't a pre-loaded class but it >>>>> will be loaded during system initialization. It is approx the 120th >>>>> class to be loaded. Unsafe is about 135th. >>>> >>>> 120 is earlier than 135, so by that measure it is superior. >>>> Do you see any other problems with the change? >>>> The method's not at all "Unsafe" in the technical sense of the word, >>>> so it is just a matter of choosing a good home. >>> >>> On further investigation, change to sun.misc.VM would be the first >>> time that hotspot knows of the existence of sun.misc.VM; >>> sun.misc.Unsafe is already filled with methods that the runtime knows >>> about (intrinsics, etc). I think Unsafe is better. >> >> Okay. >> >> David > > Hi David(s), > > Excuse me for my ignorance, but does pre-loading the class involve it's > initialization? Is static initializer called at that time? No, pre-load is simply loading not initialization. Static initialization gets triggerred via a controlled process as it is very delicate. Even if it is > not at that time, it surely should be called before first invocation of > a method on that class (the throwIllegalAccessError() method in this > case). You need a reference to this method very early - even before > system initialization starts. How early do you expect first "faulty > invocations" could occur that need to call this method? What if calling > that method triggers non-trivial initialization which in turn encounters > another faulty invocation? These faults should only appear in application classes so generally everything should be initialized well before you need to use this method. If a core library class has a bug that triggered this need to call this method then yes it is possible that it might happen too early to succeed - but that is quite normal for the core classes, there are a number of things that can happen too early in the initialization process to work (eg throwing exceptions, using assertions). That said I'm not sure how this could fail in that all we need is a reference to the method to put in the vtable and we have that after loading. Then all that can go wrong is that we can't actually throw the exception. > sun.misc.Unsafe has a non-trivial static initialization which involves > "registerNatives()" native method invocation, and it also calls: registerNative is not an issue > sun.reflect.Reflection.registerMethodsToFilter(Unsafe.class, "getUnsafe"); > > ...which initializes hell lot of things (like java.util.HashMap for > example, which in who knows which incarnation included random hash seed > initialization which triggered random number generator initialization > with gathering of random seed from various sources, ...) > sun.misc.VM on the other hand, only has the following static > initialization: > > private static final Object lock = new Object(); > > static { > initialize(); > } > private native static void initialize(); > > > Are you okay with all possible interactions of this initialization on > all platforms? The only time the initialization order would be changed by this fix is if one of the classes initialized before-hand had a bug that required this fix to come into affect. That is obviously a JDK bug and is extremely unlikely to happen. Note that sun.misc.VM is currently initialized 44th while Unsafe is 61st. I don't see any issues with this fix in that regard. > I think a new class with only this method would be a safer choice. > Regarding back-porting, even if sun.misc.Unsafe is used as the holder > for that method, this new method will have to be added to > sun.misc.Unsafe on those legacy platforms in order to obtain this new > Method *. If the method is not found, the VM would have to behave as > before. Couldn't the pre-loading of classes be made such that some of > them are optional? It already supports optional classes. David H. -------- > > > Regard, Peter > >> >>> David >>> > From Alan.Bateman at oracle.com Wed Nov 27 10:03:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Nov 2013 10:03:59 +0000 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <52951CF1.5060404@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> <52951CF1.5060404@oracle.com> Message-ID: <5295C38F.6050406@oracle.com> On 26/11/2013 22:13, huizhe wang wrote: > > Ah, I missed that. I took it for granted that since > ServiceLoader.load(service) uses TCCL, load(service, null) would use > TCCL. I've updated the webrev now: > > http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ > It looks good now but I'm still wondering about tests. Are you planning to push any tests with this? -Alan From paul.sandoz at oracle.com Wed Nov 27 11:02:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Nov 2013 12:02:14 +0100 Subject: RFR 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task Message-ID: <2DDDB8DD-1794-4166-8603-3921CB070C79@oracle.com> Hi, https://bugs.openjdk.java.net/browse/JDK-8029164 http://cr.openjdk.java.net/~psandoz/tl/JDK-8029164-thenCompose-async/webrev/ This fixes an issue with CompletableFuture.thenCompose. If the composing future is already completed before the call to thenCompose (or completes during some part of the call to thenCompose) and the composing function returns a future that is not yet completed then there is race to set the result, usually won by thenCompose which incorrectly sets the result to null, due to an errant conditional statement. Doug has reviewed and committed the fix to the 166 repo and we have double checked there are no similar errors lurking in other areas of CompletableFuture code. Paul. From chris.hegarty at oracle.com Wed Nov 27 11:12:19 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 27 Nov 2013 11:12:19 +0000 Subject: RFR 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task In-Reply-To: <2DDDB8DD-1794-4166-8603-3921CB070C79@oracle.com> References: <2DDDB8DD-1794-4166-8603-3921CB070C79@oracle.com> Message-ID: <5295D393.9010201@oracle.com> Looks good to me Paul. -Chris. On 27/11/13 11:02, Paul Sandoz wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-8029164 > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8029164-thenCompose-async/webrev/ > > This fixes an issue with CompletableFuture.thenCompose. > > If the composing future is already completed before the call to thenCompose (or completes during some part of the call to thenCompose) and the composing function returns a future that is not yet completed then there is race to set the result, usually won by thenCompose which incorrectly sets the result to null, due to an errant conditional statement. > > Doug has reviewed and committed the fix to the 166 repo and we have double checked there are no similar errors lurking in other areas of CompletableFuture code. > > Paul. > From peter.levart at gmail.com Wed Nov 27 11:53:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Nov 2013 12:53:57 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5295C374.9010304@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> <5295B96A.6090902@gmail.com> <5295C374.9010304@oracle.com> Message-ID: <5295DD55.90607@gmail.com> 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 >>>> wrote: >>>>> On 2013-11-26, at 7:32 AM, David Holmes >>>>> wrote: >>>>>> On 26/11/2013 10:16 PM, David Chase wrote: >>>>>>> On 2013-11-26, at 7:12 AM, David Holmes >>>>>>> wrote: >>>>>>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>>>>>> On 2013-11-25, at 9:18 PM, David Holmes >>>>>>>>> wrote: >>>>>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as >>>>>>>>>> good a place as any - though maybe sun.misc.VM is marginally >>>>>>>>>> better? >>>>>>>>> >>>>>>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>>>>>> I have to do a minor revision to the hotspot commit anyway. >>>>>>>>> Is sun.misc.VM also loaded very early anyway? >>>>>>>> >>>>>>>> No you would have to add it as for Unsafe. >>>>>>> >>>>>>> But it's loaded early anyway as a normal consequence of other >>>>>>> class loading, right? >>>>>> >>>>>> What do you mean by "early"? It isn't a pre-loaded class but it >>>>>> will be loaded during system initialization. It is approx the 120th >>>>>> class to be loaded. Unsafe is about 135th. >>>>> >>>>> 120 is earlier than 135, so by that measure it is superior. >>>>> Do you see any other problems with the change? >>>>> The method's not at all "Unsafe" in the technical sense of the word, >>>>> so it is just a matter of choosing a good home. >>>> >>>> On further investigation, change to sun.misc.VM would be the first >>>> time that hotspot knows of the existence of sun.misc.VM; >>>> sun.misc.Unsafe is already filled with methods that the runtime knows >>>> about (intrinsics, etc). I think Unsafe is better. >>> >>> Okay. >>> >>> David >> >> Hi David(s), >> >> Excuse me for my ignorance, but does pre-loading the class involve it's >> initialization? Is static initializer called at that time? > > No, pre-load is simply loading not initialization. Static > initialization gets triggerred via a controlled process as it is very > delicate. > > Even if it is >> not at that time, it surely should be called before first invocation of >> a method on that class (the throwIllegalAccessError() method in this >> case). You need a reference to this method very early - even before >> system initialization starts. How early do you expect first "faulty >> invocations" could occur that need to call this method? What if calling >> that method triggers non-trivial initialization which in turn encounters >> another faulty invocation? > > These faults should only appear in application classes so generally > everything should be initialized well before you need to use this > method. If a core library class has a bug that triggered this need to > call this method then yes it is possible that it might happen too > early to succeed - but that is quite normal for the core classes, > there are a number of things that can happen too early in the > initialization process to work (eg throwing exceptions, using > assertions). > > That said I'm not sure how this could fail in that all we need is a > reference to the method to put in the vtable and we have that after > loading. Then all that can go wrong is that we can't actually throw > the exception. > >> sun.misc.Unsafe has a non-trivial static initialization which involves >> "registerNatives()" native method invocation, and it also calls: > > registerNative is not an issue > >> sun.reflect.Reflection.registerMethodsToFilter(Unsafe.class, >> "getUnsafe"); >> >> ...which initializes hell lot of things (like java.util.HashMap for >> example, which in who knows which incarnation included random hash seed >> initialization which triggered random number generator initialization >> with gathering of random seed from various sources, ...) > >> sun.misc.VM on the other hand, only has the following static >> initialization: >> >> private static final Object lock = new Object(); >> >> static { >> initialize(); >> } >> private native static void initialize(); >> >> >> Are you okay with all possible interactions of this initialization on >> all platforms? > > The only time the initialization order would be changed by this fix is > if one of the classes initialized before-hand had a bug that required > this fix to come into affect. That is obviously a JDK bug and is > extremely unlikely to happen. > > Note that sun.misc.VM is currently initialized 44th while Unsafe is 61st. > > I don't see any issues with this fix in that regard. I see. Thanks for explanation, David. > >> I think a new class with only this method would be a safer choice. >> Regarding back-porting, even if sun.misc.Unsafe is used as the holder >> for that method, this new method will have to be added to >> sun.misc.Unsafe on those legacy platforms in order to obtain this new >> Method *. If the method is not found, the VM would have to behave as >> before. Couldn't the pre-loading of classes be made such that some of >> them are optional? > > It already supports optional classes. 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 of platform... Sorry for noise. Regards, Peter > > David H. > -------- > >> >> >> Regard, Peter >> >>> >>>> David >>>> >> From Alan.Bateman at oracle.com Wed Nov 27 12:04:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Nov 2013 12:04:11 +0000 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <529535C7.8090403@oracle.com> References: <529535C7.8090403@oracle.com> Message-ID: <5295DFBB.1070008@oracle.com> On 26/11/2013 23:59, Mandy Chung wrote: > This is a simple patch that adds a new jdeps -jdkinternals option to > make it easier for developers to find dependencies on the JDK internal > APIs: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ This looks good (and I can't think of a better name for the option). Do you think this needs a test as otherwise this option will not be exercised? -Alan From balchandra.vaidya at oracle.com Wed Nov 27 12:38:41 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Wed, 27 Nov 2013 12:38:41 +0000 Subject: Request to review JDK-8028094 In-Reply-To: References: <528B57BA.3060102@oracle.com> <528CD120.3050101@oracle.com> <528DFBE9.60003@oracle.com> Message-ID: <5295E7D1.70009@oracle.com> Hi Martin, I have incorporated your contribution into following webrev. Please review the changes. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev.01/ I have tested it on a linux machine, and the test is passing. The sleep processes are killed when the pkill command exists on the machine. The test is passing without killing sleep when the pkill command is not present. Thanks Balchandra On 11/26/13 06:15 PM, Martin Buchholz wrote: > I dredged up some more memories about this part of ProcessBuilder and > this part of Basic.java. > > As the comment indicates, there are remaining issues (might even call > it a "bug") where the grandchild can keep a file descriptor open and > thus cause a hang in the java process. Which is very hard to fix; I > advise you not to try, unless perhaps your name is Alan Bateman. > > But here's an improvement to Basic.java which should kill off the > sleep if pkill is available, not fail if pkill is not available, and > keep the wakeupJeff-protected code working as intended until some > brave soul tries to tackle the lingering bug in ProcessBuilder. > > https://www.youtube.com/watch?v=XP7q2o1Z0w8 > > --- a/test/java/lang/ProcessBuilder/Basic.java > +++ b/test/java/lang/ProcessBuilder/Basic.java > @@ -2017,7 +2017,6 @@ > && new File("/bin/bash").exists() > && new File("/bin/sleep").exists()) { > final String[] cmd = { "/bin/bash", "-c", > "(/bin/sleep 6666)" }; > - final String[] cmdkill = { "/bin/bash", "-c", > "(/usr/bin/pkill -f \"sleep 6666\")" }; > final ProcessBuilder pb = new ProcessBuilder(cmd); > final Process p = pb.start(); > final InputStream stdout = p.getInputStream(); > @@ -2045,13 +2044,13 @@ > stdout.close(); > stderr.close(); > stdin.close(); > - new ProcessBuilder(cmdkill).start(); > //---------------------------------------------------------- > // There remain unsolved issues with asynchronous close. > // Here's a highly non-portable experiment to > demonstrate: > //---------------------------------------------------------- > if (Boolean.getBoolean("wakeupJeff!")) { > System.out.println("wakeupJeff!"); > + long startTime = System.nanoTime(); > // Initialize signal handler for INTERRUPT_SIGNAL. > new > FileInputStream("/bin/sleep").getChannel().close(); > // Send INTERRUPT_SIGNAL to every thread in this > java. > @@ -2064,8 +2063,18 @@ > }; > new ProcessBuilder(wakeupJeff).start().waitFor(); > // If wakeupJeff worked, reader probably got EBADF. > - reader.join(); > + long timeout = 60L * 1000L; > + reader.join(timeout); > + long elapsedTimeMillis = > + (System.nanoTime() - startTime) / (1024L * > 1024L); > + check(elapsedTimeMillis < timeout); > + check(!reader.isAlive()); > } > + // Try to clean up the sleep process, but don't fret > about it. > + try { > + new ProcessBuilder("/usr/bin/pkill", "-f", "sleep > 6666") > + .start(); > + } catch (IOException noPkillCommandInstalled) { } > } > } catch (Throwable t) { unexpected(t); } > > > > > On Thu, Nov 21, 2013 at 4:26 AM, Balchandra Vaidya > > > wrote: > > > Hi Martin, > > > > > + check(elapsedTimeMillis < timeout); > > + *check(!reader.isAlive());* > > > The line check(!reader.isAlive()) is causing the test failure > when the pkill command is not available. Any idea ? The > test is passing with check(reader.isAlive()). > > > The modified test is passing when the pkill command is > available. > > > When the pkill command is not available, the test is/was > failing without try block around > new ProcessBuilder(cmdkill).start(). > > So, without placing the above line under try block was a > mistake. I will make the correction. > > > Thanks > Balchandra > > > > On 11/20/13 03:11 PM, Balchandra Vaidya wrote: >> >> Thanks Martin. I will incorporate your suggested improvements, and >> will send out another webrev. >> >> Regards >> Balchandra >> >> On 19/11/2013 22:53, Martin Buchholz wrote: >>> I see this is already submitted. >>> >>> I thought I could do better than using pkill, but no - there is >>> no convenient communication from the java process to the >>> grandchild. This is a hairy test! >>> >>> Nevertheless, I would like you to incorporate the following >>> improvements: >>> - invoke pkill directly >>> - do some extra checking >>> - join with reader thread >>> - don't fail if pkill is not available >>> >>> --- a/test/java/lang/ProcessBuilder/Basic.java >>> +++ b/test/java/lang/ProcessBuilder/Basic.java >>> @@ -2016,7 +2016,7 @@ >>> && new File("/bin/bash").exists() >>> && new File("/bin/sleep").exists()) { >>> final String[] cmd = { "/bin/bash", "-c", >>> "(/bin/sleep 6666)" }; >>> - final String[] cmdkill = { "/bin/bash", "-c", >>> "(/usr/bin/pkill -f \"sleep 6666\")" }; >>> + final String[] cmdkill = { "/usr/bin/pkill", >>> "-f", "sleep 6666" }; >>> final ProcessBuilder pb = new ProcessBuilder(cmd); >>> final Process p = pb.start(); >>> final InputStream stdout = p.getInputStream(); >>> @@ -2044,7 +2044,9 @@ >>> stdout.close(); >>> stderr.close(); >>> stdin.close(); >>> - new ProcessBuilder(cmdkill).start(); >>> + // Try to clean up the sleep process, but don't >>> fret about it. >>> + try { new ProcessBuilder(cmdkill).start(); } >>> + catch (IOException noPkillCommandInstalled) { } >>> //---------------------------------------------------------- >>> // There remain unsolved issues with >>> asynchronous close. >>> // Here's a highly non-portable experiment to >>> demonstrate: >>> @@ -2063,8 +2065,14 @@ >>> }; >>> new >>> ProcessBuilder(wakeupJeff).start().waitFor(); >>> // If wakeupJeff worked, reader probably >>> got EBADF. >>> - reader.join(); >>> } >>> + long startTime = System.nanoTime(); >>> + long timeout = 60L * 1000L; >>> + reader.join(timeout); >>> + long elapsedTimeMillis = >>> + (System.nanoTime() - startTime) / (1024L * >>> 1024L); >>> + check(elapsedTimeMillis < timeout); >>> + check(!reader.isAlive()); >>> } >>> } catch (Throwable t) { unexpected(t); } >>> >>> >>> >>> On Tue, Nov 19, 2013 at 4:21 AM, Balchandra Vaidya >>> >> > wrote: >>> >>> >>> Hi, >>> >>> Here is one possible solution for the issue JDK-8028094. >>> http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ >>> >>> >>> I am not sure pkill is available in all Unix flavor at >>> /usr/bin directory, >>> but it is present in Solaris and OEL 6. I have tested on Solaris >>> and OEL and "sleep 6666" is no longer left over. >>> >>> >>> Thanks >>> Balchandra >>> >>> >>> >> > > From david.r.chase at oracle.com Wed Nov 27 13:40:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Nov 2013 08:40:51 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5295DD55.90607@gmail.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> <5295B96A.6090902@gmail.com> <5295C374.9010304@oracle.com> <5295DD55.90607@gmail.com> Message-ID: <35B7D2E9-C22A-4090-BBB7-F522B0F365D4@oracle.com> On 2013-11-27, at 6:53 AM, Peter Levart 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 of platform... > > Sorry for noise. Noise is okay. This fix was a PITA, init order can hide surprises, and I don't mind going over the details. As to the activation of the code in question, practically never, except in tests or when bozo-bytecode-generators (a remark I resemble) are making mistakes. The "initialize" of the throwIAE method is deferred until loading of a class that performs an illegal-access-override of an interface method -- e.g., interface I { int m(); } class C implements I { private int m(); } so even that requires an inconsistent set of classes, which is unlikely in any normal initialization. Longer-term/hoped-for plan is to create a custom throwIAE method each time this happens so that an informative error message can be included -- "C.m() overrides I.m() but is private" (or protected, or package-inaccessible) -- but that is tricky because we don't have a good place to put the method; by the time we learn this about class C, we have rewritten its constant pool and it is difficult to add more, and the constant pool cache is fragile-yet-critical-to-interpreter-performance. So for now, I did this. I did test it as much as I could figure out how, including running the regression test in Netbeans and poking around, and also running it under jdb on some embedded platforms and trying to think of commands that might trigger embarrassing failures. The push is in the pipeline, but if you have other tests you can suggest, it is not too late to pull the emergency stop (in particular, I am gatekeeper for hs-comp this month, so I can put off the next turn of the crank till the last moment). David From martinrb at google.com Wed Nov 27 15:03:54 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Nov 2013 07:03:54 -0800 Subject: Request to review JDK-8028094 In-Reply-To: <5295E7D1.70009@oracle.com> References: <528B57BA.3060102@oracle.com> <528CD120.3050101@oracle.com> <528DFBE9.60003@oracle.com> <5295E7D1.70009@oracle.com> Message-ID: Thanks. Looks good. Sorry for having burdened posterity with this test snippet. IIRC I originally tried to write an ordinary test, but the test succeeded in demonstrating there was a (difficult) bug left in the code. Hence the current state of the test code. I'll add this to my (fix-when-I-retire) list. On Wed, Nov 27, 2013 at 4:38 AM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > Hi Martin, > > I have incorporated your contribution into following > webrev. Please review the changes. > http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev.01/ > > I have tested it on a linux machine, and the test is passing. > The sleep processes are killed when the pkill command exists > on the machine. The test is passing without killing sleep when the > pkill command is not present. > > > Thanks > Balchandra > > > > On 11/26/13 06:15 PM, Martin Buchholz wrote: > > I dredged up some more memories about this part of ProcessBuilder and this > part of Basic.java. > > As the comment indicates, there are remaining issues (might even call it > a "bug") where the grandchild can keep a file descriptor open and thus > cause a hang in the java process. Which is very hard to fix; I advise you > not to try, unless perhaps your name is Alan Bateman. > > But here's an improvement to Basic.java which should kill off the sleep > if pkill is available, not fail if pkill is not available, and keep the > wakeupJeff-protected code working as intended until some brave soul tries > to tackle the lingering bug in ProcessBuilder. > > https://www.youtube.com/watch?v=XP7q2o1Z0w8 > > --- a/test/java/lang/ProcessBuilder/Basic.java > +++ b/test/java/lang/ProcessBuilder/Basic.java > @@ -2017,7 +2017,6 @@ > && new File("/bin/bash").exists() > && new File("/bin/sleep").exists()) { > final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep > 6666)" }; > - final String[] cmdkill = { "/bin/bash", "-c", > "(/usr/bin/pkill -f \"sleep 6666\")" }; > final ProcessBuilder pb = new ProcessBuilder(cmd); > final Process p = pb.start(); > final InputStream stdout = p.getInputStream(); > @@ -2045,13 +2044,13 @@ > stdout.close(); > stderr.close(); > stdin.close(); > - new ProcessBuilder(cmdkill).start(); > > //---------------------------------------------------------- > // There remain unsolved issues with asynchronous close. > // Here's a highly non-portable experiment to demonstrate: > > //---------------------------------------------------------- > if (Boolean.getBoolean("wakeupJeff!")) { > System.out.println("wakeupJeff!"); > + long startTime = System.nanoTime(); > // Initialize signal handler for INTERRUPT_SIGNAL. > new > FileInputStream("/bin/sleep").getChannel().close(); > // Send INTERRUPT_SIGNAL to every thread in this java. > @@ -2064,8 +2063,18 @@ > }; > new ProcessBuilder(wakeupJeff).start().waitFor(); > // If wakeupJeff worked, reader probably got EBADF. > - reader.join(); > + long timeout = 60L * 1000L; > + reader.join(timeout); > + long elapsedTimeMillis = > + (System.nanoTime() - startTime) / (1024L * 1024L); > + check(elapsedTimeMillis < timeout); > + check(!reader.isAlive()); > } > + // Try to clean up the sleep process, but don't fret > about it. > + try { > + new ProcessBuilder("/usr/bin/pkill", "-f", "sleep > 6666") > + .start(); > + } catch (IOException noPkillCommandInstalled) { } > } > } catch (Throwable t) { unexpected(t); } > > > > > > On Thu, Nov 21, 2013 at 4:26 AM, Balchandra Vaidya < > balchandra.vaidya at oracle.com> wrote: > >> >> Hi Martin, >> >> >> >> > + check(elapsedTimeMillis < timeout); >> > + *check(!reader.isAlive());* >> >> >> The line check(!reader.isAlive()) is causing the test failure >> when the pkill command is not available. Any idea ? The >> test is passing with check(reader.isAlive()). >> >> >> The modified test is passing when the pkill command is >> available. >> >> >> When the pkill command is not available, the test is/was >> failing without try block around >> new ProcessBuilder(cmdkill).start(). >> >> So, without placing the above line under try block was a >> mistake. I will make the correction. >> >> >> Thanks >> Balchandra >> >> >> >> On 11/20/13 03:11 PM, Balchandra Vaidya wrote: >> >> >> Thanks Martin. I will incorporate your suggested improvements, and >> will send out another webrev. >> >> Regards >> Balchandra >> >> On 19/11/2013 22:53, Martin Buchholz wrote: >> >> I see this is already submitted. >> >> I thought I could do better than using pkill, but no - there is no >> convenient communication from the java process to the grandchild. This is >> a hairy test! >> >> Nevertheless, I would like you to incorporate the following >> improvements: >> - invoke pkill directly >> - do some extra checking >> - join with reader thread >> - don't fail if pkill is not available >> >> --- a/test/java/lang/ProcessBuilder/Basic.java >> +++ b/test/java/lang/ProcessBuilder/Basic.java >> @@ -2016,7 +2016,7 @@ >> && new File("/bin/bash").exists() >> && new File("/bin/sleep").exists()) { >> final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep >> 6666)" }; >> - final String[] cmdkill = { "/bin/bash", "-c", >> "(/usr/bin/pkill -f \"sleep 6666\")" }; >> + final String[] cmdkill = { "/usr/bin/pkill", "-f", >> "sleep 6666" }; >> final ProcessBuilder pb = new ProcessBuilder(cmd); >> final Process p = pb.start(); >> final InputStream stdout = p.getInputStream(); >> @@ -2044,7 +2044,9 @@ >> stdout.close(); >> stderr.close(); >> stdin.close(); >> - new ProcessBuilder(cmdkill).start(); >> + // Try to clean up the sleep process, but don't fret >> about it. >> + try { new ProcessBuilder(cmdkill).start(); } >> + catch (IOException noPkillCommandInstalled) { } >> >> //---------------------------------------------------------- >> // There remain unsolved issues with asynchronous close. >> // Here's a highly non-portable experiment to >> demonstrate: >> @@ -2063,8 +2065,14 @@ >> }; >> new ProcessBuilder(wakeupJeff).start().waitFor(); >> // If wakeupJeff worked, reader probably got EBADF. >> - reader.join(); >> } >> + long startTime = System.nanoTime(); >> + long timeout = 60L * 1000L; >> + reader.join(timeout); >> + long elapsedTimeMillis = >> + (System.nanoTime() - startTime) / (1024L * 1024L); >> + check(elapsedTimeMillis < timeout); >> + check(!reader.isAlive()); >> } >> } catch (Throwable t) { unexpected(t); } >> >> >> >> >> On Tue, Nov 19, 2013 at 4:21 AM, Balchandra Vaidya < >> balchandra.vaidya at oracle.com> wrote: >> >>> >>> Hi, >>> >>> Here is one possible solution for the issue JDK-8028094. >>> http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ >>> >>> I am not sure pkill is available in all Unix flavor at /usr/bin >>> directory, >>> but it is present in Solaris and OEL 6. I have tested on Solaris >>> and OEL and "sleep 6666" is no longer left over. >>> >>> >>> Thanks >>> Balchandra >>> >>> >>> >> >> >> > > From scolebourne at joda.org Wed Nov 27 15:11:53 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 27 Nov 2013 15:11:53 +0000 Subject: Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge must refuse null values] In-Reply-To: References: Message-ID: On 26 November 2013 17:35, Martin Buchholz wrote: > I haven't looked in depth, but I agree with Stephen's analysis. This API > and its javadoc needs work. > E.g. It's not clear that the purpose of Map.compute is to *update* the > mapping for key in the map. I actually felt that the names of all four methods felt wrong. compute and merge seem like unfortunate choices. > Instead of "The default implementation makes no guarantees about > synchronization or atomicity properties of this method." we should boldly > say that the default implementation is *not* atomic, even if the underlying > map is. Saying that the default implementation is not atomic sounds uncontroversial. Stephen From dalibor.topic at oracle.com Wed Nov 27 15:52:05 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 27 Nov 2013 16:52:05 +0100 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <5295DFBB.1070008@oracle.com> References: <529535C7.8090403@oracle.com> <5295DFBB.1070008@oracle.com> Message-ID: <52961525.6060503@oracle.com> On 11/27/13 1:04 PM, Alan Bateman wrote: > On 26/11/2013 23:59, Mandy Chung wrote: >> This is a simple patch that adds a new jdeps -jdkinternals option to make it easier for developers to find dependencies on the JDK internal APIs: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ > This looks good (and I can't think of a better name for the option). Do you think this needs a test as otherwise this option will not be exercised? -jdkinternals doesn't necessarily imply that using the JDK internal APIs is dangerous. Maybe calling it -warn would be better, and offer a path forward to in the future warn about other objectionable dependency constructs (circles, etc.). cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From peter.levart at gmail.com Wed Nov 27 16:17:42 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Nov 2013 17:17:42 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <35B7D2E9-C22A-4090-BBB7-F522B0F365D4@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> <5295B96A.6090902@gmail.com> <5295C374.9010304@oracle.com> <5295DD55.90607@gmail.com> <35B7D2E9-C22A-4090-BBB7-F522B0F365D4@oracle.com> Message-ID: <52961B26.4020409@gmail.com> On 11/27/2013 02:40 PM, David Chase wrote: > On 2013-11-27, at 6:53 AM, Peter Levart 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 of platform... >> >> Sorry for noise. > Noise is okay. This fix was a PITA, init order can hide surprises, and I don't mind going over the details. > > As to the activation of the code in question, practically never, except in tests or when bozo-bytecode-generators (a remark I resemble) are making mistakes. The "initialize" of the throwIAE method is deferred until loading of a class that performs an illegal-access-override of an interface method -- e.g., interface I { int m(); } class C implements I { private int m(); } so even that requires an inconsistent set of classes, which is > unlikely in any normal initialization. > > Longer-term/hoped-for plan is to create a custom throwIAE method each time this happens so that an informative error message can be included -- "C.m() overrides I.m() but is private" (or protected, or package-inaccessible) -- but that is tricky because we don't have a good place to put the method; by the time we learn this about class C, we have rewritten its constant pool and it is difficult to add more, and the constant pool cache is fragile-yet-critical-to-interpreter-performance. So for now, I did this. > > I did test it as much as I could figure out how, including running the regression test in Netbeans and poking around, and also running it under jdb on some embedded platforms and trying to think of commands that might trigger embarrassing failures. > > The push is in the pipeline, but if you have other tests you can suggest, it is not too late to pull the emergency stop (in particular, I am gatekeeper for hs-comp this month, so I can put off the next turn of the crank till the last moment). > > David > Your and David Holmes' answers have pretty much silenced me. I can't think of any more troubles... About creating an informative error message: is there a way to dynamically dig-out from the VM, while executing the single system-wide throwIAE method, the symbolic invocation attributes of a call-site together with the target object in case of instance method invocation? From that data it could be possible to re-compute the context in question, I assume... Regards, Peter From mandy.chung at oracle.com Wed Nov 27 16:46:46 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 Nov 2013 08:46:46 -0800 Subject: Review Request for 8029216: (jdeps) Provide a specific option to report JDK internal APIs In-Reply-To: <52961525.6060503@oracle.com> References: <529535C7.8090403@oracle.com> <5295DFBB.1070008@oracle.com> <52961525.6060503@oracle.com> Message-ID: <529621F6.5050403@oracle.com> On 11/27/2013 7:52 AM, Dalibor Topic wrote: > On 11/27/13 1:04 PM, Alan Bateman wrote: >> On 26/11/2013 23:59, Mandy Chung wrote: >>> This is a simple patch that adds a new jdeps -jdkinternals option to make it easier for developers to find dependencies on the JDK internal APIs: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8029216/webrev.00/ >> This looks good (and I can't think of a better name for the option). Do you think this needs a test as otherwise this option will not be exercised? I will add a test for this option. > -jdkinternals doesn't necessarily imply that using the JDK internal APIs is dangerous. Maybe calling it -warn would be better, and offer a path forward to in the future warn about other objectionable dependency constructs (circles, etc.). By default it already highlights any dependency on JDK internal APIs. This option is to make it easier for developers to filter them and I think -jdkinternals is more obvious. I'll keep the -warn idea to explore in the future. thanks Mandy From huizhe.wang at oracle.com Wed Nov 27 17:03:01 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 27 Nov 2013 09:03:01 -0800 Subject: RFR (JAXP) 8028822 : Error in the documentation for newFactory method of the javax.xml.stream factories In-Reply-To: <5295C38F.6050406@oracle.com> References: <5293C676.7020304@oracle.com> <5294C79F.1080907@oracle.com> <5294EA97.4060804@oracle.com> <5295149D.6070206@oracle.com> <52951CF1.5060404@oracle.com> <5295C38F.6050406@oracle.com> Message-ID: <529625C5.9030604@oracle.com> On 11/27/2013 2:03 AM, Alan Bateman wrote: > On 26/11/2013 22:13, huizhe wang wrote: >> >> Ah, I missed that. I took it for granted that since >> ServiceLoader.load(service) uses TCCL, load(service, null) would use >> TCCL. I've updated the webrev now: >> >> http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8028822/webrev/ >> > It looks good now but I'm still wondering about tests. Are you > planning to push any tests with this? I'm not adding new tests. I labeled it noreg-jck and Paul has identified the specific test cases. -Joe > > -Alan From naoto.sato at oracle.com Wed Nov 27 18:01:47 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 27 Nov 2013 18:01:47 +0000 Subject: hg: jdk8/tl/jdk: 8028771: regression test java/util/Locale/LocaleProviders.sh failed Message-ID: <20131127180205.D38E9628AC@hg.openjdk.java.net> Changeset: 2370d285d08b Author: naoto Date: 2013-11-27 10:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2370d285d08b 8028771: regression test java/util/Locale/LocaleProviders.sh failed Reviewed-by: alanb ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From daniel.fuchs at oracle.com Wed Nov 27 19:23:34 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 27 Nov 2013 20:23:34 +0100 Subject: 8029281: Synchronization issues in Logger and LogManager Message-ID: <529646B6.50900@oracle.com> Hi, Please find below a webrev for: 8029281: Synchronization issues in Logger and LogManager Now some comments on the fix: LogManager: When a logger was garbage collected, and then a new logger of the same name requested, addlocalLogger used to call LoggerContext.removeLogger to remove the stale reference and replace it by a new one. But sometime, the stale reference was still in the reference queue, which caused the *new* logger to be wrongly removed later when the reference queue was drained. LogManager was also missing some synchronization for its 'props' variable. Logger: userBundle & resourceBundleName were sometimes accessed within a synchronized block, and sometimes without. In particular the getters were not synchronized, which could cause race conditions because an other thread could see inconsistent data. I also had to refactor the two methods getEffectiveResourceBundle() and getResourceBundleName() into a single method. The code there might be a bit more difficult to follow, because I made sure it preserved the former behavior wrt to what will be set in the LogRecord in doLog(). Tests: The new TestLoggerBundleSync.java has been great to test the issues above in both Logger & LogManager (it detected the drainLoggerRefQueueBounded issue). Since I had to touch at drainLoggerRefQueueBounded to make TestLoggerBundleSync.java pass I also threw in a TestLogConfigurationDeadLock.java to make sure I hadn't introduced any new deadlock (and it detected the lack of synchronization in LogManager.props). best regards, -- daniel From brian.burkhalter at oracle.com Wed Nov 27 19:39:51 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Nov 2013 11:39:51 -0800 Subject: JDK 8 RFR 4891331: BigInteger a.multiply(a) should use squaring code Message-ID: <13DE1334-1EA5-4E58-AE44-9E62F56F17C6@oracle.com> Continuing from the end of this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022399.html ... Issue: https://bugs.openjdk.java.net/browse/JDK-4891331 Webrev: http://cr.openjdk.java.net/~bpb/4891331/webrev.2 After running more micro-benchmark performance tests using a threshold on the int-length of BigInteger above which squaring code is used for multiply(this), the value 20 appears more apropos. This is the value in the updated webrev. This threshold appears to prevent regressions across the array of machines tested (Linux, Mac, Windows, AMD, Intel). In some cases of course, the threshold prevents performance improvement which would otherwise occur. This is the cost of avoiding regressions. It should be noted that a small regression, on the order of 1%-3% is often observed for the case of unity int-length, i.e., when the BigInteger is equivalent to an int. This is apparently the cost of the added conditional val == this. It does not seem to me however to be of sufficient import to argue against going forward with the patch. Thanks, Brian From joe.darcy at oracle.com Wed Nov 27 19:53:25 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 Nov 2013 11:53:25 -0800 Subject: JDK 8 RFR 4891331: BigInteger a.multiply(a) should use squaring code In-Reply-To: <13DE1334-1EA5-4E58-AE44-9E62F56F17C6@oracle.com> References: <13DE1334-1EA5-4E58-AE44-9E62F56F17C6@oracle.com> Message-ID: <52964DB5.7010403@oracle.com> Hi Brian, Looks good; approved to go back. Thanks, -Joe On 11/27/2013 11:39 AM, Brian Burkhalter wrote: > Continuing from the end of this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/022399.html ... > > Issue: https://bugs.openjdk.java.net/browse/JDK-4891331 > Webrev: http://cr.openjdk.java.net/~bpb/4891331/webrev.2 > > After running more micro-benchmark performance tests using a threshold on the int-length of BigInteger above which squaring code is used for multiply(this), the value 20 appears more apropos. This is the value in the updated webrev. This threshold appears to prevent regressions across the array of machines tested (Linux, Mac, Windows, AMD, Intel). In some cases of course, the threshold prevents performance improvement which would otherwise occur. This is the cost of avoiding regressions. > > It should be noted that a small regression, on the order of 1%-3% is often observed for the case of unity int-length, i.e., when the BigInteger is equivalent to an int. This is apparently the cost of the added conditional val == this. It does not seem to me however to be of sufficient import to argue against going forward with the patch. > > Thanks, > > Brian From peter.levart at gmail.com Wed Nov 27 21:34:06 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 27 Nov 2013 22:34:06 +0100 Subject: 8029281: Synchronization issues in Logger and LogManager In-Reply-To: <529646B6.50900@oracle.com> References: <529646B6.50900@oracle.com> Message-ID: <5296654E.8070909@gmail.com> 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 public method LogManager.addLogger The 1st and 2nd are guarded by LoggerContext.this lock, but the 3rd is unguarded. What can happen is the following: Thread1: LogManager.addLogger(someLogger) LogManager.drainLoggerRefQueueBounded() // finds some enqueued LoggerWeakRef for name == 'X.Y' and... LoggerWeakRef.dispose() // this is 1st call to dispose, so... synchronized (LoggerWeakRef.this) { disposed = true; } ---context switch--- Thread2: LogManager.addLogger(logger{name=='X.Y'}) LogManager.drainLoggerRefQueueBounded() // no enqueued refs... LoggerContext.addLocalLogger(logger{name=='X.Y'}, true) LoggerWeakRef ref = namedLoggers.get(name); // returns a non-null ref ('X.Y' still points to a cleared weak ref) if (ref.get() == null) { ref.dispose(); // this is a 2nd call to this ref, so it returns quickly } // ... namedLoggers gets new entry, etc... LogNode node = getNode(name); // get node for 'X.Y' * node.loggerRef = ref;* ---context switch--- Thread1: (still in LoggerWeakRef.dispose()) if (node != null) { * node.loggerRef = null;* // clear LogNode's weak ref to us *!!! NOT QUITE !!!* ... so Thread1 erroneously clears the reference from Node to new LoggerWeakRef that was just added by Thread2 ... One way to fix this is to synchronize the clearing of node.logerRef on node.context too. I would make LoggerWeakRef.node and parentRef fields volatile and do the following: final class LoggerWeakRef extends WeakReference { private String name; // for namedLoggers cleanup private volatile LogNode node; // for loggerRef cleanup private volatile WeakReference parentRef; // for kids cleanup LoggerWeakRef(Logger logger) { super(logger, loggerRefQueue); name = logger.getName(); // save for namedLoggers cleanup } // dispose of this LoggerWeakRef object void dispose() { LogNode node = this.node; if (node != null) { synchronized (node.context) { node = this.node; // double-checked locking if (node != null) { // if we have a LogNode, then we were a named Logger // so clear namedLoggers weak ref to us node.context.removeLoggerRef(name, this); name = null; // clear our ref to the Logger's name node.loggerRef = null; // clear LogNode's weak ref to us this.node = null; // clear our ref to LogNode } } } WeakReference parentRef = this.parentRef; if (parentRef != null) { // this LoggerWeakRef has or had a parent Logger this.parentRef = null; // clear our weak ref to the parent Logger (racy, but harmless) Logger parent = parentRef.get(); if (parent != null) { // the parent Logger is still there so clear the // parent Logger's weak ref to us parent.removeChildLogger(this); } } } ... What do you think? That's all for today. Will check the rest of patch tomorrow. Regards, Peter On 11/27/2013 08:23 PM, Daniel Fuchs wrote: > Hi, > > Please find below a webrev for: > > 8029281: Synchronization issues in Logger and LogManager > > I believe this changeset will also fix JDK-8027670 and > JDK-8029092 - which I have thus closed as duplicates of JDK-8029281. > > webrev: > > Now some comments on the fix: > > LogManager: > > When a logger was garbage collected, and then a new logger > of the same name requested, addlocalLogger used to call > LoggerContext.removeLogger to remove the stale reference > and replace it by a new one. But sometime, the stale reference > was still in the reference queue, which caused the *new* logger > to be wrongly removed later when the reference queue was drained. > > LogManager was also missing some synchronization for its 'props' > variable. > > Logger: > > userBundle & resourceBundleName were sometimes accessed within > a synchronized block, and sometimes without. In particular the > getters were not synchronized, which could cause race conditions > because an other thread could see inconsistent data. > > I also had to refactor the two methods getEffectiveResourceBundle() > and getResourceBundleName() into a single method. > The code there might be a bit more difficult to follow, > because I made sure it preserved the former behavior wrt to > what will be set in the LogRecord in doLog(). > > Tests: > > The new TestLoggerBundleSync.java has been great to test > the issues above in both Logger & LogManager (it detected > the drainLoggerRefQueueBounded issue). > > Since I had to touch at drainLoggerRefQueueBounded to make > TestLoggerBundleSync.java pass I also threw in a > TestLogConfigurationDeadLock.java to make sure I hadn't introduced > any new deadlock (and it detected the lack of synchronization > in LogManager.props). > > best regards, > > -- daniel > > > From jason.uh at oracle.com Wed Nov 27 23:27:00 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Wed, 27 Nov 2013 23:27:00 +0000 Subject: hg: jdk8/tl/jdk: 8021418: Intermittent: SSLSocketSSLEngineTemplate.java test fails with timeout Message-ID: <20131127232713.D3EFD628C0@hg.openjdk.java.net> Changeset: 5ac7cd164300 Author: juh Date: 2013-11-27 15:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ac7cd164300 8021418: Intermittent: SSLSocketSSLEngineTemplate.java test fails with timeout Reviewed-by: xuelei, wetmore Contributed-by: rajan.halade at oracle.com ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From zhangshj at linux.vnet.ibm.com Thu Nov 28 07:53:44 2013 From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang) Date: Thu, 28 Nov 2013 15:53:44 +0800 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter Message-ID: <5296F688.1050806@linux.vnet.ibm.com> Hi, We get a deadlock between java.util.logging.FileHandler and java.util.logging.ConsoleHandler when we are using a customized formatter in these handlers. Here is the simple test case. http://cr.openjdk.java.net/~zhangshj/deadlockInHandlers/deadlockInHandlers.zip Run "java -Djava.util.logging.config.file=logging.properties TestThread", it will hang immediately. And this is the stack trace in dump file "Thread-1": at java.util.logging.StreamHandler.publish(StreamHandler.java:205) - waiting to lock <0x00000000ec52e0c0> (a java.util.logging.ConsoleHandler) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:118) at java.util.logging.Logger.log(Logger.java:617) at java.util.logging.Logger.doLog(Logger.java:638) at java.util.logging.Logger.log(Logger.java:661) at java.util.logging.Logger.info(Logger.java:1289) at CustomerFormatter.format(CustomerFormatter.java:16) at java.util.logging.StreamHandler.publish(StreamHandler.java:210) - locked <0x00000000ec51ab90> (a java.util.logging.FileHandler) at java.util.logging.FileHandler.publish(FileHandler.java:614) - locked <0x00000000ec51ab90> (a java.util.logging.FileHandler) at java.util.logging.Logger.log(Logger.java:617) at java.util.logging.Logger.doLog(Logger.java:638) at java.util.logging.Logger.log(Logger.java:661) at java.util.logging.Logger.info(Logger.java:1289) at TestThread$1.run(TestThread.java:14) at java.lang.Thread.run(Thread.java:724) "Thread-2": at java.util.logging.FileHandler.publish(FileHandler.java:611) - waiting to lock <0x00000000ec51ab90> (a java.util.logging.FileHandler) at java.util.logging.Logger.log(Logger.java:617) at java.util.logging.Logger.doLog(Logger.java:638) at java.util.logging.Logger.log(Logger.java:661) at java.util.logging.Logger.info(Logger.java:1289) at CustomerFormatter.format(CustomerFormatter.java:16) at java.util.logging.StreamHandler.publish(StreamHandler.java:210) - locked <0x00000000ec52e0c0> (a java.util.logging.ConsoleHandler) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:118) at java.util.logging.Logger.log(Logger.java:617) at java.util.logging.Logger.doLog(Logger.java:638) at java.util.logging.Logger.log(Logger.java:661) at java.util.logging.Logger.info(Logger.java:1289) at TestThread$1.run(TestThread.java:14) at java.lang.Thread.run(Thread.java:724) 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 not synchronized, the deadlock happens. This violates the Java doc for java.util.logging.Logger that says "All methods on Logger are multi-thread safe." Currently we have 2 workarounds. First is to add 2 lines in the logging.properties to force CustomerFormatter use new instance of FileHandler and ConsoleHandler like this, CustomerFormatter.handlers = java.util.logging.FileHandler, java.util.logging.ConsoleHandler CustomerFormatter.useParentHandlers = false Second is to synchronize the logger.info call in TestThread test case. I'm not sure whether we should fix this problem in JDK. The fix I can image is to synchronize each call to handler.publish() in Logger.log, but I think this would cause performance degradation. Another solution is to add some documents in Java doc to state that Logger is not "so much" multi-thread safe. Any suggestion or better fix? -- Regards, Shi Jun Zhang From jaroslav.bachorik at oracle.com Thu Nov 28 08:16:50 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 28 Nov 2013 08:16:50 +0000 Subject: hg: jdk8/tl/jdk: 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS Message-ID: <20131128081759.A7522628D2@hg.openjdk.java.net> Changeset: 4afe1281c837 Author: jbachorik Date: 2013-11-28 09:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4afe1281c837 6987597: ManagementFactory.getGarbageCollectorMXBeans() returns empty list with CMS Reviewed-by: mchung ! test/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java ! test/java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java From headius at headius.com Thu Nov 28 09:31:50 2013 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 28 Nov 2013 03:31:50 -0600 Subject: Different error decoding Shift-JIS sequence in JDK8 In-Reply-To: <529321A2.40905@oracle.com> References: <528F5A2B.2000402@oracle.com> <529321A2.40905@oracle.com> Message-ID: What incantation is required to get Sherman to offer his perspective? :-) I accept that it may be after Thanksgiving, but I need to know the situation since we have tests for JRuby that depended on this character being valid Shift-JIS. - Charlie On Mon, Nov 25, 2013 at 4:08 AM, Se?n Coffey wrote: > Sherman can answer this best. The 8008386 fix for 8 differs from earlier > updates since alot of the code was rewritten in this area. The initial > report was identified as a regression in JDK6. Back in 2005, the 6227339 fix > changed behaviour which meant that invalid single byte characters were > treated incorrectly when decoding Shift_JIS encoded bytes. It meant that two > bytes are decoded to a "?" character rather than one. The valid single byte > characters are lost as a result and I believe this was all unintended when > the 6227339 fix was made. > > Changes made in 8008386 mean that the case of a malformed character (legal > leading byte) followed by a valid single byte should now return a > replacement character for the first malformed byte and a correctly decoded > single byte character. > > regards, > Sean. > > > On 22/11/2013 13:20, Alan Bateman wrote: >> >> On 22/11/2013 11:02, Charles Oliver Nutter wrote: >>> >>> Apologies if this is not the correct place to post this, bit i18n >>> seemed more focused on languages and localization than the mechanics >>> of transcoding. >>> >>> I have noticed a behavioral difference in JDK8 decoding a two-byte >>> Shift-JIS sequence. Specifically, JDK8 appears to report malformed >>> input for what should be a valid Shift-JIS sequence, where JDK7 >>> reported that the character was unmappable. >> >> I assume this is related to JDK-8008386 [1] and I'm sure Sherman or Sean >> will jump in to explain this (which seems to be related to a long standing >> regression). >> >> -Alan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8008386 > > >> Apologies if this is not the correct place to post this, bit i18n >> seemed more focused on languages and localization than the mechanics >> of transcoding. >> >> I have noticed a behavioral difference in JDK8 decoding a two-byte >> Shift-JIS sequence. Specifically, JDK8 appears to report malformed >> input for what should be a valid Shift-JIS sequence, where JDK7 >> reported that the character was unmappable. >> >> The code to reproduce is fairly simple: >> >> byte[] bytes = {(byte)0xEF, 0x40}; >> CharsetDecoder decoder = Charset.forName("Shift-JIS").newDecoder(); >> System.out.println(decoder.decode(ByteBuffer.wrap(bytes), >> CharBuffer.allocate(2), false)); >> >> Note that this is pumping the decoder directly and specifying partial >> input (false). We use this mechanism in JRuby for transcoding >> arbitrary byte[] from one encoding to another. >> >> The result of running this on JDK7 is "UNMAPPABLE[2]" while the result >> on JDK8 is "MALFORMED[1]". >> >> Information online is spotty as to whether this sequence is valid. It >> does appear on the table for [JIS X >> 203](http://x0213.org/codetable/sjis-0213-2004-std.txt) and several >> articles on Shift-JIS claim that it is at worst undefined and at best >> valid. So I'm leaning toward this being a bug in JDK8's Shift-JIS >> decoder. >> >> Note that on JDK7 it is "unmappable", which may mean this code >> represents a character with no equivalent in Unicode. >> >> I have uploaded my code to github here: >> https://github.com/headius/jdk8_utf8_decoding_bug >> >> Thoughts? >> >> - Charlie > > > From peter.levart at gmail.com Thu Nov 28 12:13:40 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 28 Nov 2013 13:13:40 +0100 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <5296F688.1050806@linux.vnet.ibm.com> References: <5296F688.1050806@linux.vnet.ibm.com> Message-ID: <52973374.4010004@gmail.com> 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 not synchronized, the > deadlock happens. Hello Shi Jun Zhang, Why do you use Logger.log in the CustomerFormatter? What are you achieving by it? Do you want to re-route and re-format messages destined for one handler to some other Logger and consequently handler? On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: > This violates the Java doc for java.util.logging.Logger that says "All > methods on Logger are multi-thread safe." I don't know for sure, but I think that "multi-thread-safe" does not imply "dead-lock-safe". It would be good if java logging used less locks and be less deadlock-prone though. So we should see if it is possible to remove some locks, not to add more locking... Regards, Peter From daniel.fuchs at oracle.com Thu Nov 28 14:26:51 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 Nov 2013 15:26:51 +0100 Subject: 8029281: Synchronization issues in Logger and LogManager In-Reply-To: <5296654E.8070909@gmail.com> References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com> Message-ID: <529752AB.2050101@oracle.com> On 11/27/13 10:34 PM, Peter Levart wrote: > Hi Daniel, > > I have started looking at the LogManager change first, and here's the > 1st race I found... Hi Peter, Thanks a lot for your feedback! see below... > The new method LoggerWeakRef.dispose() can be called from 3 places: > > - LoggerContext.addLocalLogger > - LoggerContext.findLogger > - LogManager.drainLoggerRefQueueBounded which is called from public > method LogManager.addLogger > > The 1st and 2nd are guarded by LoggerContext.this lock, but the 3rd is > unguarded. > > What can happen is the following: > > Thread1: > LogManager.addLogger(someLogger) > LogManager.drainLoggerRefQueueBounded() // finds some enqueued > LoggerWeakRef for name == 'X.Y' and... > LoggerWeakRef.dispose() // this is 1st call to dispose, so... > synchronized (LoggerWeakRef.this) { > disposed = true; > } > > ---context switch--- > > Thread2: > LogManager.addLogger(logger{name=='X.Y'}) > LogManager.drainLoggerRefQueueBounded() // no enqueued refs... > LoggerContext.addLocalLogger(logger{name=='X.Y'}, true) > LoggerWeakRef ref = namedLoggers.get(name); // returns > a non-null ref ('X.Y' still points to a cleared weak ref) > if (ref.get() == null) { > ref.dispose(); // this is a 2nd call to this ref, > so it returns quickly > } > // ... namedLoggers gets new entry, etc... > LogNode node = getNode(name); // get node for 'X.Y' > * node.loggerRef = ref;* > > ---context switch--- > > Thread1: (still in LoggerWeakRef.dispose()) > if (node != null) { > * node.loggerRef = null;* // clear LogNode's weak ref to > us *!!! NOT QUITE !!!* > > > ... so Thread1 erroneously clears the reference from Node to new > LoggerWeakRef that was just added by Thread2 ... Damn. I believe that you're right! I overlooked the fact that LogNode is reused. Locking on LogNode.context is indeed a good way of solving the issue. The only method that we will call from within the lock is LogNode.context.rmoveLoggerRef(name this) - and that already requires a lock on LogNode.context so it would be safe. I have also double checked the places where LogNode.loggerRef is set, and all those places (except in dispose() so far) are already from within a lock on LoggerContext. I think I would prefer however to keep the 'disposed' flag - and to check whether LogNode.loggerRef == this before clearing it. Given that - as I said - LogNode.loggerRef is always modified from within a lock on LoggerContext I think the following would work: void dispose() { synchronized(this) { if (disposed) return; disposed = true; } final LogNode n = node; if (n != null) { synchronized (n.context) { n.context.removeLoggerRef(name, this); name = null; if (n.loggerRef == this) { n.loggerRef = null; } node = null; } } if (parentRef != null) { Logger parent = parentRef.get(); if (parent != null) { parent.removeChildLogger(this); } parentRef = null; // clear our weak ref to the parent Logger } } I don't think 'node' or 'parentRef' need to be volatile. That - said - we could still declare them volatile to make it obvious that the code in 'dispose()' will not see a stale value (I don't think it can, but having the variables volatile would make it obvious). If we reach 'dispose()' then it does mean that the LoggerWeakRef is no longer used - so I believe the real thing we need to guard against is actually modifications of the LogNode state - rather modification of the LoggerWeakRef state. Therefore I believe that the important thing is to guarantee that all modifications to LogNode.loggerRef happen from within a lock on LoggerContext. I'd also like to keep the disposed flag because it makes it immediately obvious that the method is processed only once (so we haven't to worry about making it re-entrant at every step). Would you agree with the code above? best regards, and congratulations for catching this! -- daniel > > > One way to fix this is to synchronize the clearing of node.logerRef on > node.context too. I would make LoggerWeakRef.node and parentRef fields > volatile and do the following: > > > final class LoggerWeakRef extends WeakReference { > private String name; // for > namedLoggers cleanup > private volatile LogNode node; // for loggerRef > cleanup > private volatile WeakReference parentRef; // for kids > cleanup > > LoggerWeakRef(Logger logger) { > super(logger, loggerRefQueue); > name = logger.getName(); // save for namedLoggers cleanup > } > > // dispose of this LoggerWeakRef object > void dispose() { > LogNode node = this.node; > if (node != null) { > synchronized (node.context) { > node = this.node; // double-checked locking > if (node != null) { > // if we have a LogNode, then we were a named > Logger > // so clear namedLoggers weak ref to us > node.context.removeLoggerRef(name, this); > name = null; // clear our ref to the Logger's name > > node.loggerRef = null; // clear LogNode's weak > ref to us > this.node = null; // clear our ref to LogNode > } > } > } > > WeakReference parentRef = this.parentRef; > if (parentRef != null) { > // this LoggerWeakRef has or had a parent Logger > this.parentRef = null; // clear our weak ref to the > parent Logger (racy, but harmless) > Logger parent = parentRef.get(); > if (parent != null) { > // the parent Logger is still there so clear the > // parent Logger's weak ref to us > parent.removeChildLogger(this); > } > } > } > > ... > > > What do you think? > > That's all for today. Will check the rest of patch tomorrow. > > > Regards, Peter > > > > On 11/27/2013 08:23 PM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a webrev for: >> >> 8029281: Synchronization issues in Logger and LogManager >> > >> I believe this changeset will also fix JDK-8027670 and >> JDK-8029092 - which I have thus closed as duplicates of JDK-8029281. >> >> webrev: >> >> Now some comments on the fix: >> >> LogManager: >> >> When a logger was garbage collected, and then a new logger >> of the same name requested, addlocalLogger used to call >> LoggerContext.removeLogger to remove the stale reference >> and replace it by a new one. But sometime, the stale reference >> was still in the reference queue, which caused the *new* logger >> to be wrongly removed later when the reference queue was drained. >> >> LogManager was also missing some synchronization for its 'props' >> variable. >> >> Logger: >> >> userBundle & resourceBundleName were sometimes accessed within >> a synchronized block, and sometimes without. In particular the >> getters were not synchronized, which could cause race conditions >> because an other thread could see inconsistent data. >> >> I also had to refactor the two methods getEffectiveResourceBundle() >> and getResourceBundleName() into a single method. >> The code there might be a bit more difficult to follow, >> because I made sure it preserved the former behavior wrt to >> what will be set in the LogRecord in doLog(). >> >> Tests: >> >> The new TestLoggerBundleSync.java has been great to test >> the issues above in both Logger & LogManager (it detected >> the drainLoggerRefQueueBounded issue). >> >> Since I had to touch at drainLoggerRefQueueBounded to make >> TestLoggerBundleSync.java pass I also threw in a >> TestLogConfigurationDeadLock.java to make sure I hadn't introduced >> any new deadlock (and it detected the lack of synchronization >> in LogManager.props). >> >> best regards, >> >> -- daniel >> >> >> > From daniel.fuchs at oracle.com Thu Nov 28 17:21:21 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 Nov 2013 18:21:21 +0100 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <52973374.4010004@gmail.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> Message-ID: <52977B91.6030903@oracle.com> Hi Shi Jun Zhang, I agree with Peter. It is strange that CustomFormatter calls Logger.log. This looks like the source of the deadlock. The Logger API can be customized in many ways - and when you can plugin custom classes and objects you can introduce new opportunity for deadlocks. Concerning the Javadoc - I don't know whether that could be satisfactorily improved. In JDK 8, we have a new annotation, @implNote - which can give non normative hints on what the implementation does under the hood. I am not sure whether documenting the locking mechanism that j.u.l uses behind the scenes would be appropriate - or even feasible. I am afraid that trying to describe every lock that is involved in every possible case along every possible code path would be hard to achieve. I believe the fact that Handler.publish() is usually synchronized is kind of natural: by which I mean that I would naively expect it, given that you wouldn't want one message to overlap with the next. Maybe that could be documented. best regards, -- daniel On 11/28/13 1:13 PM, Peter Levart wrote: > 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 not synchronized, the >> deadlock happens. > > Hello Shi Jun Zhang, > > Why do you use Logger.log in the CustomerFormatter? What are you > achieving by it? Do you want to re-route and re-format messages destined > for one handler to some other Logger and consequently handler? > > On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: >> This violates the Java doc for java.util.logging.Logger that says "All >> methods on Logger are multi-thread safe." > > I don't know for sure, but I think that "multi-thread-safe" does not > imply "dead-lock-safe". It would be good if java logging used less locks > and be less deadlock-prone though. So we should see if it is possible to > remove some locks, not to add more locking... > > Regards, Peter > From Alan.Bateman at oracle.com Thu Nov 28 19:29:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Nov 2013 19:29:05 +0000 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) In-Reply-To: References: <5294A85F.2090903@oracle.com> <5294AF06.1050502@oracle.com> Message-ID: <52979981.10305@oracle.com> On 27/11/2013 08:33, Thomas St?fe wrote: > > I can see arguments for both sides (linking statically vs using the > system zlib) and I'm leaning toward the former. Errors or > incompatibilities in the zlib could be really harmful, and I rather > use the zlib I ran all my tests with instead of the system zlib which > may or may not be out of date or show regressions. Statically linking has its advantages when you are creating a binary that needs to run on many distributions. However, I think we have to allow for anyone to link against the system zlib. I believe it might even be a hard requirement for many of the Linux distributions (there are folks from the IcedTea project on this list that will know a lot more about that topic). > > So, if I were to recode this fix again to not change the zlib - which > is not so trivial - do you think there is a chance that this fix gets > examined and maybe pulled into the OpenJDK? I don't see any reason why not. So I would suggest go ahead and see if this can be fixed without changing zlib. If you can come up with a patch then bring it here and we can review/discuss it. -Alan From sebastian.sickelmann at gmx.de Thu Nov 28 21:43:41 2013 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 28 Nov 2013 22:43:41 +0100 Subject: Access Checking for MethodHandles.Lookup broken! In-Reply-To: <5294DDF0.4030808@gmx.de> References: <528F08BF.2030100@gmx.de> <5291D033.7070106@gmx.de> <95B973DF-86E5-4C68-85C6-1CAA64B0E184@oracle.com> <5294DDF0.4030808@gmx.de> Message-ID: <5297B90D.1070508@gmx.de> Hi, i finally found some time to have a look at this. I think it is a problem in MethodHandleNatives.resolve which is called from MemberName.resolve to figure out which MemberName is the one that should be resolved. The wrong behavior of jdk1.7.0_17 was very usefull to find this, because it has the same error for fields(see [0]) which is broken for virtual method lookups in 1.7.0_45. Let's assume we have a class Example with some private fields and methods and an class SubExample which extends Example. When MethodHandleNatives is called with a MemberName.clazz [2] == SubExample.class and the MemberName.name on private field of Example and an lookupClass == SubExample.class then in 1.7.0_17 a MemberName is returned with the declaring class equals to SubExample.class in contrary to 1.7.0_45 where a MemberName is returned with the declaring class equals to Example.class. When we take a look at the same example for a lookup of a virtual method call we see that MethodHandleNatives: When MethodHandleNatives is called with a MemberName.clazz == SubExample.class and the MemberName.name on private method of Example and an lookupClass == SubExample.class then a MemberName is returned with the declaring class equals to SubExample.class which is wrong. SubExample isn't the declaring class of this method. And some time later in sun.invoke.util.VerifyAccess.isMemberAccessible it run's into this code here: if (defc == lookupClass) return true; // easy check; all self-access is OK which skips any further checking. Should we file a bug for this? -- Sebastian [2] which should be the declaring class. But in this example it isn't. Am 26.11.2013 18:44, schrieb Sebastian Sickelmann: > Hi, > > A few days ago I thought I had found a bug in > MethodHandles.Lookup.findGetter/findSetter[0] , but i was wrong > it seemed to be fixed in the latest JDK7 and JDK8 versions. I search the > Bugdatabase for a ticket relating my issue > and didn't found one. So i looked at the regressiontests for > java/lang/invoke in the jdk repository. I found some > test but it doesn't seem to produce the error i had expected on my old > jdk7-version. So i decided to add some > additional regressiontests. See patch[1] for more information of it. > Everything is fine. It chrashes multiple times with my old jdk7 and it > runs almost with 1.7.0_45 and 1.8.0-ea-b109. > But unfortunatly it runs only almost. The last testcase in > testFindPrivate() chrashes on jdk7 and jdk8. > > checkIllegalAccessException(new CTROE(){ public void run() throws ReflectiveOperationException{ > PRIV_SUBCLASS.findVirtual(SubExample.class, "pri_v0",MethodType.methodType(void.class)); > }}); > > > The code tries to access the private method Example.pri_v0 from an > lookup instance of a subclass of Example. > I expect that there should be an IllegalAccessException, but > unfortunatly it works. > > Sorry for cross-posting. But i think it is more related to core-libs-dev. > > I would love to work on a fix of this. But it will take some days for me to take a closer look to the implementation. > > > -- Sebastian > > [0] > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010148.html > [1] > https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/hgexport_0.txt > > > Am 26.11.2013 03:03, schrieb John Rose: >> On Nov 24, 2013, at 2:08 AM, Sebastian Sickelmann >> > wrote: >> >>> I am sorry. Due to a configuration failure in my IDE had run with >>> 1.7.0_16 >>> >>> Checked this again with 1.7.0_45 and 1.8.0-ea-b109 and everything is >>> fine. >>> >>> Sorry for the mailing-list noise. >> If a MethodHandles.Lookup call allows more access to a method than its >> corresponding bytecode behavior, that is definitely a bug. >> >> Recent updates to the javadoc for Lookup (in JDK 8) emphasize this >> correspondence principle strongly. If it breaks, we want to know >> about it. >> >> Thanks for the report and the double-check. >> >> ? John > > From zhangshj at linux.vnet.ibm.com Fri Nov 29 05:58:20 2013 From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang) Date: Fri, 29 Nov 2013 13:58:20 +0800 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <52973374.4010004@gmail.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> Message-ID: <52982CFC.5000105@linux.vnet.ibm.com> On 11/28/2013 8:13 PM, Peter Levart wrote: > 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 not synchronized, >> the deadlock happens. > > Hello Shi Jun Zhang, > > Why do you use Logger.log in the CustomerFormatter? What are you > achieving by it? Do you want to re-route and re-format messages > destined for one handler to some other Logger and consequently handler? Hi Peter, This happens in a real complicated application and I simply the test case. There is some complicated logic in the CustomerFormatter and we add some debug log messages in CustomerFormatter.format() method. As CustomerFormatter.format() method is called in Logger.log, there would be an infinite recursion if we do nothing, then we have to add some check to break the recursion. The things we are doing here are 1) using CustomerFormatter as logger formatter and logging in an application. 2) logging some debug information in CustomerFormatter. > > On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: >> This violates the Java doc for java.util.logging.Logger that says >> "All methods on Logger are multi-thread safe." > > I don't know for sure, but I think that "multi-thread-safe" does not > imply "dead-lock-safe". It would be good if java logging used less > locks and be less deadlock-prone though. So we should see if it is > possible to remove some locks, not to add more locking... > > Regards, Peter > I agree that we need less locks in java logging, java logging is getting more complicated and getting more deadlock recently. -- Regards, Shi Jun Zhang From thomas.stuefe at gmail.com Fri Nov 29 06:02:24 2013 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Fri, 29 Nov 2013 07:02:24 +0100 Subject: Proposed fix for JDK-8028804 (Deflater.deflateBytes() may produce corrupted output on Deflater level/strategy change) In-Reply-To: <52979981.10305@oracle.com> References: <5294A85F.2090903@oracle.com> <5294AF06.1050502@oracle.com> <52979981.10305@oracle.com> Message-ID: So, if I were to recode this fix again to not change the zlib - which is >> not so trivial - do you think there is a chance that this fix gets examined >> and maybe pulled into the OpenJDK? >> > I don't see any reason why not. So I would suggest go ahead and see if > this can be fixed without changing zlib. If you can come up with a patch > then bring it here and we can review/discuss it. > > Thanks, I will do that. Have a nice Thanksgiving! ..Thomas From zhangshj at linux.vnet.ibm.com Fri Nov 29 06:19:09 2013 From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang) Date: Fri, 29 Nov 2013 14:19:09 +0800 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <52977B91.6030903@oracle.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> <52977B91.6030903@oracle.com> Message-ID: <529831DD.5080408@linux.vnet.ibm.com> On 11/29/2013 1:21 AM, Daniel Fuchs wrote: > Hi Shi Jun Zhang, > > I agree with Peter. > It is strange that CustomFormatter calls Logger.log. This looks like > the source of the deadlock. Hi Daniel, I explained why we call Logger.log in CustomerFormatter in another mail replied to Peter, CustomerFormatter is complicated and we add some debug logging info in it. When we enable the debug level in logging, the deadlock happens. This is the source of the deadlock. > > The Logger API can be customized in many ways - and when you can > plugin custom classes and objects you can introduce new opportunity > for deadlocks. In my understanding, usually we should not get deadlock between 2 locks in JDK if we don't violate any Java spec or Java API doc. > > Concerning the Javadoc - I don't know whether that could > be satisfactorily improved. In JDK 8, we have a new annotation, > @implNote - which can give non normative hints on what the > implementation does under the hood. I am not sure whether > documenting the locking mechanism that j.u.l uses behind the > scenes would be appropriate - or even feasible. > I am afraid that trying to describe every lock that is involved > in every possible case along every possible code path would be > hard to achieve. I think it would be useful to document the locking mechanism with @implNote annotation. However, this problem also happens in OpenJDK 7, and even Oracle JDK 6. > > I believe the fact that Handler.publish() is usually synchronized > is kind of natural: by which I mean that I would naively expect it, > given that you wouldn't want one message to overlap with the next. > Maybe that could be documented. > > best regards, > > -- daniel > > On 11/28/13 1:13 PM, Peter Levart wrote: >> 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 not synchronized, the >>> deadlock happens. >> >> Hello Shi Jun Zhang, >> >> Why do you use Logger.log in the CustomerFormatter? What are you >> achieving by it? Do you want to re-route and re-format messages destined >> for one handler to some other Logger and consequently handler? >> >> On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: >>> This violates the Java doc for java.util.logging.Logger that says "All >>> methods on Logger are multi-thread safe." >> >> I don't know for sure, but I think that "multi-thread-safe" does not >> imply "dead-lock-safe". It would be good if java logging used less locks >> and be less deadlock-prone though. So we should see if it is possible to >> remove some locks, not to add more locking... >> >> Regards, Peter >> > -- Regards, Shi Jun Zhang From daniel.fuchs at oracle.com Fri Nov 29 09:25:16 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Nov 2013 10:25:16 +0100 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <529831DD.5080408@linux.vnet.ibm.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> <52977B91.6030903@oracle.com> <529831DD.5080408@linux.vnet.ibm.com> Message-ID: <52985D7C.8080703@oracle.com> On 11/29/13 7:19 AM, Shi Jun Zhang wrote: > On 11/29/2013 1:21 AM, Daniel Fuchs wrote: >> Hi Shi Jun Zhang, >> >> I agree with Peter. >> It is strange that CustomFormatter calls Logger.log. This looks like >> the source of the deadlock. > > Hi Daniel, > > I explained why we call Logger.log in CustomerFormatter in another > mail replied to Peter, CustomerFormatter is complicated and we add > some debug logging info in it. When we enable the debug level in > logging, the deadlock happens. This is the source of the deadlock. Hi Shi Jun Zhang, Since CustomFormatter returns a message string that will be printed in the log, would it be possible for you to add the debug information in that string (for instance at the end of the string - or at the beginning) rather than calling Logger.log from within CustomFormatter, (and hence from within Handler.publish)? best regards, -- daniel > >> >> The Logger API can be customized in many ways - and when you can >> plugin custom classes and objects you can introduce new opportunity >> for deadlocks. > > In my understanding, usually we should not get deadlock between 2 > locks in JDK if we don't violate any Java spec or Java API doc. > >> >> Concerning the Javadoc - I don't know whether that could >> be satisfactorily improved. In JDK 8, we have a new annotation, >> @implNote - which can give non normative hints on what the >> implementation does under the hood. I am not sure whether >> documenting the locking mechanism that j.u.l uses behind the >> scenes would be appropriate - or even feasible. >> I am afraid that trying to describe every lock that is involved >> in every possible case along every possible code path would be >> hard to achieve. > > I think it would be useful to document the locking mechanism with > @implNote annotation. However, this problem also happens in OpenJDK 7, > and even Oracle JDK 6. > >> >> I believe the fact that Handler.publish() is usually synchronized >> is kind of natural: by which I mean that I would naively expect it, >> given that you wouldn't want one message to overlap with the next. >> Maybe that could be documented. >> >> best regards, >> >> -- daniel >> >> On 11/28/13 1:13 PM, Peter Levart wrote: >>> 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 not synchronized, the >>>> deadlock happens. >>> >>> Hello Shi Jun Zhang, >>> >>> Why do you use Logger.log in the CustomerFormatter? What are you >>> achieving by it? Do you want to re-route and re-format messages >>> destined >>> for one handler to some other Logger and consequently handler? >>> >>> On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: >>>> This violates the Java doc for java.util.logging.Logger that says "All >>>> methods on Logger are multi-thread safe." >>> >>> I don't know for sure, but I think that "multi-thread-safe" does not >>> imply "dead-lock-safe". It would be good if java logging used less >>> locks >>> and be less deadlock-prone though. So we should see if it is >>> possible to >>> remove some locks, not to add more locking... >>> >>> Regards, Peter >>> >> > > From chris.hegarty at oracle.com Fri Nov 29 09:26:20 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 29 Nov 2013 09:26:20 +0000 Subject: hg: jdk8/tl/jdk: 8029348: ProblemList.txt updates (11/2013) Message-ID: <20131129092634.5775662930@hg.openjdk.java.net> Changeset: 5bcaf730ceb8 Author: tyan Date: 2013-11-29 09:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8 8029348: ProblemList.txt updates (11/2013) Reviewed-by: chegar ! test/ProblemList.txt From chris.hegarty at oracle.com Fri Nov 29 09:47:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 29 Nov 2013 09:47:58 +0000 Subject: RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java In-Reply-To: <5294C29B.4010502@oracle.com> References: <96fe0ea6-4c0b-4e90-9c58-24e244a8cc15@default> <52949851.9000407@oracle.com> <5294C29B.4010502@oracle.com> Message-ID: <7BD02DC8-A561-4EE4-83CF-3728B859159B@oracle.com> To keep things clear and obvious in the bug report, I pushed this under a new bug number, 8029348. You should update 6933803, including a summary of the details in this thread. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8 Thanks, -Chris. On 26 Nov 2013, at 15:47, Tristan Yan wrote: > Thank you. Chris. > Tristan > > On 11/26/2013 11:16 PM, Chris Hegarty wrote: >> Tristan, >> >> The removal of this test from the ProblemList.txt looks like the right thing to do. I can push this for you. >> >> -Chris. >> >> On 26 Nov 2013, at 12:47, Tristan Yan wrote: >> >>> Hi Alan >>> Could you sponsor this small change for me if you're ok with this change. >>> Thank you very much. >>> Tristan >>> >>> On 11/20/2013 12:45 PM, Tristan Yan wrote: >>>> Hi Everyone >>>> >>>> We have a test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that was put into ProblemList because of bug JDK-6933803, this test has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/diff/cb3ecb5e4ce5/test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java. We have run a 1000 times loop test for making sure there is no issue in this test anymore and we don't see any failure . I think it's good time to bring this test back from ProblemList. >>>> http://cr.openjdk.java.net/~ewang/tristan/JDK-6933803/webrev.00/test/ProblemList.txt.sdiff.html >>>> >>>> Please let me know if you have comment on this. >>>> Thank you. >>>> >>>> /Tristan Yan(Haibo Yan)/ > From zhangshj at linux.vnet.ibm.com Fri Nov 29 09:49:32 2013 From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang) Date: Fri, 29 Nov 2013 17:49:32 +0800 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <52985D7C.8080703@oracle.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> <52977B91.6030903@oracle.com> <529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com> Message-ID: <5298632C.5070701@linux.vnet.ibm.com> On 11/29/2013 5:25 PM, Daniel Fuchs wrote: > On 11/29/13 7:19 AM, Shi Jun Zhang wrote: >> On 11/29/2013 1:21 AM, Daniel Fuchs wrote: >>> Hi Shi Jun Zhang, >>> >>> I agree with Peter. >>> It is strange that CustomFormatter calls Logger.log. This looks like >>> the source of the deadlock. >> >> Hi Daniel, >> >> I explained why we call Logger.log in CustomerFormatter in another >> mail replied to Peter, CustomerFormatter is complicated and we add >> some debug logging info in it. When we enable the debug level in >> logging, the deadlock happens. This is the source of the deadlock. > Hi Shi Jun Zhang, > > Since CustomFormatter returns a message string that will be printed in > the log, would it be > possible for you to add the debug information in that string (for > instance at the end of the > string - or at the beginning) rather than calling Logger.log from > within CustomFormatter, > (and hence from within Handler.publish)? > > best regards, > > -- daniel Hi Daniel, Yes, this would be another workaround and we already have several workarounds. We'd like to see whether this problem could be solved in JDK level but not in application, or add some Java spec/doc indicating the usage like this could cause possible deadlock. -- Regards, Shi Jun Zhang > >> >>> >>> The Logger API can be customized in many ways - and when you can >>> plugin custom classes and objects you can introduce new opportunity >>> for deadlocks. >> >> In my understanding, usually we should not get deadlock between 2 >> locks in JDK if we don't violate any Java spec or Java API doc. >> >>> >>> Concerning the Javadoc - I don't know whether that could >>> be satisfactorily improved. In JDK 8, we have a new annotation, >>> @implNote - which can give non normative hints on what the >>> implementation does under the hood. I am not sure whether >>> documenting the locking mechanism that j.u.l uses behind the >>> scenes would be appropriate - or even feasible. >>> I am afraid that trying to describe every lock that is involved >>> in every possible case along every possible code path would be >>> hard to achieve. >> >> I think it would be useful to document the locking mechanism with >> @implNote annotation. However, this problem also happens in OpenJDK >> 7, and even Oracle JDK 6. >> >>> >>> I believe the fact that Handler.publish() is usually synchronized >>> is kind of natural: by which I mean that I would naively expect it, >>> given that you wouldn't want one message to overlap with the next. >>> Maybe that could be documented. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 11/28/13 1:13 PM, Peter Levart wrote: >>>> 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 not synchronized, >>>>> the >>>>> deadlock happens. >>>> >>>> Hello Shi Jun Zhang, >>>> >>>> Why do you use Logger.log in the CustomerFormatter? What are you >>>> achieving by it? Do you want to re-route and re-format messages >>>> destined >>>> for one handler to some other Logger and consequently handler? >>>> >>>> On 11/28/2013 08:53 AM, Shi Jun Zhang wrote: >>>>> This violates the Java doc for java.util.logging.Logger that says >>>>> "All >>>>> methods on Logger are multi-thread safe." >>>> >>>> I don't know for sure, but I think that "multi-thread-safe" does not >>>> imply "dead-lock-safe". It would be good if java logging used less >>>> locks >>>> and be less deadlock-prone though. So we should see if it is >>>> possible to >>>> remove some locks, not to add more locking... >>>> >>>> Regards, Peter >>>> >>> >> >> > From daniel.fuchs at oracle.com Fri Nov 29 10:08:17 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Nov 2013 11:08:17 +0100 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <5298632C.5070701@linux.vnet.ibm.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> <52977B91.6030903@oracle.com> <529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com> <5298632C.5070701@linux.vnet.ibm.com> Message-ID: <52986791.5040306@oracle.com> On 11/29/13 10:49 AM, Shi Jun Zhang wrote: > On 11/29/2013 5:25 PM, Daniel Fuchs wrote: >> On 11/29/13 7:19 AM, Shi Jun Zhang wrote: >>> On 11/29/2013 1:21 AM, Daniel Fuchs wrote: >>>> Hi Shi Jun Zhang, >>>> >>>> I agree with Peter. >>>> It is strange that CustomFormatter calls Logger.log. This looks like >>>> the source of the deadlock. >>> >>> Hi Daniel, >>> >>> I explained why we call Logger.log in CustomerFormatter in another >>> mail replied to Peter, CustomerFormatter is complicated and we add >>> some debug logging info in it. When we enable the debug level in >>> logging, the deadlock happens. This is the source of the deadlock. >> Hi Shi Jun Zhang, >> >> Since CustomFormatter returns a message string that will be printed >> in the log, would it be >> possible for you to add the debug information in that string (for >> instance at the end of the >> string - or at the beginning) rather than calling Logger.log from >> within CustomFormatter, >> (and hence from within Handler.publish)? >> >> best regards, >> >> -- daniel > > Hi Daniel, > > Yes, this would be another workaround and we already have several > workarounds. We'd like to see whether this problem could be solved in > JDK level but not in application, or add some Java spec/doc indicating > the usage like this could cause possible deadlock. > I'll have a look at what happens in Handler.publish (and subclasses) but I wouldn't put too much hope into that. As seen from the traces, the CustomFormatter, by calling Logger.log, is causing the lock inversion which is at the root of the deadlock. To fix that deadlock, the formatter would need to be called from outside the handler lock. However, removing or just moving the lock around might well introduce new unknown issues - so it will need to be carefully anaIyzed, and I am not sure it can/should be attempted in a minor JDK release. best regards -- daniel From daniel.fuchs at oracle.com Fri Nov 29 11:41:17 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Nov 2013 12:41:17 +0100 Subject: 8029281: Synchronization issues in Logger and LogManager In-Reply-To: <529752AB.2050101@oracle.com> References: <529646B6.50900@oracle.com> <5296654E.8070909@gmail.com> <529752AB.2050101@oracle.com> Message-ID: <52987D5D.6070800@oracle.com> Hi, Here is a new revision that includes Peter's findings. Thanks again for that Peter! 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 have started looking at the LogManager change first, and here's the >> 1st race I found... > > Hi Peter, > > Thanks a lot for your feedback! see below... > >> The new method LoggerWeakRef.dispose() can be called from 3 places: >> >> - LoggerContext.addLocalLogger >> - LoggerContext.findLogger >> - LogManager.drainLoggerRefQueueBounded which is called from public >> method LogManager.addLogger >> >> The 1st and 2nd are guarded by LoggerContext.this lock, but the 3rd is >> unguarded. >> >> What can happen is the following: >> >> Thread1: >> LogManager.addLogger(someLogger) >> LogManager.drainLoggerRefQueueBounded() // finds some enqueued >> LoggerWeakRef for name == 'X.Y' and... >> LoggerWeakRef.dispose() // this is 1st call to dispose, >> so... >> synchronized (LoggerWeakRef.this) { >> disposed = true; >> } >> >> ---context switch--- >> >> Thread2: >> LogManager.addLogger(logger{name=='X.Y'}) >> LogManager.drainLoggerRefQueueBounded() // no enqueued >> refs... >> LoggerContext.addLocalLogger(logger{name=='X.Y'}, true) >> LoggerWeakRef ref = namedLoggers.get(name); // returns >> a non-null ref ('X.Y' still points to a cleared weak ref) >> if (ref.get() == null) { >> ref.dispose(); // this is a 2nd call to this ref, >> so it returns quickly >> } >> // ... namedLoggers gets new entry, etc... >> LogNode node = getNode(name); // get node for 'X.Y' >> * node.loggerRef = ref;* >> >> ---context switch--- >> >> Thread1: (still in LoggerWeakRef.dispose()) >> if (node != null) { >> * node.loggerRef = null;* // clear LogNode's weak ref to >> us *!!! NOT QUITE !!!* >> >> >> ... so Thread1 erroneously clears the reference from Node to new >> LoggerWeakRef that was just added by Thread2 ... > > Damn. I believe that you're right! I overlooked the fact that LogNode is > reused. > > Locking on LogNode.context is indeed a good way of solving the issue. > The only method that we will call from within the lock is > LogNode.context.rmoveLoggerRef(name this) - and that already requires > a lock on LogNode.context so it would be safe. > > I have also double checked the places where LogNode.loggerRef is set, > and all those places (except in dispose() so far) are already from > within a lock on LoggerContext. > > I think I would prefer however to keep the 'disposed' flag - and to > check whether LogNode.loggerRef == this before clearing it. > > Given that - as I said - LogNode.loggerRef is always modified > from within a lock on LoggerContext I think the following would > work: > > void dispose() { > synchronized(this) { > if (disposed) return; > disposed = true; > } > > final LogNode n = node; > if (n != null) { > synchronized (n.context) { > n.context.removeLoggerRef(name, this); > name = null; > if (n.loggerRef == this) { > n.loggerRef = null; > } > node = null; > } > } > > if (parentRef != null) { > Logger parent = parentRef.get(); > if (parent != null) { > parent.removeChildLogger(this); > } > parentRef = null; // clear our weak ref to the parent Logger > } > } > > I don't think 'node' or 'parentRef' need to be volatile. > That - said - we could still declare them volatile to make it obvious > that the code in 'dispose()' will not see a stale value (I don't > think it can, but having the variables volatile would make it > obvious). > If we reach 'dispose()' then it does mean that the LoggerWeakRef > is no longer used - so I believe the real thing we need to guard against > is actually modifications of the LogNode state - rather modification > of the LoggerWeakRef state. > Therefore I believe that the important thing is to guarantee that > all modifications to LogNode.loggerRef happen from within a lock > on LoggerContext. > > I'd also like to keep the disposed flag because it makes it immediately > obvious that the method is processed only once (so we haven't to worry > about making it re-entrant at every step). > > Would you agree with the code above? > > best regards, and congratulations for catching this! > > -- daniel > >> >> >> One way to fix this is to synchronize the clearing of node.logerRef on >> node.context too. I would make LoggerWeakRef.node and parentRef fields >> volatile and do the following: >> >> >> final class LoggerWeakRef extends WeakReference { >> private String name; // for >> namedLoggers cleanup >> private volatile LogNode node; // for loggerRef >> cleanup >> private volatile WeakReference parentRef; // for kids >> cleanup >> >> LoggerWeakRef(Logger logger) { >> super(logger, loggerRefQueue); >> name = logger.getName(); // save for namedLoggers cleanup >> } >> >> // dispose of this LoggerWeakRef object >> void dispose() { >> LogNode node = this.node; >> if (node != null) { >> synchronized (node.context) { >> node = this.node; // double-checked locking >> if (node != null) { >> // if we have a LogNode, then we were a named >> Logger >> // so clear namedLoggers weak ref to us >> node.context.removeLoggerRef(name, this); >> name = null; // clear our ref to the >> Logger's name >> >> node.loggerRef = null; // clear LogNode's weak >> ref to us >> this.node = null; // clear our ref to >> LogNode >> } >> } >> } >> >> WeakReference parentRef = this.parentRef; >> if (parentRef != null) { >> // this LoggerWeakRef has or had a parent Logger >> this.parentRef = null; // clear our weak ref to the >> parent Logger (racy, but harmless) >> Logger parent = parentRef.get(); >> if (parent != null) { >> // the parent Logger is still there so clear the >> // parent Logger's weak ref to us >> parent.removeChildLogger(this); >> } >> } >> } >> >> ... >> >> >> What do you think? >> >> That's all for today. Will check the rest of patch tomorrow. >> >> >> Regards, Peter >> >> >> >> On 11/27/2013 08:23 PM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a webrev for: >>> >>> 8029281: Synchronization issues in Logger and LogManager >>> >> >>> I believe this changeset will also fix JDK-8027670 and >>> JDK-8029092 - which I have thus closed as duplicates of JDK-8029281. >>> >>> webrev: >>> >>> Now some comments on the fix: >>> >>> LogManager: >>> >>> When a logger was garbage collected, and then a new logger >>> of the same name requested, addlocalLogger used to call >>> LoggerContext.removeLogger to remove the stale reference >>> and replace it by a new one. But sometime, the stale reference >>> was still in the reference queue, which caused the *new* logger >>> to be wrongly removed later when the reference queue was drained. >>> >>> LogManager was also missing some synchronization for its 'props' >>> variable. >>> >>> Logger: >>> >>> userBundle & resourceBundleName were sometimes accessed within >>> a synchronized block, and sometimes without. In particular the >>> getters were not synchronized, which could cause race conditions >>> because an other thread could see inconsistent data. >>> >>> I also had to refactor the two methods getEffectiveResourceBundle() >>> and getResourceBundleName() into a single method. >>> The code there might be a bit more difficult to follow, >>> because I made sure it preserved the former behavior wrt to >>> what will be set in the LogRecord in doLog(). >>> >>> Tests: >>> >>> The new TestLoggerBundleSync.java has been great to test >>> the issues above in both Logger & LogManager (it detected >>> the drainLoggerRefQueueBounded issue). >>> >>> Since I had to touch at drainLoggerRefQueueBounded to make >>> TestLoggerBundleSync.java pass I also threw in a >>> TestLogConfigurationDeadLock.java to make sure I hadn't introduced >>> any new deadlock (and it detected the lack of synchronization >>> in LogManager.props). >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> >> > From mark.sheppard at oracle.com Fri Nov 29 14:21:33 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 29 Nov 2013 14:21:33 +0000 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Message-ID: <5298A2ED.2030409@oracle.com> Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent failure occurs on some windows test machines. this replaces a Thread.sleep(5000) with explicit synchronization between sender and receiver via a CountDownLatch regards Mark From alexyursha at gmail.com Fri Nov 29 14:43:16 2013 From: alexyursha at gmail.com (Alex Yursha) Date: Fri, 29 Nov 2013 17:43:16 +0300 Subject: Redundant check in java.security.BasicPermission.implies() Message-ID: Hi everyone, the summary of this issue is that it seems like java.security.BasicPermission.implies() executes a useless check that duplicates the functionality provided by java.lang.String.startsWith(). Below is a jdk7 code for java.security.BasicPermission.implies() method with the lines of interest highlighted in bold: public boolean implies(Permission p) { if ((p == null) || (p.getClass() != getClass())) return false; BasicPermission that = (BasicPermission) p; if (this.wildcard) { if (that.wildcard) { // one wildcard can imply another return that.path.startsWith(path); } else { *// make sure ap.path is longer so a.b.* doesn't imply a.b* * return (that.path.length() > this.path.length()) &&* * that.path.startsWith(this.path);* } } else { if (that.wildcard) { // a non-wildcard can't imply a wildcard return false; } else { return this.path.equals(that.path); } } } As the highlighted comment states, the length comparison check is performed in order to prevent such cases where "a.b.*" would imply "a.b". But the contract for java.lang.String.startsWith() is such that if the prefix length is greater than the string length than that test will fail. So it seems like java.security.BasicPermission.implies() tries to duplicate the check that is performed by java.lang.String.startswith() out of the box. Regards, Alex Yursha From Alan.Bateman at oracle.com Fri Nov 29 15:37:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Nov 2013 15:37:52 +0000 Subject: Redundant check in java.security.BasicPermission.implies() In-Reply-To: References: Message-ID: <5298B4D0.4060108@oracle.com> On 29/11/2013 14:43, Alex Yursha wrote: > Hi everyone, the summary of this issue is that it seems like > java.security.BasicPermission.implies() executes a useless check that > duplicates the functionality provided by java.lang.String.startsWith(). > > Below is a jdk7 code for java.security.BasicPermission.implies() method > with the lines of interest highlighted in bold: > On the surface this it does appear to be unnecessary so I'd suggest bringing it up on security-dev where this area is maintained (it looks like BasicPermission could do with at least some clean-up anyway). -Alan. From daniel.fuchs at oracle.com Fri Nov 29 15:40:00 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Nov 2013 16:40:00 +0100 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <5298A2ED.2030409@oracle.com> References: <5298A2ED.2030409@oracle.com> Message-ID: <5298B550.7080300@oracle.com> Hi Mark, Using a CountDownLatch looks like the right thing to do indeed. At first I thought that the instance variables would need to be declared volatile - or synchronized - but since they're set before the new Thread is created and not changed afterwards I guess it's OK. It's a bit strange to pass 'this' to another thread before 'this' is fully constructed though. Well - it's just a test ;-) best regards, -- daniel On 11/29/13 3:21 PM, Mark Sheppard wrote: > Hi > please oblige and review the following changes > > http://cr.openjdk.java.net/~msheppar/8025211/webrev/ > which address the issue raised in the bug > https://bugs.openjdk.java.net/browse/JDK-8025211 > > an intermittent failure occurs on some windows test machines. > > this replaces a Thread.sleep(5000) with explicit synchronization between > sender > and receiver via a CountDownLatch > > regards > Mark From Alan.Bateman at oracle.com Fri Nov 29 15:56:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Nov 2013 15:56:09 +0000 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <52986791.5040306@oracle.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> <52977B91.6030903@oracle.com> <529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com> <5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com> Message-ID: <5298B919.6000909@oracle.com> 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 carefully anaIyzed, and I am > not sure > it can/should be attempted in a minor JDK release. > Yes, we have to be very careful as the logging code has a history of biting the hand of those that try to improve it. For various reasons, it seems there is a lot of code that has subtle dependencies on the implementation, on the initialization in particular. In any case, you are to be applauded for tackling the synchronization issues and it would be a good project to re-examine all of this in JDK 9 to see how it would be simplified. On documenting the locking details in an @implNote (which seems to be one of the suggestions here) then we also need to be careful as I think we need some flexibility to change some of this going forward. -Alan From daniel.fuchs at oracle.com Fri Nov 29 16:05:29 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Nov 2013 17:05:29 +0100 Subject: Deadlock between FileHandler and ConsoleHandler when using customized formatter In-Reply-To: <5298B919.6000909@oracle.com> References: <5296F688.1050806@linux.vnet.ibm.com> <52973374.4010004@gmail.com> <52977B91.6030903@oracle.com> <529831DD.5080408@linux.vnet.ibm.com> <52985D7C.8080703@oracle.com> <5298632C.5070701@linux.vnet.ibm.com> <52986791.5040306@oracle.com> <5298B919.6000909@oracle.com> Message-ID: <5298BB49.9040506@oracle.com> 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 carefully anaIyzed, and I am >> not sure >> it can/should be attempted in a minor JDK release. >> > Yes, we have to be very careful as the logging code has a history of > biting the hand of those that try to improve it. For various reasons, it > seems there is a lot of code that has subtle dependencies on the > implementation, on the initialization in particular. In any case, you > are to be applauded for tackling the synchronization issues and it would > be a good project to re-examine all of this in JDK 9 to see how it would > be simplified. > > On documenting the locking details in an @implNote (which seems to be > one of the suggestions here) then we also need to be careful as I think > we need some flexibility to change some of this going forward. Yes - that's a two edged sword indeed. We certainly don't want to set that in stone... On the other hand I empathizes with developers who struggle to find out what they can - and can't do - when extending j.u.l APIs... Anyway, if usage of the 'synchronized' keyword never appears in the Javadoc I guess that's for good reasons... Thanks Alan, -- daniel > > -Alan From mark.sheppard at oracle.com Fri Nov 29 16:10:20 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 29 Nov 2013 16:10:20 +0000 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <5298B550.7080300@oracle.com> References: <5298A2ED.2030409@oracle.com> <5298B550.7080300@oracle.com> Message-ID: <5298BC6C.6020608@oracle.com> Hi Daniel, Thanks for the feedback. That's a fair point about the Thread construction. In addressing the issue, I took a minimalist approach and mainly homed in on the Thread.sleep prior to the server send, as the potential culprit. As the intermittent failure is on the client DatagramSocket receive. I think it's worth restructuring the test to avoid how it uses "this" for thread construction. regards Mark On 29/11/2013 15:40, Daniel Fuchs wrote: > Hi Mark, > > Using a CountDownLatch looks like the right thing to do > indeed. > At first I thought that the instance variables would need > to be declared volatile - or synchronized - but since they're > set before the new Thread is created and not changed afterwards > I guess it's OK. > It's a bit strange to pass 'this' to another thread before > 'this' is fully constructed though. Well - it's just a test ;-) > > best regards, > > -- daniel > > On 11/29/13 3:21 PM, Mark Sheppard wrote: >> Hi >> please oblige and review the following changes >> >> http://cr.openjdk.java.net/~msheppar/8025211/webrev/ >> which address the issue raised in the bug >> https://bugs.openjdk.java.net/browse/JDK-8025211 >> >> an intermittent failure occurs on some windows test machines. >> >> this replaces a Thread.sleep(5000) with explicit synchronization between >> sender >> and receiver via a CountDownLatch >> >> regards >> Mark > From Alan.Bateman at oracle.com Fri Nov 29 16:19:21 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Nov 2013 16:19:21 +0000 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <5298A2ED.2030409@oracle.com> References: <5298A2ED.2030409@oracle.com> Message-ID: <5298BE89.5090205@oracle.com> On 29/11/2013 14:21, Mark Sheppard wrote: > Hi > please oblige and review the following changes > > http://cr.openjdk.java.net/~msheppar/8025211/webrev/ > which address the issue raised in the bug > https://bugs.openjdk.java.net/browse/JDK-8025211 > > an intermittent failure occurs on some windows test machines. > > this replaces a Thread.sleep(5000) with explicit synchronization > between sender > and receiver via a CountDownLatch (cc'ing net-dev) Would an alternative here be to just get rid of the server thread (do both the send + receive on the main thread)? -Alan From daniel.fuchs at oracle.com Fri Nov 29 16:41:47 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 Nov 2013 17:41:47 +0100 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <5298BE89.5090205@oracle.com> References: <5298A2ED.2030409@oracle.com> <5298BE89.5090205@oracle.com> Message-ID: <5298C3CB.2060801@oracle.com> On 11/29/13 5:19 PM, Alan Bateman wrote: > On 29/11/2013 14:21, Mark Sheppard wrote: >> Hi >> please oblige and review the following changes >> >> http://cr.openjdk.java.net/~msheppar/8025211/webrev/ >> which address the issue raised in the bug >> https://bugs.openjdk.java.net/browse/JDK-8025211 >> >> an intermittent failure occurs on some windows test machines. >> >> this replaces a Thread.sleep(5000) with explicit synchronization >> between sender >> and receiver via a CountDownLatch > (cc'ing net-dev) > > Would an alternative here be to just get rid of the server thread (do > both the send + receive on the main thread)? Hmm... The message sent by the server is short enough so that it should be stored in the client's socket buffer and received later by the client, even though the client is not yet blocked waiting in clientSock.receive() when the message is sent. That might work. Unless multi-threading was relevant to the configuration being tested? -- daniel > > -Alan From Alan.Bateman at oracle.com Fri Nov 29 17:03:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Nov 2013 17:03:05 +0000 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <528BA6C4.6000702@oracle.com> References: <528BA6C4.6000702@oracle.com> Message-ID: <5298C8C9.5050204@oracle.com> 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 creating new InitialLdapContext() can fail with > "javax.naming.NamingException: LDAP response read timed out, timeout > used:30000ms", even though the specified timeout hadn't been elapsed. > > The fix was provided by the filer of the bug some time ago. > Here's the webrev with this fix: > http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ I haven't seen any replies to this but I've cc'ed Vinnie and Xuelei as they are more familiar with this area. If I understand correctly then the issue is that the timeout handling doesn't take account of wakeups when aren't any BerDecoders to dequeue. The changes mean it will retry the wait with a decreasing timeout until a reply is received or the timeout elapses. That seems reasonable, assuming the time doesn't change :-) You might find the code is a bit clearer if you have a "remaining" time as that would allow you get rid of timedOut, timeOut and endTime. I see the patch doesn't come with a test. Is there any test infrastructure for testing LDAP without require a complete server? -Alan. From mark.sheppard at oracle.com Fri Nov 29 17:17:28 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 29 Nov 2013 17:17:28 +0000 Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java In-Reply-To: <5298C3CB.2060801@oracle.com> References: <5298A2ED.2030409@oracle.com> <5298BE89.5090205@oracle.com> <5298C3CB.2060801@oracle.com> Message-ID: <5298CC28.7090506@oracle.com> Alan, Daniel, thanks for the replies. yes, 'tis a possibility, and it appears to work ok as a test, as it avoids the sender's Thread.sleep creating a race condition, such that the send doesn't happen prior to the timeout of the client receive. The context of the test appears to be creating conditions such that an ICMP PortUnreachable event is generated, which caused a close a particular version of windows. The test is for socket closed scenario, afaik tested on the errant test machine with consistent success. regards Mark On 29/11/2013 16:41, Daniel Fuchs wrote: > On 11/29/13 5:19 PM, Alan Bateman wrote: >> On 29/11/2013 14:21, Mark Sheppard wrote: >>> Hi >>> please oblige and review the following changes >>> >>> http://cr.openjdk.java.net/~msheppar/8025211/webrev/ >>> which address the issue raised in the bug >>> https://bugs.openjdk.java.net/browse/JDK-8025211 >>> >>> an intermittent failure occurs on some windows test machines. >>> >>> this replaces a Thread.sleep(5000) with explicit synchronization >>> between sender >>> and receiver via a CountDownLatch >> (cc'ing net-dev) >> >> Would an alternative here be to just get rid of the server thread (do >> both the send + receive on the main thread)? > > Hmm... The message sent by the server is short enough so that it > should be stored in the client's socket buffer and received later > by the client, even though the client is not yet blocked waiting > in clientSock.receive() when the message is sent. > > That might work. > > Unless multi-threading was relevant to the configuration being > tested? > > > -- daniel > >> >> -Alan > From xueming.shen at oracle.com Fri Nov 29 19:25:39 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 29 Nov 2013 11:25:39 -0800 Subject: Different error decoding Shift-JIS sequence in JDK8 In-Reply-To: References: <528F5A2B.2000402@oracle.com> <529321A2.40905@oracle.com> Message-ID: <5298EA33.4010403@oracle.com> Hi Charles, My apology for the late response. I was on vacation the past week and did not have full email access. As Sean pointed out, this is triggered by the change we just put in recently for 8008386, in which tried to address a strong request that asked for case like 'fe' '40' to be treated as 1 malformed byte + a mappable ascii 40. The reasoning appears to be in case like this, the decoder should assume the first byte "fe" is incorrectly transferred during communication..., treating them as a pair causes valuable information, the next byte, get dropped. And this was a regression of jdk6 (from jdk5). As a matter of fact, the reason we made the change in jdk6 was because of a similar case of your use scenario:-( So it appears we are between a rock and a hard wall... That said, I have to admitted in case of fe 40, it might be more reasonable to treat it as unmappable-2-byte, in stead of a malformed leading byte followed by a mappable ascii. I need to take a little more time to review the whole situation and see if we can have some compromise here. Btw, if would be helpful if you can provide a little more details regarding your use scenario, as you mentioned in your email. "We use this mechanism in JRuby for transcoding arbitrary byte[] from one encoding to another." Thanks! -Sherman On 11/28/13 1:31 AM, Charles Oliver Nutter wrote: > What incantation is required to get Sherman to offer his perspective? :-) > > I accept that it may be after Thanksgiving, but I need to know the > situation since we have tests for JRuby that depended on this > character being valid Shift-JIS. > > - Charlie > > On Mon, Nov 25, 2013 at 4:08 AM, Se?n Coffey wrote: >> Sherman can answer this best. The 8008386 fix for 8 differs from earlier >> updates since alot of the code was rewritten in this area. The initial >> report was identified as a regression in JDK6. Back in 2005, the 6227339 fix >> changed behaviour which meant that invalid single byte characters were >> treated incorrectly when decoding Shift_JIS encoded bytes. It meant that two >> bytes are decoded to a "?" character rather than one. The valid single byte >> characters are lost as a result and I believe this was all unintended when >> the 6227339 fix was made. >> >> Changes made in 8008386 mean that the case of a malformed character (legal >> leading byte) followed by a valid single byte should now return a >> replacement character for the first malformed byte and a correctly decoded >> single byte character. >> >> regards, >> Sean. >> >> >> On 22/11/2013 13:20, Alan Bateman wrote: >>> On 22/11/2013 11:02, Charles Oliver Nutter wrote: >>>> Apologies if this is not the correct place to post this, bit i18n >>>> seemed more focused on languages and localization than the mechanics >>>> of transcoding. >>>> >>>> I have noticed a behavioral difference in JDK8 decoding a two-byte >>>> Shift-JIS sequence. Specifically, JDK8 appears to report malformed >>>> input for what should be a valid Shift-JIS sequence, where JDK7 >>>> reported that the character was unmappable. >>> I assume this is related to JDK-8008386 [1] and I'm sure Sherman or Sean >>> will jump in to explain this (which seems to be related to a long standing >>> regression). >>> >>> -Alan >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8008386 >> >>> Apologies if this is not the correct place to post this, bit i18n >>> seemed more focused on languages and localization than the mechanics >>> of transcoding. >>> >>> I have noticed a behavioral difference in JDK8 decoding a two-byte >>> Shift-JIS sequence. Specifically, JDK8 appears to report malformed >>> input for what should be a valid Shift-JIS sequence, where JDK7 >>> reported that the character was unmappable. >>> >>> The code to reproduce is fairly simple: >>> >>> byte[] bytes = {(byte)0xEF, 0x40}; >>> CharsetDecoder decoder = Charset.forName("Shift-JIS").newDecoder(); >>> System.out.println(decoder.decode(ByteBuffer.wrap(bytes), >>> CharBuffer.allocate(2), false)); >>> >>> Note that this is pumping the decoder directly and specifying partial >>> input (false). We use this mechanism in JRuby for transcoding >>> arbitrary byte[] from one encoding to another. >>> >>> The result of running this on JDK7 is "UNMAPPABLE[2]" while the result >>> on JDK8 is "MALFORMED[1]". >>> >>> Information online is spotty as to whether this sequence is valid. It >>> does appear on the table for [JIS X >>> 203](http://x0213.org/codetable/sjis-0213-2004-std.txt) and several >>> articles on Shift-JIS claim that it is at worst undefined and at best >>> valid. So I'm leaning toward this being a bug in JDK8's Shift-JIS >>> decoder. >>> >>> Note that on JDK7 it is "unmappable", which may mean this code >>> represents a character with no equivalent in Unicode. >>> >>> I have uploaded my code to github here: >>> https://github.com/headius/jdk8_utf8_decoding_bug >>> >>> Thoughts? >>> >>> - Charlie >> >> From ivan.gerasimov at oracle.com Fri Nov 29 20:06:38 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 30 Nov 2013 00:06:38 +0400 Subject: RFR [6968459] JNDI timeout fails before timeout is reached In-Reply-To: <5298C8C9.5050204@oracle.com> References: <528BA6C4.6000702@oracle.com> <5298C8C9.5050204@oracle.com> Message-ID: <5298F3CE.6000003@oracle.com> 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 creating new InitialLdapContext() can fail with >> "javax.naming.NamingException: LDAP response read timed out, timeout >> used:30000ms", even though the specified timeout hadn't been elapsed. >> >> The fix was provided by the filer of the bug some time ago. >> Here's the webrev with this fix: >> http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ > > I haven't seen any replies to this but I've cc'ed Vinnie and Xuelei as > they are more familiar with this area. > > If I understand correctly then the issue is that the timeout handling > doesn't take account of wakeups when aren't any BerDecoders to > dequeue. The changes mean it will retry the wait with a decreasing > timeout until a reply is received or the timeout elapses. That seems > reasonable, assuming the time doesn't change :-) You might find the > code is a bit clearer if you have a "remaining" time as that would > allow you get rid of timedOut, timeOut and endTime. > I modified the patch in the way you suggest. http://cr.openjdk.java.net/~igerasim/6968459/1/webrev/ The timeOut variable now holds the remaining time. If the system time had changed back, we start counting from the beginning. If it had changed forward, we have no way to catch it and the timeout gets elapsed earlier. > I see the patch doesn't come with a test. Is there any test > infrastructure for testing LDAP without require a complete server? > I didn't find anything like that, that's why I set 'noreg-hard' label. Sincerely yours, Ivan > -Alan. > >