From Alan.Bateman at oracle.com Sat Oct 1 01:28:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Oct 2011 02:28:59 +0100 Subject: Test failure on Ubuntu 10.04 java/nio/channels/FileChannel/Transfers.java In-Reply-To: <57208D7E-BA58-43A3-B604-C0A639A68B2E@oracle.com> References: <57208D7E-BA58-43A3-B604-C0A639A68B2E@oracle.com> Message-ID: <4E866CDB.5080705@oracle.com> Kelly O'Hair wrote: > Has anyone seen this testcase fail like this? > > FAILED: java/nio/channels/FileChannel/Transfers.java > > ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Some tests failed > REASON: Assumed action based on file name: run main Transfers > TIME: 3.337 seconds > messages: > command: main Transfers > reason: Assumed action based on file name: run main Transfers > elapsed time (seconds): 3.337 > STDOUT: > From file channel: 0 1 2 3 4 5 6 7 8 9 15 16 17 31 32 33 63 64 65 127 128 129 255 256 257 511 512 513 1023 1024 1025 2047 2048 2049 4095 4096 4097 8191 8192 8193 16383 16384 16385 32767 > From user channel: 0 1 2 3 4 5 6 7 8 9 15 16 17 31 32 33 63 64 65 127 128 129 255 256 257 511 512 513 1023 1024 1025 2047 2048 2049 4095 4096 4097 8191 8192 8193 16383 16384 16385 32767 > To file channel: 0 > FAILURE: FileChannel, offset 0, length 1 > Transfers$Failure: Wrong position: 0 (expected 1) > at Transfers$FileTarget.verify(Transfers.java:316) > at Transfers.testTo(Transfers.java:449) > at Transfers.main(Transfers.java:527) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) > at java.lang.Thread.run(Thread.java:722) > .... > goes on forever ... :^( > > -kto 10.04 = 2.6.32 which I think is the kernel version where sendfile was updated to use splice and support sending to file descriptors connected to a file. If I recall correctly it didn't update the file position causing the above failure. Updating the kernel will likely fix this issue and I've verified that it doesn't happen with 10.10 (2.6.35) and 11.04 (2.6.38). -Alan. From kelly.ohair at oracle.com Sat Oct 1 01:54:42 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 30 Sep 2011 18:54:42 -0700 Subject: Test failure on Ubuntu 10.04 java/nio/channels/FileChannel/Transfers.java In-Reply-To: <4E866CDB.5080705@oracle.com> References: <57208D7E-BA58-43A3-B604-C0A639A68B2E@oracle.com> <4E866CDB.5080705@oracle.com> Message-ID: <85888D8B-D072-4FD5-9206-632A13334994@oracle.com> On Sep 30, 2011, at 6:28 PM, Alan Bateman wrote: > Kelly O'Hair wrote: >> Has anyone seen this testcase fail like this? >> >> FAILED: java/nio/channels/FileChannel/Transfers.java >> >> ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Some tests failed >> REASON: Assumed action based on file name: run main Transfers >> TIME: 3.337 seconds >> messages: >> command: main Transfers >> reason: Assumed action based on file name: run main Transfers >> elapsed time (seconds): 3.337 >> STDOUT: >> From file channel: 0 1 2 3 4 5 6 7 8 9 15 16 17 31 32 33 63 64 65 127 128 129 255 256 257 511 512 513 1023 1024 1025 2047 2048 2049 4095 4096 4097 8191 8192 8193 16383 16384 16385 32767 >> From user channel: 0 1 2 3 4 5 6 7 8 9 15 16 17 31 32 33 63 64 65 127 128 129 255 256 257 511 512 513 1023 1024 1025 2047 2048 2049 4095 4096 4097 8191 8192 8193 16383 16384 16385 32767 >> To file channel: 0 >> FAILURE: FileChannel, offset 0, length 1 >> Transfers$Failure: Wrong position: 0 (expected 1) >> at Transfers$FileTarget.verify(Transfers.java:316) >> at Transfers.testTo(Transfers.java:449) >> at Transfers.main(Transfers.java:527) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:474) >> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) >> at java.lang.Thread.run(Thread.java:722) >> .... >> goes on forever ... :^( >> >> -kto > 10.04 = 2.6.32 which I think is the kernel version where sendfile was updated to use splice and support sending to file descriptors connected to a file. If I recall correctly it didn't update the file position causing the above failure. Updating the kernel will likely fix this issue and I've verified that it doesn't happen with 10.10 (2.6.35) and 11.04 (2.6.38). > > -Alan. FYI.. On my Ubuntu 10.04 system it had 2.6.32-33, and after a 'aptitude full-upgrade' and reboot I had 2.6.32-34 and the problem seems to have gone away. -kto From sebastian.sickelmann at gmx.de Sat Oct 1 06:25:22 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 01 Oct 2011 08:25:22 +0200 Subject: JDK 8 Code Review Request for 5029031 (coll) Collections.checkedQueue(Queue, Class) is missing In-Reply-To: <4E862481.6050800@oracle.com> References: <4E862481.6050800@oracle.com> Message-ID: <4E86B252.9030706@gmx.de> Am 30.09.2011 22:20, schrieb Darryl Mocek: > Hello. > > Please review this patch to add CheckedQueue to Collections. Test > case provided. > > Webrev at: http://cr.openjdk.java.net/~mduigou/4533691/0/webrev/ > > Thanks, > Darryl Looks good to me. Just the @since 1.7 seems wrong for an JDK8 Patch. Should there be a backport to jdk7 of this? Here are some additional ideas: Should we use diamonds in testcases too? L71,85,108,125,157 What's about moving public boolean equals(Object o) {return o == this || c.equals(o);} to CheckedCollection and remove it in CheckedSet (L2394), CheckedList (L2506) and public int hashCode() {return c.hashCode();} to CheckedCollection and remove it in CheckedSet (L2395) This additional change doesn't look to big for me. But unfortunatly i can't read the bugdetails of 5029031. Should we do more deduplication in Collections like the above, in another CR? Then i would send a Code Review Request for this. Is there someone who would sponsor it? -- Sebastian From sean.mullan at oracle.com Sat Oct 1 16:19:44 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Sat, 01 Oct 2011 12:19:44 -0400 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E86073D.9050101@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> Message-ID: <4E873DA0.5050906@oracle.com> On 9/30/11 2:15 PM, Sebastian Sickelmann wrote: >>> I think I know the reason. If you allow initCause to be called when a >>> cause is >>> not initially provided, then getCause will still return null, which >>> seems wrong. >>> >> getCause() of Throwable and all classes that doesn't had a chaining >> before >> Throwable introduces it, doing this excact this way. Whats wrong on this? >> >> return (cause==this ? null : cause); // Where the initial >> value(uninitialied) of cause is this. > Does this make sense? I actually not sure i understand you right. The following code: KeySelectorException kse = new KeySelectorException("foo"); kse.initCause(new Exception("bar")); System.out.println(kse.getCause()); prints null as the cause, even though initCause was subsequently called. Do you see my concern? > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html Thanks! --Sean From Ulf.Zibis at gmx.de Sat Oct 1 21:21:33 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 01 Oct 2011 23:21:33 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E862AB2.7090605@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> Message-ID: <4E87845D.2090908@gmx.de> Am 30.09.2011 22:46, schrieb Xueming Shen: > On 09/30/2011 07:09 AM, Ulf Zibis wrote: >>> >>> (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> CoderResult.malformedForLength(1) >>> It appears the Unicode Standard now explicitly recommends to return the malformed length 2, >>> what UTF-8 is doing now, for this scenario >> My idea behind was, that in case of malformed length 1 a consecutive call to the decode loop >> would again return another malformed length 1, to ensure 2 replacement chars in the output >> string. (Not sure, if that is expected in this corner case.) > > Unicode Standard's "best practices" D93a/b recommends to return 2 in this case. Can you please give me a link for D93a/a. I don't know, where to find it. > > >> 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong results >> >> >> >>> I'm not sure I understand the suggested b1 < -0x3e patch, I don't see we can simply replace >>> ((b1 >> 5) == -2) with (b1 < -0x3e). >> You must see the b1 < -0x3e in combination with the following b1 < -0x20. ;-) >> >> But now I have a better "if...else if" switch. :-) >> - saves the shift operations >> - only 1 comparison per case >> - only 1 constant to load per case >> - helps compiler to benefit from 1 byte constants and op-codes >> - much better readable > > I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because > the benchmark shows the "shift" version is slightly faster. IIRC this was only about a shift by multiples of 8 to ensure an 1-byte comparison of 16/32-byte values in the double/quad-byte charsets. > Do you have any number > shows any difference now. My non-scientific benchmark still suggests the "shift" > type is faster on -server vm, no significant difference on -client vm. > > ------------------ your new switch--------------- > (1) -server > Method Millis Ratio > Decoding 1b UTF-8 : 125 1.000 > Decoding 2b UTF-8 : 2558 20.443 > Decoding 3b UTF-8 : 3439 27.481 > Decoding 4b UTF-8 : 2030 16.221 > (2) -client > Decoding 1b UTF-8 : 335 1.000 > Decoding 2b UTF-8 : 1041 3.105 > Decoding 3b UTF-8 : 2245 6.694 > Decoding 4b UTF-8 : 1254 3.741 > > ------------------ existing "shift"--------------- > (1) -server > Decoding 1b UTF-8 : 134 1.000 > Decoding 2b UTF-8 : 1891 14.106 > Decoding 3b UTF-8 : 2934 21.886 > Decoding 4b UTF-8 : 2133 15.913 > (2) -client > Decoding 1b UTF-8 : 341 1.000 > Decoding 2b UTF-8 : 949 2.560 > Decoding 3b UTF-8 : 2321 6.255 > Decoding 4b UTF-8 : 1278 3.446 > Very interesting and surprising numbers! The most surprising is, that the client compiler generates faster code for 2..4-byte codes. I think, we should ask the HotSpot team for help. As the UTF-8 de/encoding is a very frequent task, HotSpot should provide compiled code as optimized best as possible for UTF-8 de/encoding. Another surprise is, that benchmark for 1b UTF-8 is not same for "new switch" and "shift" version, as the ASCII only loop is the same in both versions. To discover the miracle, why the"shift" version is little faster than the "new switch" version, it should be helpful, to see the disassembling of the HotSpot compiled code. A third version, using the "(b1 & 0xe0) == 0xc0"/"(b1 & 0xf0) == 0xe0"/"(b1 & 0xf8) == 0xf0" pattern, should be interesting toofor the benchmark comparison. In my opinion it would be more significant to compare x 1..4-byte codes than y bytes of 1..4-byte codes. I.e. 1000 bytes of 1-byte codes against 2000 bytes of 2-byte codes against 3000 bytes of 3-byte codes against 4000 bytes of 4-byte codes We should document somewhere, that the ESU-8 decoder is faster than the strong UTF-8 decoder for developers, who can ensure, that there are no invalid surrogates in their source bytes. -Ulf From xueming.shen at oracle.com Sun Oct 2 06:29:11 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 01 Oct 2011 23:29:11 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E87845D.2090908@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E87845D.2090908@gmx.de> Message-ID: <4E8804B7.2060600@oracle.com> http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf Go to 3.9 Unicode Encoding Forms. Or simply search D93 On 10/1/2011 2:21 PM, Ulf Zibis wrote: > Am 30.09.2011 22:46, schrieb Xueming Shen: >> On 09/30/2011 07:09 AM, Ulf Zibis wrote: >>>> >>>> (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> >>>> CoderResult.malformedForLength(1) >>>> It appears the Unicode Standard now explicitly recommends to return >>>> the malformed length 2, >>>> what UTF-8 is doing now, for this scenario >>> My idea behind was, that in case of malformed length 1 a consecutive >>> call to the decode loop would again return another malformed length >>> 1, to ensure 2 replacement chars in the output string. (Not sure, if >>> that is expected in this corner case.) >> >> Unicode Standard's "best practices" D93a/b recommends to return 2 in >> this case. > Can you please give me a link for D93a/a. I don't know, where to find it. > > >> >> >>> 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong >>> results >>> >>> >>>> I'm not sure I understand the suggested b1 < -0x3e patch, I don't >>>> see we can simply replace >>>> ((b1 >> 5) == -2) with (b1 < -0x3e). >>> You must see the b1 < -0x3e in combination with the following b1 < >>> -0x20. ;-) >>> >>> But now I have a better "if...else if" switch. :-) >>> - saves the shift operations >>> - only 1 comparison per case >>> - only 1 constant to load per case >>> - helps compiler to benefit from 1 byte constants and op-codes >>> - much better readable >> >> I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to >> 2009(?) because >> the benchmark shows the "shift" version is slightly faster. > IIRC this was only about a shift by multiples of 8 to ensure an 1-byte > comparison of 16/32-byte values in the double/quad-byte charsets. > > >> Do you have any number >> shows any difference now. My non-scientific benchmark still suggests >> the "shift" >> type is faster on -server vm, no significant difference on -client vm. >> >> ------------------ your new switch--------------- >> (1) -server >> Method Millis Ratio >> Decoding 1b UTF-8 : 125 1.000 >> Decoding 2b UTF-8 : 2558 20.443 >> Decoding 3b UTF-8 : 3439 27.481 >> Decoding 4b UTF-8 : 2030 16.221 >> (2) -client >> Decoding 1b UTF-8 : 335 1.000 >> Decoding 2b UTF-8 : 1041 3.105 >> Decoding 3b UTF-8 : 2245 6.694 >> Decoding 4b UTF-8 : 1254 3.741 >> >> ------------------ existing "shift"--------------- >> (1) -server >> Decoding 1b UTF-8 : 134 1.000 >> Decoding 2b UTF-8 : 1891 14.106 >> Decoding 3b UTF-8 : 2934 21.886 >> Decoding 4b UTF-8 : 2133 15.913 >> (2) -client >> Decoding 1b UTF-8 : 341 1.000 >> Decoding 2b UTF-8 : 949 2.560 >> Decoding 3b UTF-8 : 2321 6.255 >> Decoding 4b UTF-8 : 1278 3.446 >> > Very interesting and surprising numbers! > The most surprising is, that the client compiler generates faster code > for 2..4-byte codes. I think, we should ask the HotSpot team for help. > As the UTF-8 de/encoding is a very frequent task, HotSpot should > provide compiled code as optimized best as possible for UTF-8 de/encoding. > Another surprise is, that benchmark for 1b UTF-8 is not same for "new > switch" and "shift" version, as the ASCII only loop is the same in > both versions. > To discover the miracle, why the"shift" version is little faster than > the "new switch" version, it should be helpful, to see the > disassembling of the HotSpot compiled code. > A third version, using the "(b1 & 0xe0) == 0xc0"/"(b1 & 0xf0) == > 0xe0"/"(b1 & 0xf8) == 0xf0" pattern, should be interesting toofor the > benchmark comparison. > > In my opinion it would be more significant to compare x 1..4-byte > codes than y bytes of 1..4-byte codes. I.e. 1000 bytes of 1-byte codes > against 2000 bytes of 2-byte codes against 3000 bytes of 3-byte codes > against 4000 bytes of 4-byte codes > > We should document somewhere, that the ESU-8 decoder is faster than > the strong UTF-8 decoder for developers, who can ensure, that there > are no invalid surrogates in their source bytes. > > -Ulf > From Ulf.Zibis at gmx.de Sun Oct 2 09:52:35 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 02 Oct 2011 11:52:35 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E8804B7.2060600@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E87845D.2090908@gmx.de> <4E8804B7.2060600@oracle.com> Message-ID: <4E883463.1090508@gmx.de> Am 02.10.2011 08:29, schrieb Xueming Shen: > http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf > > Go to 3.9 Unicode Encoding Forms. Or simply search D93 > > On 10/1/2011 2:21 PM, Ulf Zibis wrote: >> Am 30.09.2011 22:46, schrieb Xueming Shen: >>> On 09/30/2011 07:09 AM, Ulf Zibis wrote: >>>>> >>>>> (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> CoderResult.malformedForLength(1) >>>>> It appears the Unicode Standard now explicitly recommends to return the malformed length 2, >>>>> what UTF-8 is doing now, for this scenario >>>> My idea behind was, that in case of malformed length 1 a consecutive call to the decode loop >>>> would again return another malformed length 1, to ensure 2 replacement chars in the output >>>> string. (Not sure, if that is expected in this corner case.) >>> >>> Unicode Standard's "best practices" D93a/b recommends to return 2 in this case. OK, I got it: E1 80 42 --> malformed length 2 --> 1 replacement --> FFFD 0042 Because for later understanding by others it could be difficult to find the right documents, it would be *very nice* to add this link to the souce code of UTF_8.java, by javadoc, or by simple doc. -Ulf From sebastian.sickelmann at gmx.de Sun Oct 2 19:49:14 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sun, 02 Oct 2011 21:49:14 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E873DA0.5050906@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> Message-ID: <4E88C03A.90904@gmx.de> Am 01.10.2011 18:19, schrieb Sean Mullan: > On 9/30/11 2:15 PM, Sebastian Sickelmann wrote: >>>> I think I know the reason. If you allow initCause to be called when a >>>> cause is >>>> not initially provided, then getCause will still return null, which >>>> seems wrong. >>>> >>> getCause() of Throwable and all classes that doesn't had a chaining >>> before >>> Throwable introduces it, doing this excact this way. Whats wrong on this? >>> >>> return (cause==this ? null : cause); // Where the initial >>> value(uninitialied) of cause is this. >> Does this make sense? I actually not sure i understand you right. > The following code: > > KeySelectorException kse = new KeySelectorException("foo"); > kse.initCause(new Exception("bar")); > System.out.println(kse.getCause()); > > prints null as the cause, even though initCause was subsequently called. Do you > see my concern? This is one of the places in code which must be changes to match the initCause behavoir of Throwable. I have done it here: http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html But is this the best way? Or should we just follow the other Exceptions and start an seperate discussion on this with core-libs-dev? >> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html > Thanks! > --Sean > From Ulf.Zibis at gmx.de Sun Oct 2 21:36:36 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 02 Oct 2011 23:36:36 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E84F0E2.6010503@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E84E025.3010105@gmx.de> <4E84F0E2.6010503@oracle.com> Message-ID: <4E88D964.1040603@gmx.de> Hi again, Am 30.09.2011 00:27, schrieb Xueming Shen: > On 09/29/2011 02:16 PM, Ulf Zibis wrote: >> >> 280 if (Character.isSurrogate(c)) >> 281 return malformedForLength(src, sp, dst, dp, 3); >> Shouldn't we return cr.length() = 1to allow remaining 2 bytes to be interpreted again ? >> Forget it! If c is a surrogate, b2 is in range A0..BF and b3 is in range 80..BF. Both can not be potentially well-formed as a first byte. > Actually I don't know the answer. My reading of D93a/D93b suggests that we might > interpret it as a whole, given the bytes are actually in well-formed byte pattern range > listed in Table 3.7, but "ill-formed" simply because they are surrogate value not scale > value, so I would interpret the whole 3 bytes as a maximal subpart. Given D93a/b is > "best practices for Using U+fffd", either way should be fine. We do have Unicode expert > on the list, so maybe they can share their opinion on what is the "desired"/recommended > behavior in this case, from Standard point view? At line 102 you could insert: // [E0] [A0..BF] // [E1..EF] [80..BF] -Ulf From kelly.ohair at oracle.com Mon Oct 3 01:10:19 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sun, 2 Oct 2011 18:10:19 -0700 Subject: testcase failure Message-ID: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> Anyone seen this testcase failure before? -kto -------------------------------------------------- TEST: java/util/Locale/Bug6989440.java JDK under test: (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-201110030014.jprtadm.jdk-b00) Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) ACTION: compile -- Passed. Compilation successful REASON: User specified action: run compile -XDignore.symbol.file=true Bug6989440.java TIME: 0.053 seconds messages: command: compile -XDignore.symbol.file=true /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java reason: User specified action: run compile -XDignore.symbol.file=true Bug6989440.java elapsed time (seconds): 0.053 ACTION: build -- Passed. All files up to date REASON: Named class compiled on demand TIME: 0.0 seconds messages: command: build Bug6989440 reason: Named class compiled on demand elapsed time (seconds): 0.0 ACTION: main -- Error. Error while cleaning up threads after test REASON: User specified action: run main Bug6989440 TIME: 120.01 seconds messages: command: main Bug6989440 reason: User specified action: run main Bug6989440 elapsed time (seconds): 120.01 STDOUT: STDERR: JavaTest Message: Test complete. TEST RESULT: Error. Error while cleaning up threads after test -------------------------------------------------- From kelly.ohair at oracle.com Mon Oct 3 01:26:38 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sun, 2 Oct 2011 18:26:38 -0700 Subject: another testcase failure Message-ID: <5D3C5333-EC32-4728-9F66-A20C7CC9F62C@oracle.com> This one failed on Solaris 10u6 sparc, look familiar to anyone? -kto -------------------------------------------------- TEST: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java JDK under test: (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_sparc_5.10-product) openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-201110030014.jprtadm.jdk-b00) Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode) ACTION: build -- Passed. Build successful REASON: User specified action: run build LoggingMXBeanTest TIME: 0.068 seconds messages: command: build LoggingMXBeanTest reason: User specified action: run build LoggingMXBeanTest elapsed time (seconds): 0.068 ACTION: compile -- Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 0.067 seconds messages: command: compile /tmp/jprt/P1/001456.jprtadm/source/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java reason: .class file out of date or does not exist elapsed time (seconds): 0.067 ACTION: build -- Passed. All files up to date REASON: Named class compiled on demand TIME: 0.0 seconds messages: command: build LoggingMXBeanTest reason: Named class compiled on demand elapsed time (seconds): 0.0 ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.NullPointerException REASON: User specified action: run main LoggingMXBeanTest TIME: 0.04 seconds messages: command: main LoggingMXBeanTest reason: User specified action: run main LoggingMXBeanTest elapsed time (seconds): 0.04 STDOUT: Test Logger Name retrieval (getLoggerNames) : Found new Logger : com.sun.management.Logger.Logger2 : Found new Logger : com.sun.management.Logger : PASSED. Test getLoggerLevel : Level for Logger com.sun.management.Logger : FINE : Level for Logger com.sun.management.Logger.Logger2 : : Level for unknown logger : null Test setLoggerLevel : Set Level for Logger com.sun.management.Logger to: INFO : Set Level for Logger com.sun.management.Logger.Logger2 to: SERVER : Set Level for Logger com.sun.management.Logger to: null : Set Level for unknown Logger to: FINE : IllegalArgumentException caught as expected : Set Level for Logger com.sun.management.Logger to: DUMMY : IllegalArgumentException caught as expected Test getParentLoggerName : Parent Logger for com.sun.management.Logger.Logger2 : com.sun.management.Logger : Parent Logger for "" : : Parent Logger for unknown logger : null STDERR: java.lang.NullPointerException at LoggingMXBeanTest.checkAttributes(LoggingMXBeanTest.java:220) at LoggingMXBeanTest.main(LoggingMXBeanTest.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) at java.lang.Thread.run(Thread.java:722) JavaTest Message: Test threw exception: java.lang.NullPointerException JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException -------------------------------------------------- From Alan.Bateman at oracle.com Mon Oct 3 02:33:11 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Oct 2011 03:33:11 +0100 Subject: another testcase failure In-Reply-To: <5D3C5333-EC32-4728-9F66-A20C7CC9F62C@oracle.com> References: <5D3C5333-EC32-4728-9F66-A20C7CC9F62C@oracle.com> Message-ID: <4E891EE7.20300@oracle.com> Kelly O'Hair wrote: > This one failed on Solaris 10u6 sparc, look familiar to anyone? > > > STDERR: > java.lang.NullPointerException > at LoggingMXBeanTest.checkAttributes(LoggingMXBeanTest.java:220) > at LoggingMXBeanTest.main(LoggingMXBeanTest.java:61) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) > at java.lang.Thread.run(Thread.java:722) > > JavaTest Message: Test threw exception: java.lang.NullPointerException > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException > -------------------------------------------------- > > I saw this once too and found there is a bug open on it (7067691). I think the issue is that the Loggers are being GC'ed with the result that getLogger returns null causing the failure you observed. It's not Solaris specific but rather it's just that the loggers were GC'ed at the wrong time. It's possible that some of the other logging tests need to be fixed for the same issue. -Alan. From Alan.Bateman at oracle.com Mon Oct 3 02:39:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Oct 2011 03:39:39 +0100 Subject: testcase failure In-Reply-To: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> Message-ID: <4E89206B.1040603@oracle.com> I haven't seen it but Olivier Lagneau asked me off-list recently about the same issue (same test, same failure mode). I've cc'ed the i18n folks in case they recognize it. My guess is that this is an implementation bug in LocaleServiceProviderPool rather than a test bug. -Alan. Kelly O'Hair wrote: > Anyone seen this testcase failure before? > > -kto > > -------------------------------------------------- > TEST: java/util/Locale/Bug6989440.java > JDK under test: (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-201110030014.jprtadm.jdk-b00) > Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) > > ACTION: compile -- Passed. Compilation successful > REASON: User specified action: run compile -XDignore.symbol.file=true Bug6989440.java > TIME: 0.053 seconds > messages: > command: compile -XDignore.symbol.file=true /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java > reason: User specified action: run compile -XDignore.symbol.file=true Bug6989440.java > elapsed time (seconds): 0.053 > > ACTION: build -- Passed. All files up to date > REASON: Named class compiled on demand > TIME: 0.0 seconds > messages: > command: build Bug6989440 > reason: Named class compiled on demand > elapsed time (seconds): 0.0 > > ACTION: main -- Error. Error while cleaning up threads after test > REASON: User specified action: run main Bug6989440 > TIME: 120.01 seconds > messages: > command: main Bug6989440 > reason: User specified action: run main Bug6989440 > elapsed time (seconds): 120.01 > STDOUT: > STDERR: > > JavaTest Message: Test complete. > > > TEST RESULT: Error. Error while cleaning up threads after test > -------------------------------------------------- > > From jason_mehrens at hotmail.com Mon Oct 3 15:35:51 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 3 Oct 2011 10:35:51 -0500 Subject: JDK 8 Code Review Request for 5029031 (coll) Collections.checkedQueue(Queue, Class) is missing In-Reply-To: <4E86B252.9030706@gmx.de> References: <4E862481.6050800@oracle.com>,<4E86B252.9030706@gmx.de> Message-ID: > What's about moving > > public boolean equals(Object o) {return o == this || c.equals(o);} > > to CheckedCollection and remove it in CheckedSet (L2394), CheckedList (L2506) > > and > > public int hashCode() {return c.hashCode();} > > to CheckedCollection and remove it in CheckedSet (L2395) That violates the spec of checkedCollection. Jason From naoto.sato at oracle.com Mon Oct 3 17:53:49 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 03 Oct 2011 10:53:49 -0700 Subject: testcase failure In-Reply-To: <4E89206B.1040603@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> Message-ID: <4E89F6AD.1060401@oracle.com> Discussed in the CR 7027061. Never been able to reproduce outside the JPRT system, and it's difficult to investigate such issue without reproducing it. Naoto On 10/2/11 7:39 PM, Alan Bateman wrote: > > I haven't seen it but Olivier Lagneau asked me off-list recently about > the same issue (same test, same failure mode). I've cc'ed the i18n folks > in case they recognize it. My guess is that this is an implementation > bug in LocaleServiceProviderPool rather than a test bug. > > -Alan. > > Kelly O'Hair wrote: >> Anyone seen this testcase failure before? >> >> -kto >> >> -------------------------------------------------- >> TEST: java/util/Locale/Bug6989440.java >> JDK under test: >> (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) >> openjdk version "1.8.0-internal" >> OpenJDK Runtime Environment (build >> 1.8.0-internal-201110030014.jprtadm.jdk-b00) >> Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) >> >> ACTION: compile -- Passed. Compilation successful >> REASON: User specified action: run compile -XDignore.symbol.file=true >> Bug6989440.java TIME: 0.053 seconds >> messages: >> command: compile -XDignore.symbol.file=true >> /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java >> reason: User specified action: run compile -XDignore.symbol.file=true >> Bug6989440.java elapsed time (seconds): 0.053 >> >> ACTION: build -- Passed. All files up to date >> REASON: Named class compiled on demand >> TIME: 0.0 seconds >> messages: >> command: build Bug6989440 >> reason: Named class compiled on demand >> elapsed time (seconds): 0.0 >> >> ACTION: main -- Error. Error while cleaning up threads after test >> REASON: User specified action: run main Bug6989440 TIME: 120.01 seconds >> messages: >> command: main Bug6989440 >> reason: User specified action: run main Bug6989440 elapsed time >> (seconds): 120.01 >> STDOUT: >> STDERR: >> >> JavaTest Message: Test complete. >> >> >> TEST RESULT: Error. Error while cleaning up threads after test >> -------------------------------------------------- >> > From edharned at gmail.com Mon Oct 3 18:25:18 2011 From: edharned at gmail.com (Edward Harned) Date: Mon, 3 Oct 2011 14:25:18 -0400 Subject: JEP 103: Parallel Array Sorting Message-ID: Re: In opposition to JEP 103 I oppose the JEP 103 proposal for four major reasons as stated in this PDF: http://coopsoft.com/dl/Oppose103.pdf If preferred I can post the text here. Ed From sebastian.sickelmann at gmx.de Mon Oct 3 19:39:41 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 03 Oct 2011 21:39:41 +0200 Subject: JDK 8 Code Review Request for 5029031 (coll) Collections.checkedQueue(Queue, Class) is missing In-Reply-To: References: <4E862481.6050800@oracle.com>, <4E86B252.9030706@gmx.de> Message-ID: <4E8A0F7D.1020102@gmx.de> Am 03.10.2011 17:35, schrieb Jason Mehrens: > > > What's about moving > > > > public boolean equals(Object o) {return o == this || c.equals(o);} > > > > to CheckedCollection and remove it in CheckedSet (L2394), > CheckedList (L2506) > > > > and > > > > public int hashCode() {return c.hashCode();} > > > > to CheckedCollection and remove it in CheckedSet (L2395) > > That violates the spec of checkedCollection. > > Jason > Sorry missed this. This was an jdk7 javadoc patch. in jdk6 the javadoc hasn't said anything about this. I thought about it, but there is not good solution to pass through the calls of hashCode and equals to the underlying Collection (List / Set / other custom Collection) without breaking symmetric while having the Set and List implementations (both check if the other object is also a Set or List. And all my other deduplication candidates i have seen are in the same category. -- Sebastian From david.holmes at oracle.com Mon Oct 3 21:25:29 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Oct 2011 07:25:29 +1000 Subject: testcase failure In-Reply-To: <4E89F6AD.1060401@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> Message-ID: <4E8A2849.60709@oracle.com> On 4/10/2011 3:53 AM, Naoto Sato wrote: > Discussed in the CR 7027061. Never been able to reproduce outside the > JPRT system, and it's difficult to investigate such issue without > reproducing it. This error message is coming from jtreg: ACTION: main -- Error. Error while cleaning up threads after test REASON: User specified action: run main Bug6989440 so it needs to be investigated by jtreg folk. I suspect however that it may be related to trying to interrupt the threads due to a timeout. David ----- > Naoto > > On 10/2/11 7:39 PM, Alan Bateman wrote: >> >> I haven't seen it but Olivier Lagneau asked me off-list recently about >> the same issue (same test, same failure mode). I've cc'ed the i18n folks >> in case they recognize it. My guess is that this is an implementation >> bug in LocaleServiceProviderPool rather than a test bug. >> >> -Alan. >> >> Kelly O'Hair wrote: >>> Anyone seen this testcase failure before? >>> >>> -kto >>> >>> -------------------------------------------------- >>> TEST: java/util/Locale/Bug6989440.java >>> JDK under test: >>> (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) >>> openjdk version "1.8.0-internal" >>> OpenJDK Runtime Environment (build >>> 1.8.0-internal-201110030014.jprtadm.jdk-b00) >>> Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) >>> >>> ACTION: compile -- Passed. Compilation successful >>> REASON: User specified action: run compile -XDignore.symbol.file=true >>> Bug6989440.java TIME: 0.053 seconds >>> messages: >>> command: compile -XDignore.symbol.file=true >>> /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java >>> reason: User specified action: run compile -XDignore.symbol.file=true >>> Bug6989440.java elapsed time (seconds): 0.053 >>> >>> ACTION: build -- Passed. All files up to date >>> REASON: Named class compiled on demand >>> TIME: 0.0 seconds >>> messages: >>> command: build Bug6989440 >>> reason: Named class compiled on demand >>> elapsed time (seconds): 0.0 >>> >>> ACTION: main -- Error. Error while cleaning up threads after test >>> REASON: User specified action: run main Bug6989440 TIME: 120.01 seconds >>> messages: >>> command: main Bug6989440 >>> reason: User specified action: run main Bug6989440 elapsed time >>> (seconds): 120.01 >>> STDOUT: >>> STDERR: >>> >>> JavaTest Message: Test complete. >>> >>> >>> TEST RESULT: Error. Error while cleaning up threads after test >>> -------------------------------------------------- >>> >> > From kelly.ohair at oracle.com Mon Oct 3 21:44:59 2011 From: kelly.ohair at oracle.com (Kelly Ohair) Date: Mon, 3 Oct 2011 14:44:59 -0700 Subject: testcase failure In-Reply-To: <4E8A2849.60709@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> Message-ID: i have seen a similar bug in my own jprt code where i was accidently working with HashSet or HashMap objects in two different threads very strange things like this happened i dont have the testcase handy to look at but i highly suspect the testcase this last failure had nothing to with JPRT, just make&make test the test/Makefile might run jtreg a little differently but the testcase should not fail also it is critical that the test be run on a machine with more than one processor, it just will not reproduce on a machine without multiple processors Sent from my iPhone On Oct 3, 2011, at 14:25, David Holmes wrote: > On 4/10/2011 3:53 AM, Naoto Sato wrote: >> Discussed in the CR 7027061. Never been able to reproduce outside the >> JPRT system, and it's difficult to investigate such issue without >> reproducing it. > > This error message is coming from jtreg: > > ACTION: main -- Error. Error while cleaning up threads after test > REASON: User specified action: run main Bug6989440 > > so it needs to be investigated by jtreg folk. I suspect however that it may be related to trying to interrupt the threads due to a timeout. > > David > ----- > >> Naoto >> >> On 10/2/11 7:39 PM, Alan Bateman wrote: >>> >>> I haven't seen it but Olivier Lagneau asked me off-list recently about >>> the same issue (same test, same failure mode). I've cc'ed the i18n folks >>> in case they recognize it. My guess is that this is an implementation >>> bug in LocaleServiceProviderPool rather than a test bug. >>> >>> -Alan. >>> >>> Kelly O'Hair wrote: >>>> Anyone seen this testcase failure before? >>>> >>>> -kto >>>> >>>> -------------------------------------------------- >>>> TEST: java/util/Locale/Bug6989440.java >>>> JDK under test: >>>> (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) >>>> openjdk version "1.8.0-internal" >>>> OpenJDK Runtime Environment (build >>>> 1.8.0-internal-201110030014.jprtadm.jdk-b00) >>>> Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) >>>> >>>> ACTION: compile -- Passed. Compilation successful >>>> REASON: User specified action: run compile -XDignore.symbol.file=true >>>> Bug6989440.java TIME: 0.053 seconds >>>> messages: >>>> command: compile -XDignore.symbol.file=true >>>> /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java >>>> reason: User specified action: run compile -XDignore.symbol.file=true >>>> Bug6989440.java elapsed time (seconds): 0.053 >>>> >>>> ACTION: build -- Passed. All files up to date >>>> REASON: Named class compiled on demand >>>> TIME: 0.0 seconds >>>> messages: >>>> command: build Bug6989440 >>>> reason: Named class compiled on demand >>>> elapsed time (seconds): 0.0 >>>> >>>> ACTION: main -- Error. Error while cleaning up threads after test >>>> REASON: User specified action: run main Bug6989440 TIME: 120.01 seconds >>>> messages: >>>> command: main Bug6989440 >>>> reason: User specified action: run main Bug6989440 elapsed time >>>> (seconds): 120.01 >>>> STDOUT: >>>> STDERR: >>>> >>>> JavaTest Message: Test complete. >>>> >>>> >>>> TEST RESULT: Error. Error while cleaning up threads after test >>>> -------------------------------------------------- >>>> >>> >> From david.holmes at oracle.com Tue Oct 4 05:20:16 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Oct 2011 15:20:16 +1000 Subject: testcase failure In-Reply-To: References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> Message-ID: <4E8A9790.10303@oracle.com> Kelly, The test is trivial - three threads try to get the locale data. Before the fix you'd have multiple threads stomping on each other - after the fix they should now be synchronized in terms of the primary initialization. But I'd have to check the actual locale code as that is where the synchronization needs to be. But again the other error comes from jtreg not from the testcase. David On 4/10/2011 7:44 AM, Kelly Ohair wrote: > i have seen a similar bug in my own jprt code where i was accidently working with HashSet or HashMap objects in two different threads very strange things like this happened > > i dont have the testcase handy to look at but i highly suspect the testcase > > this last failure had nothing to with JPRT, just make&make test > > the test/Makefile might run jtreg a little differently but the testcase should not fail > > also it is critical that the test be run on a machine with more than one processor, it just will not reproduce on a machine without multiple processors > > > Sent from my iPhone > > On Oct 3, 2011, at 14:25, David Holmes wrote: > >> On 4/10/2011 3:53 AM, Naoto Sato wrote: >>> Discussed in the CR 7027061. Never been able to reproduce outside the >>> JPRT system, and it's difficult to investigate such issue without >>> reproducing it. >> >> This error message is coming from jtreg: >> >> ACTION: main -- Error. Error while cleaning up threads after test >> REASON: User specified action: run main Bug6989440 >> >> so it needs to be investigated by jtreg folk. I suspect however that it may be related to trying to interrupt the threads due to a timeout. >> >> David >> ----- >> >>> Naoto >>> >>> On 10/2/11 7:39 PM, Alan Bateman wrote: >>>> >>>> I haven't seen it but Olivier Lagneau asked me off-list recently about >>>> the same issue (same test, same failure mode). I've cc'ed the i18n folks >>>> in case they recognize it. My guess is that this is an implementation >>>> bug in LocaleServiceProviderPool rather than a test bug. >>>> >>>> -Alan. >>>> >>>> Kelly O'Hair wrote: >>>>> Anyone seen this testcase failure before? >>>>> >>>>> -kto >>>>> >>>>> -------------------------------------------------- >>>>> TEST: java/util/Locale/Bug6989440.java >>>>> JDK under test: >>>>> (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) >>>>> openjdk version "1.8.0-internal" >>>>> OpenJDK Runtime Environment (build >>>>> 1.8.0-internal-201110030014.jprtadm.jdk-b00) >>>>> Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) >>>>> >>>>> ACTION: compile -- Passed. Compilation successful >>>>> REASON: User specified action: run compile -XDignore.symbol.file=true >>>>> Bug6989440.java TIME: 0.053 seconds >>>>> messages: >>>>> command: compile -XDignore.symbol.file=true >>>>> /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java >>>>> reason: User specified action: run compile -XDignore.symbol.file=true >>>>> Bug6989440.java elapsed time (seconds): 0.053 >>>>> >>>>> ACTION: build -- Passed. All files up to date >>>>> REASON: Named class compiled on demand >>>>> TIME: 0.0 seconds >>>>> messages: >>>>> command: build Bug6989440 >>>>> reason: Named class compiled on demand >>>>> elapsed time (seconds): 0.0 >>>>> >>>>> ACTION: main -- Error. Error while cleaning up threads after test >>>>> REASON: User specified action: run main Bug6989440 TIME: 120.01 seconds >>>>> messages: >>>>> command: main Bug6989440 >>>>> reason: User specified action: run main Bug6989440 elapsed time >>>>> (seconds): 120.01 >>>>> STDOUT: >>>>> STDERR: >>>>> >>>>> JavaTest Message: Test complete. >>>>> >>>>> >>>>> TEST RESULT: Error. Error while cleaning up threads after test >>>>> -------------------------------------------------- >>>>> >>>> >>> From chris.hegarty at oracle.com Tue Oct 4 08:11:35 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Oct 2011 09:11:35 +0100 Subject: testcase failure In-Reply-To: <4E8A9790.10303@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> Message-ID: <4E8ABFB7.40108@oracle.com> Trivially, should the main thread in the test be waiting on the three other threads to complete before exiting? I think jtreg will try to cleanup once the main thread completes. The main thread should keep an array of the threads it creates and invoke join() on each of them before returning from main. We do this all the time in other areas. -Chris. On 10/ 4/11 06:20 AM, David Holmes wrote: > Kelly, > > The test is trivial - three threads try to get the locale data. Before > the fix you'd have multiple threads stomping on each other - after the > fix they should now be synchronized in terms of the primary > initialization. But I'd have to check the actual locale code as that is > where the synchronization needs to be. > > But again the other error comes from jtreg not from the testcase. > > David > > On 4/10/2011 7:44 AM, Kelly Ohair wrote: >> i have seen a similar bug in my own jprt code where i was accidently >> working with HashSet or HashMap objects in two different threads very >> strange things like this happened >> >> i dont have the testcase handy to look at but i highly suspect the >> testcase >> >> this last failure had nothing to with JPRT, just make&make test >> >> the test/Makefile might run jtreg a little differently but the >> testcase should not fail >> >> also it is critical that the test be run on a machine with more than >> one processor, it just will not reproduce on a machine without >> multiple processors >> >> >> Sent from my iPhone >> >> On Oct 3, 2011, at 14:25, David Holmes wrote: >> >>> On 4/10/2011 3:53 AM, Naoto Sato wrote: >>>> Discussed in the CR 7027061. Never been able to reproduce outside the >>>> JPRT system, and it's difficult to investigate such issue without >>>> reproducing it. >>> >>> This error message is coming from jtreg: >>> >>> ACTION: main -- Error. Error while cleaning up threads after test >>> REASON: User specified action: run main Bug6989440 >>> >>> so it needs to be investigated by jtreg folk. I suspect however that >>> it may be related to trying to interrupt the threads due to a timeout. >>> >>> David >>> ----- >>> >>>> Naoto >>>> >>>> On 10/2/11 7:39 PM, Alan Bateman wrote: >>>>> >>>>> I haven't seen it but Olivier Lagneau asked me off-list recently about >>>>> the same issue (same test, same failure mode). I've cc'ed the i18n >>>>> folks >>>>> in case they recognize it. My guess is that this is an implementation >>>>> bug in LocaleServiceProviderPool rather than a test bug. >>>>> >>>>> -Alan. >>>>> >>>>> Kelly O'Hair wrote: >>>>>> Anyone seen this testcase failure before? >>>>>> >>>>>> -kto >>>>>> >>>>>> -------------------------------------------------- >>>>>> TEST: java/util/Locale/Bug6989440.java >>>>>> JDK under test: >>>>>> (/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product) >>>>>> openjdk version "1.8.0-internal" >>>>>> OpenJDK Runtime Environment (build >>>>>> 1.8.0-internal-201110030014.jprtadm.jdk-b00) >>>>>> Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing) >>>>>> >>>>>> ACTION: compile -- Passed. Compilation successful >>>>>> REASON: User specified action: run compile -XDignore.symbol.file=true >>>>>> Bug6989440.java TIME: 0.053 seconds >>>>>> messages: >>>>>> command: compile -XDignore.symbol.file=true >>>>>> /tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java >>>>>> >>>>>> reason: User specified action: run compile -XDignore.symbol.file=true >>>>>> Bug6989440.java elapsed time (seconds): 0.053 >>>>>> >>>>>> ACTION: build -- Passed. All files up to date >>>>>> REASON: Named class compiled on demand >>>>>> TIME: 0.0 seconds >>>>>> messages: >>>>>> command: build Bug6989440 >>>>>> reason: Named class compiled on demand >>>>>> elapsed time (seconds): 0.0 >>>>>> >>>>>> ACTION: main -- Error. Error while cleaning up threads after test >>>>>> REASON: User specified action: run main Bug6989440 TIME: 120.01 >>>>>> seconds >>>>>> messages: >>>>>> command: main Bug6989440 >>>>>> reason: User specified action: run main Bug6989440 elapsed time >>>>>> (seconds): 120.01 >>>>>> STDOUT: >>>>>> STDERR: >>>>>> >>>>>> JavaTest Message: Test complete. >>>>>> >>>>>> >>>>>> TEST RESULT: Error. Error while cleaning up threads after test >>>>>> -------------------------------------------------- >>>>>> >>>>> >>>> From jandam at crcdata.cz Tue Oct 4 09:48:06 2011 From: jandam at crcdata.cz (Janda Martin) Date: Tue, 4 Oct 2011 11:48:06 +0200 (CEST) Subject: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post In-Reply-To: <11716099.801317721612742.JavaMail.root@zs.crcpraha> Message-ID: <19862960.851317721686499.JavaMail.root@zs.crcpraha> I hope that this is correct mailing list to comment JEP 103. Proposal: provide static methods for creating sort tasks. This allows developers to have full control over ForkJoinPool. There can be problem with one shared defaultFJPool() in multi-module applications (like Netbeans platform) when two modules requests different FJPool settings. public final class ForkJoinUtils { // should this be replaced? public static ForkJoinPool defaultFJPool() { ... } public static byte[] parallelSort(byte[] a) { ... } public static byte[] parallelSort(byte[] a, int fromIndex, int toIndex) {...} // with this? public static SortTask createParallelSortTask(byte[] a) {...} public static SortTask createParallelSortTask(byte[] a, int fromIndex, int toIndex) {...} ... } Reaction to Mr. Harned post I work as a Java SE software developer for several years. I think that Mr. Harned opinion to freeze Java in software history ('30' years ago) is not good idea. JSR 166 Fork/Join is great contribution to make Java better (thank you very much Doug Lea). Today CPUs just adds new cores so there have to be better support for parallelism. j.u.c package isn't only about sorting long arrays (huge overhead). Programs do a lot more. Thread, ThreadPool, FJPool and j.u.c are just small pieces in real application. They are solid and can be extended/controlled to support specific needs. I think that Mr. Harned should improve his own libraries to comply with his objections. I looked at his source code, demos and I prefer j.u.c to his work. Thank you everybody who works on Java Sincerely Martin JANDA PS sorry for my english From Alan.Bateman at oracle.com Tue Oct 4 13:24:11 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Oct 2011 14:24:11 +0100 Subject: testcase failure In-Reply-To: <4E8ABFB7.40108@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> Message-ID: <4E8B08FB.4040703@oracle.com> Chris Hegarty wrote: > Trivially, should the main thread in the test be waiting on the three > other threads to complete before exiting? > > I think jtreg will try to cleanup once the main thread completes. The > main thread should keep an array of the threads it creates and invoke > join() on each of them before returning from main. We do this all the > time in other areas. Right, once the main thread completes then jtreg will attempt to cleanup the remaining non-daemon threads in the thread group. It does this by interrupting each of the remaining threads in a loop up to a maximum number of rounds or until the remaining threads have terminated. It's possible that if the test is changed up to join on each of the 3 threads that this intermittent failure will go away. If so, then it suggests to me that perhaps the interrupt is causing a side effect that causes one of the threads to go into a loop block uninterruptedly. This is just a guess of course and it requires digging into the Locale code to come up with specific theories. -Alan. From chris.hegarty at oracle.com Tue Oct 4 15:12:21 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 04 Oct 2011 15:12:21 +0000 Subject: hg: jdk8/tl/jdk: 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Message-ID: <20111004151240.D32BB47BC1@hg.openjdk.java.net> Changeset: 74f5fef1d961 Author: chegar Date: 2011-10-04 13:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74f5fef1d961 6953455: CookieStore.add() cannot handle null URI parameter, contrary to the API Reviewed-by: chegar, mduigou Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/InMemoryCookieStore.java + test/java/net/CookieHandler/NullUriCookieTest.java From david.holmes at oracle.com Tue Oct 4 16:04:33 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Oct 2011 02:04:33 +1000 Subject: testcase failure In-Reply-To: <4E8B08FB.4040703@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> Message-ID: <4E8B2E91.4020604@oracle.com> Thanks Chris and Alan. On 4/10/2011 11:24 PM, Alan Bateman wrote: > Chris Hegarty wrote: >> Trivially, should the main thread in the test be waiting on the three >> other threads to complete before exiting? >> >> I think jtreg will try to cleanup once the main thread completes. The >> main thread should keep an array of the threads it creates and invoke >> join() on each of them before returning from main. We do this all the >> time in other areas. > Right, once the main thread completes then jtreg will attempt to cleanup > the remaining non-daemon threads in the thread group. It does this by > interrupting each of the remaining threads in a loop up to a maximum > number of rounds or until the remaining threads have terminated. I wasn't aware of this behaviour from jtreg (but then I don't write such tests). It explains the jtreg "error". I expect the test threads are not responsive to interrupts (why should they be). The reported ConcurrentModificationException would indicate a potential issue still remaining in the locale code. David It's > possible that if the test is changed up to join on each of the 3 threads > that this intermittent failure will go away. If so, then it suggests to > me that perhaps the interrupt is causing a side effect that causes one > of the threads to go into a loop block uninterruptedly. This is just a > guess of course and it requires digging into the Locale code to come up > with specific theories. > > -Alan. From david.holmes at oracle.com Tue Oct 4 16:25:55 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Oct 2011 02:25:55 +1000 Subject: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post In-Reply-To: <19862960.851317721686499.JavaMail.root@zs.crcpraha> References: <19862960.851317721686499.JavaMail.root@zs.crcpraha> Message-ID: <4E8B3393.6080503@oracle.com> Hi Janda, Thanks for the comments. On 4/10/2011 7:48 PM, Janda Martin wrote: > > I hope that this is correct mailing list to comment JEP 103. It certainly is. > Proposal: provide static methods for creating sort tasks. This allows developers to have full control over ForkJoinPool. I'd personally prefer to pass in the FJP to the sort method, rather than expose a SortTask type. Though I do cringe at the thought of all the additional methods (I wonder if Coin2 would be open to suggesting we add default arguments to Java ...) > There can be problem with one shared defaultFJPool() in multi-module applications (like Netbeans platform) when two modules requests different FJPool settings. Although the JEP proposes properties to allow the configuration of the default FJPool, the expectation is that: a) the majority of the time you will use the default configuration (desired parallelism level = number of 'processors') b) any change to the default config is done as a "system" setting, not by "local logic". By which I mean that it is not expected that different "modules" will attempt to do this configuration. Perhaps we need a way to enforce this. Personally I think there is room to have multiple FJPools in a system, but that makes most sense if the pools use disjoint sets of processors - which isn't currently supported in Java. But this is precisely the kind of feedback we are looking for, so thanks again. David Holmes ------------ > public final class ForkJoinUtils { > > // should this be replaced? > public static ForkJoinPool defaultFJPool() { ... } > > public static byte[] parallelSort(byte[] a) { ... } > public static byte[] parallelSort(byte[] a, int fromIndex, int toIndex) > {...} > > // with this? > public static SortTask createParallelSortTask(byte[] a) {...} > public static SortTask createParallelSortTask(byte[] a, int fromIndex, int toIndex) {...} > ... > > } > > Reaction to Mr. Harned post > > I work as a Java SE software developer for several years. I think that Mr. Harned opinion to freeze Java in software history ('30' years ago) is not good idea. > JSR 166 Fork/Join is great contribution to make Java better (thank you very much Doug Lea). Today CPUs just adds new cores so there have to be better support for parallelism. > > j.u.c package isn't only about sorting long arrays (huge overhead). Programs do a lot more. > > Thread, ThreadPool, FJPool and j.u.c are just small pieces in real application. They are solid and can be extended/controlled to support specific needs. > > I think that Mr. Harned should improve his own libraries to comply with his objections. I looked at his source code, demos and I prefer j.u.c to his work. > > Thank you everybody who works on Java > > Sincerely > Martin JANDA > > PS sorry for my english From chris.hegarty at oracle.com Tue Oct 4 16:52:58 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 04 Oct 2011 16:52:58 +0000 Subject: hg: jdk8/tl/jdk: 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Message-ID: <20111004165316.BF71647BC6@hg.openjdk.java.net> Changeset: 24741fe639a8 Author: chegar Date: 2011-10-04 16:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24741fe639a8 7095949: java/net/URLConnection/RedirectLimit.java and Redirect307Test fail intermittently Reviewed-by: alanb ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java From lordpixel+core-libs-dev at mac.com Wed Oct 5 03:08:12 2011 From: lordpixel+core-libs-dev at mac.com (Andrew Thompson) Date: Tue, 4 Oct 2011 23:08:12 -0400 Subject: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post In-Reply-To: <4E8B3393.6080503@oracle.com> References: <19862960.851317721686499.JavaMail.root@zs.crcpraha> <4E8B3393.6080503@oracle.com> Message-ID: <989592C0-C636-44F6-A5EE-DCBDA9C5E53D@mac.com> Both JEP 103 and JEP 108 are interesting to me because they remind me of something I've discussed a couple of times with one of the engineers working on the JDK at Apple. (I'll not name him solely because his input was a casual 'that sounds interesting' and I don't want to imply he endorses this idea.). The topic was Apple's Grand Central Dispatch and its applicability or lack thereof to Java programs. When we originally discussed it we noted that obviously the old Java idiom of doing 'new Thread()' directly in code is not remotely abstract enough for a vendor like Apple to be able to 'plug in' Grand Central (aka libdispatch) to do the scheduling. Of course, Executor/ExecutorService/Executors is a different story - since an ExecutorService can be a simple thread pool, a ForkJoinPool, or indeed, as Apple later created, a Grand Central backed pool: http://developer.apple.com/library/mac/documentation/Java/Reference/JavaSE6_AppleExtensionsRef/api/com/apple/concurrent/Dispatch.html But, what we concluded was Java 6 didn't offer an API or an SPI in this area. The creation of 'thread pools' is a bit more abstract than 'new Thread()' but really still fairly concrete ExecutorService myPool = Executors.newFixedThreadPool(5); // pretty clear what this means, create a pool with 5 new dedicated threads What I imagined would look something more like: ExecutorServer myCoolPool = Executors.defaultPlatformExecutorService(); //which on OSX might mean Grand Central dispatch (com.apple.concurrent.Dispatch) and something else on other platforms. Accompanying this would be an SPI allowing the 'default' thread pool to be changed. Well, JEP 103 has a similar idea embedded in it: "In addition to the actual sorting API this proposal adds a default ForkJoinPool to the platform. Consequently both the sorting API and access to the default pool is proposed to be provided by the ForkJoinUtils class: public final class ForkJoinUtils { public static ForkJoinPool defaultFJPool() { ... } ..." So is there any convergence between these ideas? Should we be thinking about adding a default ForkJoinPool to the platform, or should we be thinking about adding a default ExecutorService to the platform, which may or may not be a ForkJoinPool based on some clever logic the platform vendor could run based on # of cpus, memory, etc? I think the idea of a platform ExecutorService is interesting and may warrant its own separate JEP, which I'd be happy to write (I was thinking of doing so anyway, but I also thought it might make sense to prototype something first). On Oct 4, 2011, at 12:25 PM, David Holmes wrote: > Hi Janda, > > Thanks for the comments. > > On 4/10/2011 7:48 PM, Janda Martin wrote: >> >> I hope that this is correct mailing list to comment JEP 103. > > It certainly is. > >> Proposal: provide static methods for creating sort tasks. This allows developers to have full control over ForkJoinPool. > > I'd personally prefer to pass in the FJP to the sort method, rather than expose a SortTask type. Though I do cringe at the thought of all the additional methods (I wonder if Coin2 would be open to suggesting we add default arguments to Java ...) > >> There can be problem with one shared defaultFJPool() in multi-module applications (like Netbeans platform) when two modules requests different FJPool settings. > > Although the JEP proposes properties to allow the configuration of the default FJPool, the expectation is that: > > a) the majority of the time you will use the default configuration (desired parallelism level = number of 'processors') > > b) any change to the default config is done as a "system" setting, not by "local logic". By which I mean that it is not expected that different "modules" will attempt to do this configuration. Perhaps we need a way to enforce this. > > Personally I think there is room to have multiple FJPools in a system, but that makes most sense if the pools use disjoint sets of processors - which isn't currently supported in Java. > > But this is precisely the kind of feedback we are looking for, so thanks again. > > David Holmes > ------------ > >> public final class ForkJoinUtils { >> >> // should this be replaced? >> public static ForkJoinPool defaultFJPool() { ... } >> >> public static byte[] parallelSort(byte[] a) { ... } >> public static byte[] parallelSort(byte[] a, int fromIndex, int toIndex) >> {...} >> >> // with this? >> public static SortTask createParallelSortTask(byte[] a) {...} >> public static SortTask createParallelSortTask(byte[] a, int fromIndex, int toIndex) {...} >> ... >> >> } >> >> Reaction to Mr. Harned post >> >> I work as a Java SE software developer for several years. I think that Mr. Harned opinion to freeze Java in software history ('30' years ago) is not good idea. >> JSR 166 Fork/Join is great contribution to make Java better (thank you very much Doug Lea). Today CPUs just adds new cores so there have to be better support for parallelism. >> >> j.u.c package isn't only about sorting long arrays (huge overhead). Programs do a lot more. >> >> Thread, ThreadPool, FJPool and j.u.c are just small pieces in real application. They are solid and can be extended/controlled to support specific needs. >> >> I think that Mr. Harned should improve his own libraries to comply with his objections. I looked at his source code, demos and I prefer j.u.c to his work. >> >> Thank you everybody who works on Java >> >> Sincerely >> Martin JANDA >> >> PS sorry for my english AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me) AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me) From masayoshi.okutsu at oracle.com Wed Oct 5 06:23:52 2011 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 05 Oct 2011 06:23:52 +0000 Subject: hg: jdk8/tl/jdk: 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11; ... Message-ID: <20111005062411.EF7E847BEC@hg.openjdk.java.net> Changeset: 2bc80ba6f4a4 Author: okutsu Date: 2011-10-05 15:13 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc80ba6f4a4 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 6984762: Invalid close of file descriptor '-1' in findZoneinfoFile Reviewed-by: coffeys, ohair, naoto, peytoia ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/java/Makefile ! src/solaris/native/java/util/TimeZone_md.c From kasperni at gmail.com Wed Oct 5 07:53:30 2011 From: kasperni at gmail.com (Kasper Nielsen) Date: Wed, 05 Oct 2011 09:53:30 +0200 Subject: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post In-Reply-To: <989592C0-C636-44F6-A5EE-DCBDA9C5E53D@mac.com> References: <19862960.851317721686499.JavaMail.root@zs.crcpraha> <4E8B3393.6080503@oracle.com> <989592C0-C636-44F6-A5EE-DCBDA9C5E53D@mac.com> Message-ID: <4E8C0CFA.3010008@gmail.com> On 05-10-2011 05:08, Andrew Thompson wrote: > So is there any convergence between these ideas? Should we be thinking about adding a default ForkJoinPool to the platform, or should we be thinking about adding a default ExecutorService to the platform, which may or may not be a ForkJoinPool based on some clever logic the platform vendor could run based on # of cpus, memory, etc? > > I think the idea of a platform ExecutorService is interesting and may warrant its own separate JEP, which I'd be happy to write (I was thinking of doing so anyway, but I also thought it might make sense to prototype something first). Andrew, There was a discussion about this on the jsr-166 mailing list last year: http://cs.oswego.edu/pipermail/concurrency-interest/2010-August/007334.html I think there was pros and cons, so nothing really happened. cheers Kasper From dl at cs.oswego.edu Wed Oct 5 12:02:21 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 05 Oct 2011 08:02:21 -0400 Subject: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post In-Reply-To: <4E8C0CFA.3010008@gmail.com> References: <19862960.851317721686499.JavaMail.root@zs.crcpraha> <4E8B3393.6080503@oracle.com> <989592C0-C636-44F6-A5EE-DCBDA9C5E53D@mac.com> <4E8C0CFA.3010008@gmail.com> Message-ID: <4E8C474D.1000706@cs.oswego.edu> On 10/05/11 03:53, Kasper Nielsen wrote: > On 05-10-2011 05:08, Andrew Thompson wrote: >> So is there any convergence between these ideas? Should we be thinking about >> adding a default ForkJoinPool to the platform, or should we be thinking about >> adding a default ExecutorService to the platform, > > There was a discussion about this on the jsr-166 mailing list last year: > > http://cs.oswego.edu/pipermail/concurrency-interest/2010-August/007334.html There are two main (entangled) issues here: 1. How do you avoid requiring every method that might entail parallelism to include a parameter indicating the Executor to use, but still allow overrides? 2. How do you deal with possibly varying scheduling policies of different Executors? For example, while the use of work-stealing vs centralized queue in FJ is semantically neutral, its default locally-LIFO policy is not -- there are non-ForkJoin-like usages that only work well if the policy is overridden to be locally-FIFO (which is intrinsically a global set-once-in-constructor policy). Here are a few thoughts on resolution. 1. An Executor could be associated with each ThreadGroup, as a sort of InheritableThreadGroupLocal: * by default in the initial ThreadGroup it is some common global Executor that can be set by a Property * A new ThreadGroup constructor allows creation of one used by all threads in the group * A new ThreadGroup created without an override uses the one in used by the thread calling the new ThreadGroup constructor. This might also be overridable via some Property So, if you'd like to use an alternative common executor, you'd need to either create a new ThreadGroup or change some Property. This is not perfectly flexible, but probably flexible enough to still be better than the alternative of adding Executor parameters to the many classes/methods that will surely be created in the future as more and more functionality entails parallelism. Plus all the cases where you cannot do this because you'd like change existing methods that do not have any such parameters. 2. Some metadata could be associated with the above executors that individual classes/methods could use to decide if they need to waste the time/space creating a different kind of executor for their service. These attributes would need to simply structured and trivial to check, since you do not want to create a sequential bottleneck just deciding which parallel facility to use. -Doug From chris.hegarty at oracle.com Wed Oct 5 14:07:00 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 05 Oct 2011 15:07:00 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8B2E91.4020604@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> Message-ID: <4E8C6484.2010909@oracle.com> Alan, David, I noticed CR 7027061 was closed as 'not a defect'. Should I file a new CR to have the jtreg test fixed (join on all created threads)? The test will still exercise what it is supposed to, and the ConcurrentModificationException issue can be investigated at another time. This way we can get more stable test runs. -Chris. On 04/10/2011 17:04, David Holmes wrote: > Thanks Chris and Alan. > > On 4/10/2011 11:24 PM, Alan Bateman wrote: >> Chris Hegarty wrote: >>> Trivially, should the main thread in the test be waiting on the three >>> other threads to complete before exiting? >>> >>> I think jtreg will try to cleanup once the main thread completes. The >>> main thread should keep an array of the threads it creates and invoke >>> join() on each of them before returning from main. We do this all the >>> time in other areas. >> Right, once the main thread completes then jtreg will attempt to cleanup >> the remaining non-daemon threads in the thread group. It does this by >> interrupting each of the remaining threads in a loop up to a maximum >> number of rounds or until the remaining threads have terminated. > > I wasn't aware of this behaviour from jtreg (but then I don't write such > tests). It explains the jtreg "error". I expect the test threads are not > responsive to interrupts (why should they be). > > The reported ConcurrentModificationException would indicate a potential > issue still remaining in the locale code. > > David > > It's >> possible that if the test is changed up to join on each of the 3 threads >> that this intermittent failure will go away. If so, then it suggests to >> me that perhaps the interrupt is causing a side effect that causes one >> of the threads to go into a loop block uninterruptedly. This is just a >> guess of course and it requires digging into the Locale code to come up >> with specific theories. >> >> -Alan. From naoto.sato at oracle.com Wed Oct 5 14:57:47 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 05 Oct 2011 07:57:47 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C6484.2010909@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> Message-ID: <4E8C706B.4040200@oracle.com> Hi Chris, I appreciate it, and will fix the test case. Naoto On 10/5/11 7:07 AM, Chris Hegarty wrote: > Alan, David, > > I noticed CR 7027061 was closed as 'not a defect'. Should I file a new > CR to have the jtreg test fixed (join on all created threads)? The test > will still exercise what it is supposed to, and the > ConcurrentModificationException issue can be investigated at another > time. This way we can get more stable test runs. > > -Chris. > > On 04/10/2011 17:04, David Holmes wrote: >> Thanks Chris and Alan. >> >> On 4/10/2011 11:24 PM, Alan Bateman wrote: >>> Chris Hegarty wrote: >>>> Trivially, should the main thread in the test be waiting on the three >>>> other threads to complete before exiting? >>>> >>>> I think jtreg will try to cleanup once the main thread completes. The >>>> main thread should keep an array of the threads it creates and invoke >>>> join() on each of them before returning from main. We do this all the >>>> time in other areas. >>> Right, once the main thread completes then jtreg will attempt to cleanup >>> the remaining non-daemon threads in the thread group. It does this by >>> interrupting each of the remaining threads in a loop up to a maximum >>> number of rounds or until the remaining threads have terminated. >> >> I wasn't aware of this behaviour from jtreg (but then I don't write such >> tests). It explains the jtreg "error". I expect the test threads are not >> responsive to interrupts (why should they be). >> >> The reported ConcurrentModificationException would indicate a potential >> issue still remaining in the locale code. >> >> David >> >> It's >>> possible that if the test is changed up to join on each of the 3 threads >>> that this intermittent failure will go away. If so, then it suggests to >>> me that perhaps the interrupt is causing a side effect that causes one >>> of the threads to go into a loop block uninterruptedly. This is just a >>> guess of course and it requires digging into the Locale code to come up >>> with specific theories. >>> >>> -Alan. From chris.hegarty at oracle.com Wed Oct 5 15:42:31 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 05 Oct 2011 16:42:31 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C706B.4040200@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> Message-ID: <4E8C7AE7.10807@oracle.com> Alan, Naoto, David I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently. If you're ok with it please review the patch (below) and I can push it to the tl repo. Job done! >: hg diff test/java/util/Locale/Bug6989440.java diff -r 24741fe639a8 test/java/util/Locale/Bug6989440.java --- a/test/java/util/Locale/Bug6989440.java Tue Oct 04 16:37:08 2011 +0100 +++ b/test/java/util/Locale/Bug6989440.java Wed Oct 05 16:34:09 2011 +0100 @@ -37,14 +37,15 @@ import sun.util.LocaleServiceProviderPoo import sun.util.LocaleServiceProviderPool; public class Bug6989440 { - public static void main(String[] args) { - TestThread t1 = new TestThread(LocaleNameProvider.class); - TestThread t2 = new TestThread(TimeZoneNameProvider.class); - TestThread t3 = new TestThread(DateFormatProvider.class); - - t1.start(); - t2.start(); - t3.start(); + public static void main(String[] args) throws Exception { + Thread[] threads = new Thread[3]; + threads[0] = new TestThread(LocaleNameProvider.class); + threads[1] = new TestThread(TimeZoneNameProvider.class); + threads[2] = new TestThread(DateFormatProvider.class); + for (int i=0; i Hi Chris, > > I appreciate it, and will fix the test case. > > Naoto > > On 10/5/11 7:07 AM, Chris Hegarty wrote: >> Alan, David, >> >> I noticed CR 7027061 was closed as 'not a defect'. Should I file a new >> CR to have the jtreg test fixed (join on all created threads)? The test >> will still exercise what it is supposed to, and the >> ConcurrentModificationException issue can be investigated at another >> time. This way we can get more stable test runs. >> >> -Chris. >> >> On 04/10/2011 17:04, David Holmes wrote: >>> Thanks Chris and Alan. >>> >>> On 4/10/2011 11:24 PM, Alan Bateman wrote: >>>> Chris Hegarty wrote: >>>>> Trivially, should the main thread in the test be waiting on the three >>>>> other threads to complete before exiting? >>>>> >>>>> I think jtreg will try to cleanup once the main thread completes. The >>>>> main thread should keep an array of the threads it creates and invoke >>>>> join() on each of them before returning from main. We do this all the >>>>> time in other areas. >>>> Right, once the main thread completes then jtreg will attempt to >>>> cleanup >>>> the remaining non-daemon threads in the thread group. It does this by >>>> interrupting each of the remaining threads in a loop up to a maximum >>>> number of rounds or until the remaining threads have terminated. >>> >>> I wasn't aware of this behaviour from jtreg (but then I don't write such >>> tests). It explains the jtreg "error". I expect the test threads are not >>> responsive to interrupts (why should they be). >>> >>> The reported ConcurrentModificationException would indicate a potential >>> issue still remaining in the locale code. >>> >>> David >>> >>> It's >>>> possible that if the test is changed up to join on each of the 3 >>>> threads >>>> that this intermittent failure will go away. If so, then it suggests to >>>> me that perhaps the interrupt is causing a side effect that causes one >>>> of the threads to go into a loop block uninterruptedly. This is just a >>>> guess of course and it requires digging into the Locale code to come up >>>> with specific theories. >>>> >>>> -Alan. > From naoto.sato at oracle.com Wed Oct 5 15:53:55 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 05 Oct 2011 08:53:55 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C7AE7.10807@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> Message-ID: <4E8C7D93.5030807@oracle.com> Looks good to me. Thanks! Naoto On 10/5/11 8:42 AM, Chris Hegarty wrote: > Alan, Naoto, David > > I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently. > > If you're ok with it please review the patch (below) and I can push it > to the tl repo. Job done! > > >: hg diff test/java/util/Locale/Bug6989440.java > diff -r 24741fe639a8 test/java/util/Locale/Bug6989440.java > --- a/test/java/util/Locale/Bug6989440.java Tue Oct 04 16:37:08 2011 +0100 > +++ b/test/java/util/Locale/Bug6989440.java Wed Oct 05 16:34:09 2011 +0100 > @@ -37,14 +37,15 @@ import sun.util.LocaleServiceProviderPoo > import sun.util.LocaleServiceProviderPool; > > public class Bug6989440 { > - public static void main(String[] args) { > - TestThread t1 = new TestThread(LocaleNameProvider.class); > - TestThread t2 = new TestThread(TimeZoneNameProvider.class); > - TestThread t3 = new TestThread(DateFormatProvider.class); > - > - t1.start(); > - t2.start(); > - t3.start(); > + public static void main(String[] args) throws Exception { > + Thread[] threads = new Thread[3]; > + threads[0] = new TestThread(LocaleNameProvider.class); > + threads[1] = new TestThread(TimeZoneNameProvider.class); > + threads[2] = new TestThread(DateFormatProvider.class); > + for (int i=0; i + threads[i].start(); > + for (int i=0; i + threads[i].join(); > } > > > -Chris. > > > On 05/10/2011 15:57, Naoto Sato wrote: >> Hi Chris, >> >> I appreciate it, and will fix the test case. >> >> Naoto >> >> On 10/5/11 7:07 AM, Chris Hegarty wrote: >>> Alan, David, >>> >>> I noticed CR 7027061 was closed as 'not a defect'. Should I file a new >>> CR to have the jtreg test fixed (join on all created threads)? The test >>> will still exercise what it is supposed to, and the >>> ConcurrentModificationException issue can be investigated at another >>> time. This way we can get more stable test runs. >>> >>> -Chris. >>> >>> On 04/10/2011 17:04, David Holmes wrote: >>>> Thanks Chris and Alan. >>>> >>>> On 4/10/2011 11:24 PM, Alan Bateman wrote: >>>>> Chris Hegarty wrote: >>>>>> Trivially, should the main thread in the test be waiting on the three >>>>>> other threads to complete before exiting? >>>>>> >>>>>> I think jtreg will try to cleanup once the main thread completes. The >>>>>> main thread should keep an array of the threads it creates and invoke >>>>>> join() on each of them before returning from main. We do this all the >>>>>> time in other areas. >>>>> Right, once the main thread completes then jtreg will attempt to >>>>> cleanup >>>>> the remaining non-daemon threads in the thread group. It does this by >>>>> interrupting each of the remaining threads in a loop up to a maximum >>>>> number of rounds or until the remaining threads have terminated. >>>> >>>> I wasn't aware of this behaviour from jtreg (but then I don't write >>>> such >>>> tests). It explains the jtreg "error". I expect the test threads are >>>> not >>>> responsive to interrupts (why should they be). >>>> >>>> The reported ConcurrentModificationException would indicate a potential >>>> issue still remaining in the locale code. >>>> >>>> David >>>> >>>> It's >>>>> possible that if the test is changed up to join on each of the 3 >>>>> threads >>>>> that this intermittent failure will go away. If so, then it >>>>> suggests to >>>>> me that perhaps the interrupt is causing a side effect that causes one >>>>> of the threads to go into a loop block uninterruptedly. This is just a >>>>> guess of course and it requires digging into the Locale code to >>>>> come up >>>>> with specific theories. >>>>> >>>>> -Alan. >> From Alan.Bateman at oracle.com Wed Oct 5 16:58:50 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Oct 2011 17:58:50 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C7AE7.10807@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> Message-ID: <4E8C8CCA.7010100@oracle.com> Chris Hegarty wrote: > Alan, Naoto, David > > I filed CR 7098100: java/util/Locale/Bug6989440.java fails > intermittently. > > If you're ok with it please review the patch (below) and I can push it > to the tl repo. Job done! I assume there is also some underlying issue in the Locale code and this might get hidden if we fix the test (I"ve no objection to fixing the test of course, just thinking that we should study the Locale code to try to identify the deadlock or hang or whatever it is that is causing the threads in this test not to terminate). -Alan From naoto.sato at oracle.com Wed Oct 5 17:35:26 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 05 Oct 2011 10:35:26 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C8CCA.7010100@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> Message-ID: <4E8C955E.6060502@oracle.com> I will look into this. Reopened the original CR. Naoto On 10/5/11 9:58 AM, Alan Bateman wrote: > Chris Hegarty wrote: >> Alan, Naoto, David >> >> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >> intermittently. >> >> If you're ok with it please review the patch (below) and I can push it >> to the tl repo. Job done! > I assume there is also some underlying issue in the Locale code and this > might get hidden if we fix the test (I"ve no objection to fixing the > test of course, just thinking that we should study the Locale code to > try to identify the deadlock or hang or whatever it is that is causing > the threads in this test not to terminate). > > -Alan From david.holmes at oracle.com Wed Oct 5 17:46:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Oct 2011 03:46:23 +1000 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C8CCA.7010100@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> Message-ID: <4E8C97EF.3070707@oracle.com> On 6/10/2011 2:58 AM, Alan Bateman wrote: > Chris Hegarty wrote: >> Alan, Naoto, David >> >> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >> intermittently. >> >> If you're ok with it please review the patch (below) and I can push it >> to the tl repo. Job done! > I assume there is also some underlying issue in the Locale code and this > might get hidden if we fix the test (I"ve no objection to fixing the > test of course, just thinking that we should study the Locale code to > try to identify the deadlock or hang or whatever it is that is causing > the threads in this test not to terminate). Fixing the test should not impact the ConcurrentModificationException issue. The fix is ok - thanks Chris. The original CR should have been reassigned to the correct category rather than being closed when filed in the wrong (JPRT) category :( I'll try to take a few minutes and look at the locale code. David From david.holmes at oracle.com Wed Oct 5 18:01:51 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Oct 2011 04:01:51 +1000 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C955E.6060502@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> Message-ID: <4E8C9B8F.8000205@oracle.com> This might not be related to the CME problem, but here: public static LocaleServiceProviderPool getPool(Class providerClass) { LocaleServiceProviderPool pool = poolOfPools.get(providerClass); if (pool == null) { LocaleServiceProviderPool newPool = new LocaleServiceProviderPool(providerClass); pool = poolOfPools.put(providerClass, newPool); if (pool == null) { pool = newPool; } } return pool; } we should probably be using poolOfPools.putIfAbsent(providerClass, newPool) David On 6/10/2011 3:35 AM, Naoto Sato wrote: > I will look into this. Reopened the original CR. > > Naoto > > On 10/5/11 9:58 AM, Alan Bateman wrote: >> Chris Hegarty wrote: >>> Alan, Naoto, David >>> >>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>> intermittently. >>> >>> If you're ok with it please review the patch (below) and I can push it >>> to the tl repo. Job done! >> I assume there is also some underlying issue in the Locale code and this >> might get hidden if we fix the test (I"ve no objection to fixing the >> test of course, just thinking that we should study the Locale code to >> try to identify the deadlock or hang or whatever it is that is causing >> the threads in this test not to terminate). >> >> -Alan > From chris.hegarty at oracle.com Thu Oct 6 11:02:57 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Oct 2011 12:02:57 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8C9B8F.8000205@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> Message-ID: <4E8D8AE1.8080902@oracle.com> David, Expanding (more threads and more runs) and running this test on one of our dual core Linux x64 boxes, reproduce the CME about one in every ten runs. I instrumented where the CME was being created to determine the expected/actual modcount: final void checkForComodification() { if (modCount != expectedModCount) - throw new ConcurrentModificationException(); + throw new ConcurrentModificationException("Expected: " + expectedModCount + + ", got: " + modCount); I see several exceptions, similar to the following (numbers vary): Exception in thread "Thread-23" java.util.ConcurrentModificationException: Expected: 96, got: 156 at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) at java.util.ArrayList$Itr.next(ArrayList.java:791) at java.util.AbstractCollection.addAll(AbstractCollection.java:333) at java.util.HashSet.(HashSet.java:117) at sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) at Interrupter$TestThread.run(Interrupter.java:49) There would appear to be 156 JRE Locales ( at least on this system ), modCount is incremented for each add(), but when the iterator is created ( implicitly during the HastSet.addAll ) it sees a different value for modCount. I think there is a visibility issue here. availableJRELocales is volatile, but the List reference returned from getJRELocales is not. In the case where availableJRELocales is not null there will be no memory barrier to force a HB relationship. Or maybe I've gotten this wrong? His is quite bizarre, or maybe it is just the overly complicated use of locking/DCL in this class. -Chris. On 10/ 5/11 07:01 PM, David Holmes wrote: > This might not be related to the CME problem, but here: > > public static LocaleServiceProviderPool getPool(Class LocaleServiceProvider> providerClass) { > LocaleServiceProviderPool pool = poolOfPools.get(providerClass); > if (pool == null) { > LocaleServiceProviderPool newPool = > new LocaleServiceProviderPool(providerClass); > pool = poolOfPools.put(providerClass, newPool); > if (pool == null) { > pool = newPool; > } > } > > return pool; > } > > we should probably be using poolOfPools.putIfAbsent(providerClass, newPool) > > David > > On 6/10/2011 3:35 AM, Naoto Sato wrote: >> I will look into this. Reopened the original CR. >> >> Naoto >> >> On 10/5/11 9:58 AM, Alan Bateman wrote: >>> Chris Hegarty wrote: >>>> Alan, Naoto, David >>>> >>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>> intermittently. >>>> >>>> If you're ok with it please review the patch (below) and I can push it >>>> to the tl repo. Job done! >>> I assume there is also some underlying issue in the Locale code and this >>> might get hidden if we fix the test (I"ve no objection to fixing the >>> test of course, just thinking that we should study the Locale code to >>> try to identify the deadlock or hang or whatever it is that is causing >>> the threads in this test not to terminate). >>> >>> -Alan >> From chris.hegarty at oracle.com Thu Oct 6 13:24:28 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 06 Oct 2011 13:24:28 +0000 Subject: hg: jdk8/tl/jdk: 7090499: missing rawtypes warnings in anonymous inner class Message-ID: <20111006132450.30F6947C40@hg.openjdk.java.net> Changeset: ff5e57dc1fb3 Author: chegar Date: 2011-10-06 12:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff5e57dc1fb3 7090499: missing rawtypes warnings in anonymous inner class Summary: Fix anonymous inner classes with raw types currently being built in the jdk with -Werror Reviewed-by: mcimadamore, alanb ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java From chris.hegarty at oracle.com Thu Oct 6 13:34:51 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Oct 2011 14:34:51 +0100 Subject: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Message-ID: <4E8DAE7B.4000109@oracle.com> I filed CR 7098394 against this. Solaris 10 x64 build fails since the integration of CR 7092679. "../../../src/solaris/native/java/util/TimeZone_md.c", line 128: prototype mismatch: 2 args passed, 3 expected "../../../src/solaris/native/java/util/TimeZone_md.c", line 128: warning: improper pointer/integer combination: op "=" cc: acomp failed for ../../../src/solaris/native/java/util/TimeZone_md.c make[3]: *** [../../../build/solaris-amd64/tmp/java/java.lang/java/obj64/TimeZone_md.o] Error 1 make[3]: Leaving directory `/tmp/jprt/P1/112204.ch122065/source/make/java/java' make[2]: *** [library_parallel_compile] Error 2 make[2]: Leaving directory `/tmp/jprt/P1/112204.ch122065/source/make/java/java' make[1]: *** [all] Error 1 make[1]: Leaving directory `/tmp/jprt/P1/112204.ch122065/source/make/java' make: *** [all] Error 1 -Chris. From david.holmes at oracle.com Thu Oct 6 17:09:33 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Oct 2011 03:09:33 +1000 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8D8AE1.8080902@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> Message-ID: <4E8DE0CD.3080401@oracle.com> Hi Chris, Thanks. Here's the bug: private List getJRELocales() { if (availableJRELocales == null) { synchronized (LocaleServiceProviderPool.class) { if (availableJRELocales == null) { Locale[] allLocales = LocaleData.getAvailableLocales(); availableJRELocales = new ArrayList(allLocales.length); <<==== YIKES we just published an empty ArrayList for (Locale locale : allLocales) { availableJRELocales.add(getLookupLocale(locale)); } } } } return availableJRELocales; } availableJRELocales is a static variable shared across all pools. But it is being published before it gets populated. We need to use a temporary for the new ArrayList and only assign to availableJRELocales after it is populated. In addition, as you mentioned, availableJRELocales needs to be volatile for this DCL pattern to be correct. Thanks, David On 6/10/2011 9:02 PM, Chris Hegarty wrote: > I see several exceptions, similar to the following (numbers vary): > > Exception in thread "Thread-23" > java.util.ConcurrentModificationException: Expected: 96, got: 156 > at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) > at java.util.ArrayList$Itr.next(ArrayList.java:791) > at java.util.AbstractCollection.addAll(AbstractCollection.java:333) > at java.util.HashSet.(HashSet.java:117) > at > sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) > > at Interrupter$TestThread.run(Interrupter.java:49) > > There would appear to be 156 JRE Locales ( at least on this system ), > modCount is incremented for each add(), but when the iterator is created > ( implicitly during the HastSet.addAll ) it sees a different value for > modCount. > > I think there is a visibility issue here. availableJRELocales is > volatile, but the List reference returned from getJRELocales is not. In > the case where availableJRELocales is not null there will be no memory > barrier to force a HB relationship. Or maybe I've gotten this wrong? His > is quite bizarre, or maybe it is just the overly complicated use of > locking/DCL in this class. > > -Chris. > > On 10/ 5/11 07:01 PM, David Holmes wrote: >> This might not be related to the CME problem, but here: >> >> public static LocaleServiceProviderPool getPool(Class> LocaleServiceProvider> providerClass) { >> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >> if (pool == null) { >> LocaleServiceProviderPool newPool = >> new LocaleServiceProviderPool(providerClass); >> pool = poolOfPools.put(providerClass, newPool); >> if (pool == null) { >> pool = newPool; >> } >> } >> >> return pool; >> } >> >> we should probably be using poolOfPools.putIfAbsent(providerClass, >> newPool) >> >> David >> >> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>> I will look into this. Reopened the original CR. >>> >>> Naoto >>> >>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>> Chris Hegarty wrote: >>>>> Alan, Naoto, David >>>>> >>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>> intermittently. >>>>> >>>>> If you're ok with it please review the patch (below) and I can push it >>>>> to the tl repo. Job done! >>>> I assume there is also some underlying issue in the Locale code and >>>> this >>>> might get hidden if we fix the test (I"ve no objection to fixing the >>>> test of course, just thinking that we should study the Locale code to >>>> try to identify the deadlock or hang or whatever it is that is causing >>>> the threads in this test not to terminate). >>>> >>>> -Alan >>> From chris.hegarty at oracle.com Thu Oct 6 17:19:24 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Oct 2011 18:19:24 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java Message-ID: D'oh! I should have seen this. Thanks David -Chris David Holmes wrote: >Hi Chris, > >Thanks. Here's the bug: > > private List getJRELocales() { > if (availableJRELocales == null) { > synchronized (LocaleServiceProviderPool.class) { > if (availableJRELocales == null) { > Locale[] allLocales = LocaleData.getAvailableLocales(); > availableJRELocales = new >ArrayList(allLocales.length); <<==== YIKES we just published an >empty ArrayList > for (Locale locale : allLocales) { > availableJRELocales.add(getLookupLocale(locale)); > } > } > } > } > return availableJRELocales; > } > > >availableJRELocales is a static variable shared across all pools. But it >is being published before it gets populated. We need to use a temporary >for the new ArrayList and only assign to availableJRELocales after it is >populated. > >In addition, as you mentioned, availableJRELocales needs to be volatile >for this DCL pattern to be correct. > >Thanks, >David > >On 6/10/2011 9:02 PM, Chris Hegarty wrote: >> I see several exceptions, similar to the following (numbers vary): >> >> Exception in thread "Thread-23" >> java.util.ConcurrentModificationException: Expected: 96, got: 156 >> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >> at java.util.ArrayList$Itr.next(ArrayList.java:791) >> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >> at java.util.HashSet.(HashSet.java:117) >> at >> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >> >> at Interrupter$TestThread.run(Interrupter.java:49) > > >> >> There would appear to be 156 JRE Locales ( at least on this system ), >> modCount is incremented for each add(), but when the iterator is created >> ( implicitly during the HastSet.addAll ) it sees a different value for >> modCount. >> >> I think there is a visibility issue here. availableJRELocales is >> volatile, but the List reference returned from getJRELocales is not. In >> the case where availableJRELocales is not null there will be no memory >> barrier to force a HB relationship. Or maybe I've gotten this wrong? His >> is quite bizarre, or maybe it is just the overly complicated use of >> locking/DCL in this class. >> >> -Chris. >> >> On 10/ 5/11 07:01 PM, David Holmes wrote: >>> This might not be related to the CME problem, but here: >>> >>> public static LocaleServiceProviderPool getPool(Class>> LocaleServiceProvider> providerClass) { >>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>> if (pool == null) { >>> LocaleServiceProviderPool newPool = >>> new LocaleServiceProviderPool(providerClass); >>> pool = poolOfPools.put(providerClass, newPool); >>> if (pool == null) { >>> pool = newPool; >>> } >>> } >>> >>> return pool; >>> } >>> >>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>> newPool) >>> >>> David >>> >>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>> I will look into this. Reopened the original CR. >>>> >>>> Naoto >>>> >>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>> Chris Hegarty wrote: >>>>>> Alan, Naoto, David >>>>>> >>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>> intermittently. >>>>>> >>>>>> If you're ok with it please review the patch (below) and I can push it >>>>>> to the tl repo. Job done! >>>>> I assume there is also some underlying issue in the Locale code and >>>>> this >>>>> might get hidden if we fix the test (I"ve no objection to fixing the >>>>> test of course, just thinking that we should study the Locale code to >>>>> try to identify the deadlock or hang or whatever it is that is causing >>>>> the threads in this test not to terminate). >>>>> >>>>> -Alan >>>> From maurizio.cimadamore at oracle.com Thu Oct 6 17:46:10 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 06 Oct 2011 17:46:10 +0000 Subject: hg: jdk8/tl/langtools: 7090499: missing rawtypes warnings in anonymous inner class Message-ID: <20111006174614.CE47A47C4A@hg.openjdk.java.net> Changeset: 47147081d5b4 Author: mcimadamore Date: 2011-10-06 18:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/47147081d5b4 7090499: missing rawtypes warnings in anonymous inner class Summary: javac does not detect raw types inside anonymous inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/warnings/7090499/T7090499.java + test/tools/javac/warnings/7090499/T7090499.out From naoto.sato at oracle.com Thu Oct 6 21:59:33 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 06 Oct 2011 14:59:33 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8DE0CD.3080401@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> Message-ID: <4E8E24C5.9090402@oracle.com> Hi David, Thank you for the quick look and the fix! Naoto On 10/6/11 10:09 AM, David Holmes wrote: > Hi Chris, > > Thanks. Here's the bug: > > private List getJRELocales() { > if (availableJRELocales == null) { > synchronized (LocaleServiceProviderPool.class) { > if (availableJRELocales == null) { > Locale[] allLocales = LocaleData.getAvailableLocales(); > availableJRELocales = new ArrayList(allLocales.length); <<==== > YIKES we just published an empty ArrayList > for (Locale locale : allLocales) { > availableJRELocales.add(getLookupLocale(locale)); > } > } > } > } > return availableJRELocales; > } > > > availableJRELocales is a static variable shared across all pools. But it > is being published before it gets populated. We need to use a temporary > for the new ArrayList and only assign to availableJRELocales after it is > populated. > > In addition, as you mentioned, availableJRELocales needs to be volatile > for this DCL pattern to be correct. > > Thanks, > David > > On 6/10/2011 9:02 PM, Chris Hegarty wrote: >> I see several exceptions, similar to the following (numbers vary): >> >> Exception in thread "Thread-23" >> java.util.ConcurrentModificationException: Expected: 96, got: 156 >> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >> at java.util.ArrayList$Itr.next(ArrayList.java:791) >> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >> at java.util.HashSet.(HashSet.java:117) >> at >> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >> >> >> at Interrupter$TestThread.run(Interrupter.java:49) > > >> >> There would appear to be 156 JRE Locales ( at least on this system ), >> modCount is incremented for each add(), but when the iterator is created >> ( implicitly during the HastSet.addAll ) it sees a different value for >> modCount. >> >> I think there is a visibility issue here. availableJRELocales is >> volatile, but the List reference returned from getJRELocales is not. In >> the case where availableJRELocales is not null there will be no memory >> barrier to force a HB relationship. Or maybe I've gotten this wrong? His >> is quite bizarre, or maybe it is just the overly complicated use of >> locking/DCL in this class. >> >> -Chris. >> >> On 10/ 5/11 07:01 PM, David Holmes wrote: >>> This might not be related to the CME problem, but here: >>> >>> public static LocaleServiceProviderPool getPool(Class>> LocaleServiceProvider> providerClass) { >>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>> if (pool == null) { >>> LocaleServiceProviderPool newPool = >>> new LocaleServiceProviderPool(providerClass); >>> pool = poolOfPools.put(providerClass, newPool); >>> if (pool == null) { >>> pool = newPool; >>> } >>> } >>> >>> return pool; >>> } >>> >>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>> newPool) >>> >>> David >>> >>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>> I will look into this. Reopened the original CR. >>>> >>>> Naoto >>>> >>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>> Chris Hegarty wrote: >>>>>> Alan, Naoto, David >>>>>> >>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>> intermittently. >>>>>> >>>>>> If you're ok with it please review the patch (below) and I can >>>>>> push it >>>>>> to the tl repo. Job done! >>>>> I assume there is also some underlying issue in the Locale code and >>>>> this >>>>> might get hidden if we fix the test (I"ve no objection to fixing the >>>>> test of course, just thinking that we should study the Locale code to >>>>> try to identify the deadlock or hang or whatever it is that is causing >>>>> the threads in this test not to terminate). >>>>> >>>>> -Alan >>>> From naoto.sato at oracle.com Fri Oct 7 02:45:19 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 07 Oct 2011 02:45:19 +0000 Subject: hg: jdk8/tl/jdk: 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Message-ID: <20111007024537.1905447C70@hg.openjdk.java.net> Changeset: b8a1d30d6c65 Author: naoto Date: 2011-10-06 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8a1d30d6c65 7098394: JDK8 TL repo build fails in src/solaris/native/java/util/TimeZone_md.c Reviewed-by: chegar ! src/solaris/native/java/util/TimeZone_md.c From vincent.x.ryan at oracle.com Fri Oct 7 13:11:07 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 07 Oct 2011 13:11:07 +0000 Subject: hg: jdk8/tl/jdk: 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Message-ID: <20111007131128.B236947CAB@hg.openjdk.java.net> Changeset: 2edaef22de23 Author: vinnie Date: 2011-10-07 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2edaef22de23 7094377: Com.sun.jndi.ldap.read.timeout doesn't work with ldaps. Reviewed-by: chegar ! src/share/classes/com/sun/jndi/ldap/Connection.java + test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java From chris.hegarty at oracle.com Fri Oct 7 15:00:12 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 07 Oct 2011 16:00:12 +0100 Subject: Code Review 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Message-ID: <4E8F13FC.60801@oracle.com> Since the integration of the fix for CR 7094141, it has come to light that the test should be using the supported compiler interface, com.sun.tools.javac.Main. CR 7094141 was a little rushed so that the failing test would not prevent TL integration into the MASTER repo. There should be less issues with this test going forward after this change. hg diff sun/misc/JarIndex/metaInfFilenames/Basic.java diff -r 24741fe639a8 test/sun/misc/JarIndex/metaInfFilenames/Basic.java --- a/test/sun/misc/JarIndex/metaInfFilenames/Basic.java Tue Oct 04 16:37:08 2011 +0100 +++ b/test/sun/misc/JarIndex/metaInfFilenames/Basic.java Fri Oct 07 15:50:18 2011 +0100 @@ -154,8 +154,8 @@ public class Basic { /* run javac */ static void compile(String... args) { debug("Running: javac " + Arrays.toString(args)); - com.sun.tools.javac.main.Main compiler = new com.sun.tools.javac.main.Main("javac"); - if (compiler.compile(args) != com.sun.tools.javac.main.Main.Result.OK) { + com.sun.tools.javac.Main compiler = new com.sun.tools.javac.Main(); + if (compiler.compile(args) != 0) { throw new RuntimeException("javac failed: args=" + Arrays.toString(args)); } } -Chris. From naoto.sato at oracle.com Fri Oct 7 18:40:31 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 07 Oct 2011 11:40:31 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8E24C5.9090402@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> Message-ID: <4E8F479F.6070301@oracle.com> OK here is the proposed fix (including David's suggestion for using putIfAbsent). Can anyone please review this? --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java @@ -40,6 +40,7 @@ import java.util.ServiceLoader; import java.util.Set; import java.util.concurrent.ConcurrentHashMap; +import java.util.concurrent.ConcurrentMap; import java.util.spi.LocaleServiceProvider; import sun.util.logging.PlatformLogger; @@ -57,8 +58,8 @@ * A Map that holds singleton instances of this class. Each instance holds a * set of provider implementations of a particular locale sensitive service. */ - private static Map poolOfPools = - new ConcurrentHashMap(); + private static ConcurrentMap poolOfPools = + new ConcurrentHashMap<>(); /** * A Set containing locale service providers that implement the @@ -109,7 +110,7 @@ if (pool == null) { LocaleServiceProviderPool newPool = new LocaleServiceProviderPool(providerClass); - pool = poolOfPools.put(providerClass, newPool); + pool = poolOfPools.putIfAbsent(providerClass, newPool); if (pool == null) { pool = newPool; } @@ -257,10 +258,11 @@ synchronized (LocaleServiceProviderPool.class) { if (availableJRELocales == null) { Locale[] allLocales = LocaleData.getAvailableLocales(); - availableJRELocales = new ArrayList(allLocales.length); + List tmpList = new ArrayList<>(allLocales.length); for (Locale locale : allLocales) { - availableJRELocales.add(getLookupLocale(locale)); + tmpList.add(getLookupLocale(locale)); } + availableJRELocales = tmpList; } } } --- Naoto On 10/6/11 2:59 PM, Naoto Sato wrote: > Hi David, > > Thank you for the quick look and the fix! > > Naoto > > On 10/6/11 10:09 AM, David Holmes wrote: >> Hi Chris, >> >> Thanks. Here's the bug: >> >> private List getJRELocales() { >> if (availableJRELocales == null) { >> synchronized (LocaleServiceProviderPool.class) { >> if (availableJRELocales == null) { >> Locale[] allLocales = LocaleData.getAvailableLocales(); >> availableJRELocales = new ArrayList(allLocales.length); <<==== >> YIKES we just published an empty ArrayList >> for (Locale locale : allLocales) { >> availableJRELocales.add(getLookupLocale(locale)); >> } >> } >> } >> } >> return availableJRELocales; >> } >> >> >> availableJRELocales is a static variable shared across all pools. But it >> is being published before it gets populated. We need to use a temporary >> for the new ArrayList and only assign to availableJRELocales after it is >> populated. >> >> In addition, as you mentioned, availableJRELocales needs to be volatile >> for this DCL pattern to be correct. >> >> Thanks, >> David >> >> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>> I see several exceptions, similar to the following (numbers vary): >>> >>> Exception in thread "Thread-23" >>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>> at java.util.HashSet.(HashSet.java:117) >>> at >>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>> >>> >>> >>> at Interrupter$TestThread.run(Interrupter.java:49) >> >> >>> >>> There would appear to be 156 JRE Locales ( at least on this system ), >>> modCount is incremented for each add(), but when the iterator is created >>> ( implicitly during the HastSet.addAll ) it sees a different value for >>> modCount. >>> >>> I think there is a visibility issue here. availableJRELocales is >>> volatile, but the List reference returned from getJRELocales is not. In >>> the case where availableJRELocales is not null there will be no memory >>> barrier to force a HB relationship. Or maybe I've gotten this wrong? His >>> is quite bizarre, or maybe it is just the overly complicated use of >>> locking/DCL in this class. >>> >>> -Chris. >>> >>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>> This might not be related to the CME problem, but here: >>>> >>>> public static LocaleServiceProviderPool getPool(Class>>> LocaleServiceProvider> providerClass) { >>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>> if (pool == null) { >>>> LocaleServiceProviderPool newPool = >>>> new LocaleServiceProviderPool(providerClass); >>>> pool = poolOfPools.put(providerClass, newPool); >>>> if (pool == null) { >>>> pool = newPool; >>>> } >>>> } >>>> >>>> return pool; >>>> } >>>> >>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>> newPool) >>>> >>>> David >>>> >>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>> I will look into this. Reopened the original CR. >>>>> >>>>> Naoto >>>>> >>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>> Chris Hegarty wrote: >>>>>>> Alan, Naoto, David >>>>>>> >>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>> intermittently. >>>>>>> >>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>> push it >>>>>>> to the tl repo. Job done! >>>>>> I assume there is also some underlying issue in the Locale code and >>>>>> this >>>>>> might get hidden if we fix the test (I"ve no objection to fixing the >>>>>> test of course, just thinking that we should study the Locale code to >>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>> causing >>>>>> the threads in this test not to terminate). >>>>>> >>>>>> -Alan >>>>> > From mike.skells at talk21.com Sun Oct 9 22:00:40 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Sun, 9 Oct 2011 23:00:40 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> Message-ID: <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> Hi All, It has always?irritated?me that they create so many temporary objects. The patch reduces the number of StringBuilders that are created (originally 2 for each stack trace element) The patch reuses the StringBuilder and only sends text to the underlying stream for every line.? It could be optimised to run faster by sending updates of more than one line but that would change the memory footprint so this seemed a good compromise. I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) Regards Mike -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TestThrow.java URL: From Alan.Bateman at oracle.com Sun Oct 9 23:15:58 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Oct 2011 00:15:58 +0100 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> Message-ID: <4E922B2E.60701@oracle.com> mike.skells at talk21.com wrote: > : > > > I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) > Mike - I don't think there is a patch attached to your mail. From david.holmes at oracle.com Mon Oct 10 01:22:44 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Oct 2011 11:22:44 +1000 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E8F479F.6070301@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> Message-ID: <4E9248E4.3040509@oracle.com> Hi Naoto, This looks okay to me, but is missing the change to make availableJRELocales volatile (which is needed to ensure safe publication) David On 8/10/2011 4:40 AM, Naoto Sato wrote: > OK here is the proposed fix (including David's suggestion for using > putIfAbsent). Can anyone please review this? > > --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java > +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java > @@ -40,6 +40,7 @@ > import java.util.ServiceLoader; > import java.util.Set; > import java.util.concurrent.ConcurrentHashMap; > +import java.util.concurrent.ConcurrentMap; > import java.util.spi.LocaleServiceProvider; > > import sun.util.logging.PlatformLogger; > @@ -57,8 +58,8 @@ > * A Map that holds singleton instances of this class. Each instance holds a > * set of provider implementations of a particular locale sensitive service. > */ > - private static Map poolOfPools = > - new ConcurrentHashMap(); > + private static ConcurrentMap > poolOfPools = > + new ConcurrentHashMap<>(); > > /** > * A Set containing locale service providers that implement the > @@ -109,7 +110,7 @@ > if (pool == null) { > LocaleServiceProviderPool newPool = > new LocaleServiceProviderPool(providerClass); > - pool = poolOfPools.put(providerClass, newPool); > + pool = poolOfPools.putIfAbsent(providerClass, newPool); > if (pool == null) { > pool = newPool; > } > @@ -257,10 +258,11 @@ > synchronized (LocaleServiceProviderPool.class) { > if (availableJRELocales == null) { > Locale[] allLocales = LocaleData.getAvailableLocales(); > - availableJRELocales = new ArrayList(allLocales.length); > + List tmpList = new ArrayList<>(allLocales.length); > for (Locale locale : allLocales) { > - availableJRELocales.add(getLookupLocale(locale)); > + tmpList.add(getLookupLocale(locale)); > } > + availableJRELocales = tmpList; > } > } > } > --- > > Naoto > > On 10/6/11 2:59 PM, Naoto Sato wrote: >> Hi David, >> >> Thank you for the quick look and the fix! >> >> Naoto >> >> On 10/6/11 10:09 AM, David Holmes wrote: >>> Hi Chris, >>> >>> Thanks. Here's the bug: >>> >>> private List getJRELocales() { >>> if (availableJRELocales == null) { >>> synchronized (LocaleServiceProviderPool.class) { >>> if (availableJRELocales == null) { >>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>> availableJRELocales = new ArrayList(allLocales.length); <<==== >>> YIKES we just published an empty ArrayList >>> for (Locale locale : allLocales) { >>> availableJRELocales.add(getLookupLocale(locale)); >>> } >>> } >>> } >>> } >>> return availableJRELocales; >>> } >>> >>> >>> availableJRELocales is a static variable shared across all pools. But it >>> is being published before it gets populated. We need to use a temporary >>> for the new ArrayList and only assign to availableJRELocales after it is >>> populated. >>> >>> In addition, as you mentioned, availableJRELocales needs to be volatile >>> for this DCL pattern to be correct. >>> >>> Thanks, >>> David >>> >>> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>>> I see several exceptions, similar to the following (numbers vary): >>>> >>>> Exception in thread "Thread-23" >>>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>>> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>>> at java.util.HashSet.(HashSet.java:117) >>>> at >>>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>>> >>>> >>>> >>>> >>>> at Interrupter$TestThread.run(Interrupter.java:49) >>> >>> >>>> >>>> There would appear to be 156 JRE Locales ( at least on this system ), >>>> modCount is incremented for each add(), but when the iterator is >>>> created >>>> ( implicitly during the HastSet.addAll ) it sees a different value for >>>> modCount. >>>> >>>> I think there is a visibility issue here. availableJRELocales is >>>> volatile, but the List reference returned from getJRELocales is not. In >>>> the case where availableJRELocales is not null there will be no memory >>>> barrier to force a HB relationship. Or maybe I've gotten this wrong? >>>> His >>>> is quite bizarre, or maybe it is just the overly complicated use of >>>> locking/DCL in this class. >>>> >>>> -Chris. >>>> >>>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>>> This might not be related to the CME problem, but here: >>>>> >>>>> public static LocaleServiceProviderPool getPool(Class>>>> LocaleServiceProvider> providerClass) { >>>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>>> if (pool == null) { >>>>> LocaleServiceProviderPool newPool = >>>>> new LocaleServiceProviderPool(providerClass); >>>>> pool = poolOfPools.put(providerClass, newPool); >>>>> if (pool == null) { >>>>> pool = newPool; >>>>> } >>>>> } >>>>> >>>>> return pool; >>>>> } >>>>> >>>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>>> newPool) >>>>> >>>>> David >>>>> >>>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>>> I will look into this. Reopened the original CR. >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>>> Chris Hegarty wrote: >>>>>>>> Alan, Naoto, David >>>>>>>> >>>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>>> intermittently. >>>>>>>> >>>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>>> push it >>>>>>>> to the tl repo. Job done! >>>>>>> I assume there is also some underlying issue in the Locale code and >>>>>>> this >>>>>>> might get hidden if we fix the test (I"ve no objection to fixing the >>>>>>> test of course, just thinking that we should study the Locale >>>>>>> code to >>>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>>> causing >>>>>>> the threads in this test not to terminate). >>>>>>> >>>>>>> -Alan >>>>>> >> > From naoto.sato at oracle.com Mon Oct 10 03:35:49 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Sun, 09 Oct 2011 20:35:49 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E9248E4.3040509@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> Message-ID: <4E926815.7020808@oracle.com> Hi David, Thank you for your review. availableJRELocales is already declared with volatile keyword in the current source, so no change is involved. Naoto On 10/9/11 6:22 PM, David Holmes wrote: > Hi Naoto, > > This looks okay to me, but is missing the change to make > availableJRELocales volatile (which is needed to ensure safe publication) > > David > > On 8/10/2011 4:40 AM, Naoto Sato wrote: >> OK here is the proposed fix (including David's suggestion for using >> putIfAbsent). Can anyone please review this? >> >> --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java >> +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java >> @@ -40,6 +40,7 @@ >> import java.util.ServiceLoader; >> import java.util.Set; >> import java.util.concurrent.ConcurrentHashMap; >> +import java.util.concurrent.ConcurrentMap; >> import java.util.spi.LocaleServiceProvider; >> >> import sun.util.logging.PlatformLogger; >> @@ -57,8 +58,8 @@ >> * A Map that holds singleton instances of this class. Each instance >> holds a >> * set of provider implementations of a particular locale sensitive >> service. >> */ >> - private static Map poolOfPools = >> - new ConcurrentHashMap(); >> + private static ConcurrentMap >> poolOfPools = >> + new ConcurrentHashMap<>(); >> >> /** >> * A Set containing locale service providers that implement the >> @@ -109,7 +110,7 @@ >> if (pool == null) { >> LocaleServiceProviderPool newPool = >> new LocaleServiceProviderPool(providerClass); >> - pool = poolOfPools.put(providerClass, newPool); >> + pool = poolOfPools.putIfAbsent(providerClass, newPool); >> if (pool == null) { >> pool = newPool; >> } >> @@ -257,10 +258,11 @@ >> synchronized (LocaleServiceProviderPool.class) { >> if (availableJRELocales == null) { >> Locale[] allLocales = LocaleData.getAvailableLocales(); >> - availableJRELocales = new ArrayList(allLocales.length); >> + List tmpList = new ArrayList<>(allLocales.length); >> for (Locale locale : allLocales) { >> - availableJRELocales.add(getLookupLocale(locale)); >> + tmpList.add(getLookupLocale(locale)); >> } >> + availableJRELocales = tmpList; >> } >> } >> } >> --- >> >> Naoto >> >> On 10/6/11 2:59 PM, Naoto Sato wrote: >>> Hi David, >>> >>> Thank you for the quick look and the fix! >>> >>> Naoto >>> >>> On 10/6/11 10:09 AM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> Thanks. Here's the bug: >>>> >>>> private List getJRELocales() { >>>> if (availableJRELocales == null) { >>>> synchronized (LocaleServiceProviderPool.class) { >>>> if (availableJRELocales == null) { >>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>> availableJRELocales = new ArrayList(allLocales.length); <<==== >>>> YIKES we just published an empty ArrayList >>>> for (Locale locale : allLocales) { >>>> availableJRELocales.add(getLookupLocale(locale)); >>>> } >>>> } >>>> } >>>> } >>>> return availableJRELocales; >>>> } >>>> >>>> >>>> availableJRELocales is a static variable shared across all pools. >>>> But it >>>> is being published before it gets populated. We need to use a temporary >>>> for the new ArrayList and only assign to availableJRELocales after >>>> it is >>>> populated. >>>> >>>> In addition, as you mentioned, availableJRELocales needs to be volatile >>>> for this DCL pattern to be correct. >>>> >>>> Thanks, >>>> David >>>> >>>> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>>>> I see several exceptions, similar to the following (numbers vary): >>>>> >>>>> Exception in thread "Thread-23" >>>>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>>>> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>>>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>>>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>>>> at java.util.HashSet.(HashSet.java:117) >>>>> at >>>>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> at Interrupter$TestThread.run(Interrupter.java:49) >>>> >>>> >>>>> >>>>> There would appear to be 156 JRE Locales ( at least on this system ), >>>>> modCount is incremented for each add(), but when the iterator is >>>>> created >>>>> ( implicitly during the HastSet.addAll ) it sees a different value for >>>>> modCount. >>>>> >>>>> I think there is a visibility issue here. availableJRELocales is >>>>> volatile, but the List reference returned from getJRELocales is >>>>> not. In >>>>> the case where availableJRELocales is not null there will be no memory >>>>> barrier to force a HB relationship. Or maybe I've gotten this wrong? >>>>> His >>>>> is quite bizarre, or maybe it is just the overly complicated use of >>>>> locking/DCL in this class. >>>>> >>>>> -Chris. >>>>> >>>>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>>>> This might not be related to the CME problem, but here: >>>>>> >>>>>> public static LocaleServiceProviderPool getPool(Class>>>>> LocaleServiceProvider> providerClass) { >>>>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>>>> if (pool == null) { >>>>>> LocaleServiceProviderPool newPool = >>>>>> new LocaleServiceProviderPool(providerClass); >>>>>> pool = poolOfPools.put(providerClass, newPool); >>>>>> if (pool == null) { >>>>>> pool = newPool; >>>>>> } >>>>>> } >>>>>> >>>>>> return pool; >>>>>> } >>>>>> >>>>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>>>> newPool) >>>>>> >>>>>> David >>>>>> >>>>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>>>> I will look into this. Reopened the original CR. >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>>>> Chris Hegarty wrote: >>>>>>>>> Alan, Naoto, David >>>>>>>>> >>>>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>>>> intermittently. >>>>>>>>> >>>>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>>>> push it >>>>>>>>> to the tl repo. Job done! >>>>>>>> I assume there is also some underlying issue in the Locale code and >>>>>>>> this >>>>>>>> might get hidden if we fix the test (I"ve no objection to fixing >>>>>>>> the >>>>>>>> test of course, just thinking that we should study the Locale >>>>>>>> code to >>>>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>>>> causing >>>>>>>> the threads in this test not to terminate). >>>>>>>> >>>>>>>> -Alan >>>>>>> >>> >> From david.holmes at oracle.com Mon Oct 10 04:44:03 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Oct 2011 14:44:03 +1000 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E926815.7020808@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> Message-ID: <4E927813.1000900@oracle.com> On 10/10/2011 1:35 PM, Naoto Sato wrote: > Hi David, > > Thank you for your review. availableJRELocales is already declared with > volatile keyword in the current source, so no change is involved. Sorry - my mistake. I misread something Chris posted earlier. Cheers, David > Naoto > > On 10/9/11 6:22 PM, David Holmes wrote: >> Hi Naoto, >> >> This looks okay to me, but is missing the change to make >> availableJRELocales volatile (which is needed to ensure safe publication) >> >> David >> >> On 8/10/2011 4:40 AM, Naoto Sato wrote: >>> OK here is the proposed fix (including David's suggestion for using >>> putIfAbsent). Can anyone please review this? >>> >>> --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java >>> +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java >>> @@ -40,6 +40,7 @@ >>> import java.util.ServiceLoader; >>> import java.util.Set; >>> import java.util.concurrent.ConcurrentHashMap; >>> +import java.util.concurrent.ConcurrentMap; >>> import java.util.spi.LocaleServiceProvider; >>> >>> import sun.util.logging.PlatformLogger; >>> @@ -57,8 +58,8 @@ >>> * A Map that holds singleton instances of this class. Each instance >>> holds a >>> * set of provider implementations of a particular locale sensitive >>> service. >>> */ >>> - private static Map poolOfPools = >>> - new ConcurrentHashMap(); >>> + private static ConcurrentMap >>> poolOfPools = >>> + new ConcurrentHashMap<>(); >>> >>> /** >>> * A Set containing locale service providers that implement the >>> @@ -109,7 +110,7 @@ >>> if (pool == null) { >>> LocaleServiceProviderPool newPool = >>> new LocaleServiceProviderPool(providerClass); >>> - pool = poolOfPools.put(providerClass, newPool); >>> + pool = poolOfPools.putIfAbsent(providerClass, newPool); >>> if (pool == null) { >>> pool = newPool; >>> } >>> @@ -257,10 +258,11 @@ >>> synchronized (LocaleServiceProviderPool.class) { >>> if (availableJRELocales == null) { >>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>> - availableJRELocales = new ArrayList(allLocales.length); >>> + List tmpList = new ArrayList<>(allLocales.length); >>> for (Locale locale : allLocales) { >>> - availableJRELocales.add(getLookupLocale(locale)); >>> + tmpList.add(getLookupLocale(locale)); >>> } >>> + availableJRELocales = tmpList; >>> } >>> } >>> } >>> --- >>> >>> Naoto >>> >>> On 10/6/11 2:59 PM, Naoto Sato wrote: >>>> Hi David, >>>> >>>> Thank you for the quick look and the fix! >>>> >>>> Naoto >>>> >>>> On 10/6/11 10:09 AM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> Thanks. Here's the bug: >>>>> >>>>> private List getJRELocales() { >>>>> if (availableJRELocales == null) { >>>>> synchronized (LocaleServiceProviderPool.class) { >>>>> if (availableJRELocales == null) { >>>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>>> availableJRELocales = new ArrayList(allLocales.length); <<==== >>>>> YIKES we just published an empty ArrayList >>>>> for (Locale locale : allLocales) { >>>>> availableJRELocales.add(getLookupLocale(locale)); >>>>> } >>>>> } >>>>> } >>>>> } >>>>> return availableJRELocales; >>>>> } >>>>> >>>>> >>>>> availableJRELocales is a static variable shared across all pools. >>>>> But it >>>>> is being published before it gets populated. We need to use a >>>>> temporary >>>>> for the new ArrayList and only assign to availableJRELocales after >>>>> it is >>>>> populated. >>>>> >>>>> In addition, as you mentioned, availableJRELocales needs to be >>>>> volatile >>>>> for this DCL pattern to be correct. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>>>>> I see several exceptions, similar to the following (numbers vary): >>>>>> >>>>>> Exception in thread "Thread-23" >>>>>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>>>>> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>>>>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>>>>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>>>>> at java.util.HashSet.(HashSet.java:117) >>>>>> at >>>>>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> at Interrupter$TestThread.run(Interrupter.java:49) >>>>> >>>>> >>>>>> >>>>>> There would appear to be 156 JRE Locales ( at least on this system ), >>>>>> modCount is incremented for each add(), but when the iterator is >>>>>> created >>>>>> ( implicitly during the HastSet.addAll ) it sees a different value >>>>>> for >>>>>> modCount. >>>>>> >>>>>> I think there is a visibility issue here. availableJRELocales is >>>>>> volatile, but the List reference returned from getJRELocales is >>>>>> not. In >>>>>> the case where availableJRELocales is not null there will be no >>>>>> memory >>>>>> barrier to force a HB relationship. Or maybe I've gotten this wrong? >>>>>> His >>>>>> is quite bizarre, or maybe it is just the overly complicated use of >>>>>> locking/DCL in this class. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>>>>> This might not be related to the CME problem, but here: >>>>>>> >>>>>>> public static LocaleServiceProviderPool getPool(Class>>>>>> LocaleServiceProvider> providerClass) { >>>>>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>>>>> if (pool == null) { >>>>>>> LocaleServiceProviderPool newPool = >>>>>>> new LocaleServiceProviderPool(providerClass); >>>>>>> pool = poolOfPools.put(providerClass, newPool); >>>>>>> if (pool == null) { >>>>>>> pool = newPool; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> return pool; >>>>>>> } >>>>>>> >>>>>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>>>>> newPool) >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>>>>> I will look into this. Reopened the original CR. >>>>>>>> >>>>>>>> Naoto >>>>>>>> >>>>>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>>>>> Chris Hegarty wrote: >>>>>>>>>> Alan, Naoto, David >>>>>>>>>> >>>>>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>>>>> intermittently. >>>>>>>>>> >>>>>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>>>>> push it >>>>>>>>>> to the tl repo. Job done! >>>>>>>>> I assume there is also some underlying issue in the Locale code >>>>>>>>> and >>>>>>>>> this >>>>>>>>> might get hidden if we fix the test (I"ve no objection to fixing >>>>>>>>> the >>>>>>>>> test of course, just thinking that we should study the Locale >>>>>>>>> code to >>>>>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>>>>> causing >>>>>>>>> the threads in this test not to terminate). >>>>>>>>> >>>>>>>>> -Alan >>>>>>>> >>>> >>> > From mike.skells at talk21.com Mon Oct 10 07:53:50 2011 From: mike.skells at talk21.com (Mike Skells) Date: Mon, 10 Oct 2011 08:53:50 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E922B2E.60701@oracle.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> Message-ID: <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> Doh, This time with the patches, test code, and CPU usage stats attached Regard Mike? >________________________________ >From: Alan Bateman >To: mike.skells at talk21.com >Cc: Core-Libs-Dev >Sent: Monday, 10 October 2011, 0:15 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > >mike.skells at talk21.com wrote: >> : >> >> >> I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) >>? >Mike - I don't think there is a patch attached to your mail. > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TestThrow.java URL: From mike.skells at talk21.com Mon Oct 10 08:17:47 2011 From: mike.skells at talk21.com (Mike Skells) Date: Mon, 10 Oct 2011 09:17:47 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> Message-ID: <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> The patch (.patch) and results (.xlsx) seem to be filtered out. What is the best format to submit files to avoid list filtering attachments? >________________________________ >From: Mike Skells >To: Alan Bateman >Cc: Core-Libs-Dev >Sent: Monday, 10 October 2011, 8:53 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > >Doh, >This time with the patches, test code, and CPU usage stats attached > >Regard > >Mike? > > > >>________________________________ >>From: Alan Bateman >>To: mike.skells at talk21.com >>Cc: Core-Libs-Dev >>Sent: Monday, 10 October 2011, 0:15 >>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >> >>mike.skells at talk21.com wrote: >>> : >>> >>> >>> I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) >>>? >>Mike - I don't think there is a patch attached to your mail. >> >> >> > > From chris.hegarty at oracle.com Mon Oct 10 10:04:11 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 10 Oct 2011 10:04:11 +0000 Subject: hg: jdk8/tl/jdk: 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Message-ID: <20111010100435.6866047E2C@hg.openjdk.java.net> Changeset: 1e89a13d9d8f Author: chegar Date: 2011-10-10 10:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e89a13d9d8f 7098719: -Dsun.net.maxDatagramSockets and Socket constructor does not work correctly with System.gc() Reviewed-by: michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java From spoole at linux.vnet.ibm.com Mon Oct 10 12:58:13 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 10 Oct 2011 13:58:13 +0100 Subject: Request for review - removal of unused dlinfo variable in java_md.c Message-ID: <1318251493.17552.6.camel@jazzette> hi all, Please find attached a trivial patch to remove an unused variable in jdk/src/solaris/bin/java_md.c The present of the variable causes the AIX build to fail since Dl_info is not supported on AIX. The other use of Dl_info in the file is safely wrapped with an #if defined(__solaris__) I have built with the change successfully on AIX and Linux. Cheers Steve -------------- next part -------------- # HG changeset patch # User Steve Poole # Date 1318250829 -3600 # Node ID bf46fe8768c71a47d8fee9b784653b6f0eb971f6 # Parent f1ec21b8142168ff40f3278d2f6b5fe4bd5f3b26 Remove unused dlinfo variable. (fails to build on AIX) diff -r f1ec21b81421 -r bf46fe8768c7 src/solaris/bin/java_md.c --- a/src/solaris/bin/java_md.c Thu Oct 06 14:01:37 2011 -0700 +++ b/src/solaris/bin/java_md.c Mon Oct 10 13:47:09 2011 +0100 @@ -820,7 +820,6 @@ jboolean LoadJavaVM(const char *jvmpath, InvocationFunctions *ifn) { - Dl_info dlinfo; void *libjvm; JLI_TraceLauncher("JVM path is %s\n", jvmpath); From maurizio.cimadamore at oracle.com Mon Oct 10 14:02:38 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 10 Oct 2011 15:02:38 +0100 Subject: Code Review 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface In-Reply-To: <4E8F13FC.60801@oracle.com> References: <4E8F13FC.60801@oracle.com> Message-ID: <4E92FAFE.6040203@oracle.com> Approved Maurizio On 07/10/11 16:00, Chris Hegarty wrote: > > Since the integration of the fix for CR 7094141, it has come to light > that the test should be using the supported compiler interface, > com.sun.tools.javac.Main. CR 7094141 was a little rushed so that the > failing test would not prevent TL integration into the MASTER repo. > > There should be less issues with this test going forward after this > change. > > hg diff sun/misc/JarIndex/metaInfFilenames/Basic.java > diff -r 24741fe639a8 test/sun/misc/JarIndex/metaInfFilenames/Basic.java > --- a/test/sun/misc/JarIndex/metaInfFilenames/Basic.java Tue > Oct 04 16:37:08 2011 +0100 > +++ b/test/sun/misc/JarIndex/metaInfFilenames/Basic.java Fri > Oct 07 15:50:18 2011 +0100 > @@ -154,8 +154,8 @@ public class Basic { > /* run javac */ > static void compile(String... args) { > debug("Running: javac " + Arrays.toString(args)); > - com.sun.tools.javac.main.Main compiler = new > com.sun.tools.javac.main.Main("javac"); > - if (compiler.compile(args) != > com.sun.tools.javac.main.Main.Result.OK) { > + com.sun.tools.javac.Main compiler = new > com.sun.tools.javac.Main(); > + if (compiler.compile(args) != 0) { > throw new RuntimeException("javac failed: args=" + > Arrays.toString(args)); > } > } > > > -Chris. From neil.richards at ngmr.net Mon Oct 10 14:12:14 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 10 Oct 2011 15:12:14 +0100 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <1318251493.17552.6.camel@jazzette> References: <1318251493.17552.6.camel@jazzette> Message-ID: <1318255934.7676.2.camel@chalkhill> On Mon, 2011-10-10 at 13:58 +0100, Steve Poole wrote: > hi all, > > Please find attached a trivial patch to remove an unused variable in > jdk/src/solaris/bin/java_md.c > > The present of the variable causes the AIX build to fail since Dl_info > is not supported on AIX. The other use of Dl_info in the file is > safely wrapped with an #if defined(__solaris__) > > I have built with the change successfully on AIX and Linux. > > Cheers > > Steve > > Hi Steve, For ease of review, I've uploaded the suggested patch as a webrev [1]. The change looks good to me. Regards, Neil [1] http://cr.openjdk.java.net/~ngmr/ojdk-228/webrev.00/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Mon Oct 10 14:24:02 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Oct 2011 15:24:02 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E927813.1000900@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> Message-ID: <4E930002.8020704@oracle.com> Thumbs up from me too. -Chris. On 10/10/2011 05:44, David Holmes wrote: > On 10/10/2011 1:35 PM, Naoto Sato wrote: >> Hi David, >> >> Thank you for your review. availableJRELocales is already declared with >> volatile keyword in the current source, so no change is involved. > > Sorry - my mistake. I misread something Chris posted earlier. > > Cheers, > David > >> Naoto >> >> On 10/9/11 6:22 PM, David Holmes wrote: >>> Hi Naoto, >>> >>> This looks okay to me, but is missing the change to make >>> availableJRELocales volatile (which is needed to ensure safe >>> publication) >>> >>> David >>> >>> On 8/10/2011 4:40 AM, Naoto Sato wrote: >>>> OK here is the proposed fix (including David's suggestion for using >>>> putIfAbsent). Can anyone please review this? >>>> >>>> --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java >>>> +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java >>>> @@ -40,6 +40,7 @@ >>>> import java.util.ServiceLoader; >>>> import java.util.Set; >>>> import java.util.concurrent.ConcurrentHashMap; >>>> +import java.util.concurrent.ConcurrentMap; >>>> import java.util.spi.LocaleServiceProvider; >>>> >>>> import sun.util.logging.PlatformLogger; >>>> @@ -57,8 +58,8 @@ >>>> * A Map that holds singleton instances of this class. Each instance >>>> holds a >>>> * set of provider implementations of a particular locale sensitive >>>> service. >>>> */ >>>> - private static Map poolOfPools = >>>> - new ConcurrentHashMap(); >>>> + private static ConcurrentMap >>>> poolOfPools = >>>> + new ConcurrentHashMap<>(); >>>> >>>> /** >>>> * A Set containing locale service providers that implement the >>>> @@ -109,7 +110,7 @@ >>>> if (pool == null) { >>>> LocaleServiceProviderPool newPool = >>>> new LocaleServiceProviderPool(providerClass); >>>> - pool = poolOfPools.put(providerClass, newPool); >>>> + pool = poolOfPools.putIfAbsent(providerClass, newPool); >>>> if (pool == null) { >>>> pool = newPool; >>>> } >>>> @@ -257,10 +258,11 @@ >>>> synchronized (LocaleServiceProviderPool.class) { >>>> if (availableJRELocales == null) { >>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>> - availableJRELocales = new ArrayList(allLocales.length); >>>> + List tmpList = new ArrayList<>(allLocales.length); >>>> for (Locale locale : allLocales) { >>>> - availableJRELocales.add(getLookupLocale(locale)); >>>> + tmpList.add(getLookupLocale(locale)); >>>> } >>>> + availableJRELocales = tmpList; >>>> } >>>> } >>>> } >>>> --- >>>> >>>> Naoto >>>> >>>> On 10/6/11 2:59 PM, Naoto Sato wrote: >>>>> Hi David, >>>>> >>>>> Thank you for the quick look and the fix! >>>>> >>>>> Naoto >>>>> >>>>> On 10/6/11 10:09 AM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> Thanks. Here's the bug: >>>>>> >>>>>> private List getJRELocales() { >>>>>> if (availableJRELocales == null) { >>>>>> synchronized (LocaleServiceProviderPool.class) { >>>>>> if (availableJRELocales == null) { >>>>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>>>> availableJRELocales = new ArrayList(allLocales.length); >>>>>> <<==== >>>>>> YIKES we just published an empty ArrayList >>>>>> for (Locale locale : allLocales) { >>>>>> availableJRELocales.add(getLookupLocale(locale)); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> return availableJRELocales; >>>>>> } >>>>>> >>>>>> >>>>>> availableJRELocales is a static variable shared across all pools. >>>>>> But it >>>>>> is being published before it gets populated. We need to use a >>>>>> temporary >>>>>> for the new ArrayList and only assign to availableJRELocales after >>>>>> it is >>>>>> populated. >>>>>> >>>>>> In addition, as you mentioned, availableJRELocales needs to be >>>>>> volatile >>>>>> for this DCL pattern to be correct. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>>>>>> I see several exceptions, similar to the following (numbers vary): >>>>>>> >>>>>>> Exception in thread "Thread-23" >>>>>>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>>>>>> at >>>>>>> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>>>>>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>>>>>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>>>>>> at java.util.HashSet.(HashSet.java:117) >>>>>>> at >>>>>>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> at Interrupter$TestThread.run(Interrupter.java:49) >>>>>> >>>>>> >>>>>>> >>>>>>> There would appear to be 156 JRE Locales ( at least on this >>>>>>> system ), >>>>>>> modCount is incremented for each add(), but when the iterator is >>>>>>> created >>>>>>> ( implicitly during the HastSet.addAll ) it sees a different value >>>>>>> for >>>>>>> modCount. >>>>>>> >>>>>>> I think there is a visibility issue here. availableJRELocales is >>>>>>> volatile, but the List reference returned from getJRELocales is >>>>>>> not. In >>>>>>> the case where availableJRELocales is not null there will be no >>>>>>> memory >>>>>>> barrier to force a HB relationship. Or maybe I've gotten this wrong? >>>>>>> His >>>>>>> is quite bizarre, or maybe it is just the overly complicated use of >>>>>>> locking/DCL in this class. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>>>>>> This might not be related to the CME problem, but here: >>>>>>>> >>>>>>>> public static LocaleServiceProviderPool getPool(Class>>>>>>> LocaleServiceProvider> providerClass) { >>>>>>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>>>>>> if (pool == null) { >>>>>>>> LocaleServiceProviderPool newPool = >>>>>>>> new LocaleServiceProviderPool(providerClass); >>>>>>>> pool = poolOfPools.put(providerClass, newPool); >>>>>>>> if (pool == null) { >>>>>>>> pool = newPool; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> return pool; >>>>>>>> } >>>>>>>> >>>>>>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>>>>>> newPool) >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>>>>>> I will look into this. Reopened the original CR. >>>>>>>>> >>>>>>>>> Naoto >>>>>>>>> >>>>>>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>>>>>> Chris Hegarty wrote: >>>>>>>>>>> Alan, Naoto, David >>>>>>>>>>> >>>>>>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>>>>>> intermittently. >>>>>>>>>>> >>>>>>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>>>>>> push it >>>>>>>>>>> to the tl repo. Job done! >>>>>>>>>> I assume there is also some underlying issue in the Locale code >>>>>>>>>> and >>>>>>>>>> this >>>>>>>>>> might get hidden if we fix the test (I"ve no objection to fixing >>>>>>>>>> the >>>>>>>>>> test of course, just thinking that we should study the Locale >>>>>>>>>> code to >>>>>>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>>>>>> causing >>>>>>>>>> the threads in this test not to terminate). >>>>>>>>>> >>>>>>>>>> -Alan >>>>>>>>> >>>>> >>>> >> From chris.hegarty at oracle.com Mon Oct 10 14:27:29 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Oct 2011 15:27:29 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E927813.1000900@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> Message-ID: <4E9300D1.9000704@oracle.com> Naoto, Forgot to add, you can probably just push the changes for the test along with your source changes. I modified it a little since last review. Reproduces one in about every ten times on one of our Dual core Linux x64 boxes. >: hg diff Bug6989440.java diff -r 1e89a13d9d8f test/java/util/Locale/Bug6989440.java --- a/test/java/util/Locale/Bug6989440.java Mon Oct 10 10:38:35 2011 +0100 +++ b/test/java/util/Locale/Bug6989440.java Mon Oct 10 15:21:41 2011 +0100 @@ -37,26 +37,49 @@ import sun.util.LocaleServiceProviderPoo import sun.util.LocaleServiceProviderPool; public class Bug6989440 { - public static void main(String[] args) { - TestThread t1 = new TestThread(LocaleNameProvider.class); - TestThread t2 = new TestThread(TimeZoneNameProvider.class); - TestThread t3 = new TestThread(DateFormatProvider.class); + static volatile boolean failed; // false + static final int THREADS = 50; - t1.start(); - t2.start(); - t3.start(); + public static void main(String[] args) throws Exception { + Thread[] threads = new Thread[THREADS]; + for (int i=0; i cls; + private static int count; public TestThread(Class providerClass) { cls = providerClass; } + public TestThread() { + int which = count++ % 3; + switch (which) { + case 0 : cls = LocaleNameProvider.class; break; + case 1 : cls = TimeZoneNameProvider.class; break; + case 2 : cls = DateFormatProvider.class; break; + default : throw new AssertionError("Should not reach here"); + } + } + public void run() { - LocaleServiceProviderPool pool = LocaleServiceProviderPool.getPool(cls); - pool.getAvailableLocales(); + try { + LocaleServiceProviderPool pool = LocaleServiceProviderPool.getPool(cls); + pool.getAvailableLocales(); + } catch (Exception e) { + System.out.println(e); + e.printStackTrace(); + failed = true; + } } } } -Chris. On 10/10/2011 05:44, David Holmes wrote: > On 10/10/2011 1:35 PM, Naoto Sato wrote: >> Hi David, >> >> Thank you for your review. availableJRELocales is already declared with >> volatile keyword in the current source, so no change is involved. > > Sorry - my mistake. I misread something Chris posted earlier. > > Cheers, > David > >> Naoto >> >> On 10/9/11 6:22 PM, David Holmes wrote: >>> Hi Naoto, >>> >>> This looks okay to me, but is missing the change to make >>> availableJRELocales volatile (which is needed to ensure safe >>> publication) >>> >>> David >>> >>> On 8/10/2011 4:40 AM, Naoto Sato wrote: >>>> OK here is the proposed fix (including David's suggestion for using >>>> putIfAbsent). Can anyone please review this? >>>> >>>> --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java >>>> +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java >>>> @@ -40,6 +40,7 @@ >>>> import java.util.ServiceLoader; >>>> import java.util.Set; >>>> import java.util.concurrent.ConcurrentHashMap; >>>> +import java.util.concurrent.ConcurrentMap; >>>> import java.util.spi.LocaleServiceProvider; >>>> >>>> import sun.util.logging.PlatformLogger; >>>> @@ -57,8 +58,8 @@ >>>> * A Map that holds singleton instances of this class. Each instance >>>> holds a >>>> * set of provider implementations of a particular locale sensitive >>>> service. >>>> */ >>>> - private static Map poolOfPools = >>>> - new ConcurrentHashMap(); >>>> + private static ConcurrentMap >>>> poolOfPools = >>>> + new ConcurrentHashMap<>(); >>>> >>>> /** >>>> * A Set containing locale service providers that implement the >>>> @@ -109,7 +110,7 @@ >>>> if (pool == null) { >>>> LocaleServiceProviderPool newPool = >>>> new LocaleServiceProviderPool(providerClass); >>>> - pool = poolOfPools.put(providerClass, newPool); >>>> + pool = poolOfPools.putIfAbsent(providerClass, newPool); >>>> if (pool == null) { >>>> pool = newPool; >>>> } >>>> @@ -257,10 +258,11 @@ >>>> synchronized (LocaleServiceProviderPool.class) { >>>> if (availableJRELocales == null) { >>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>> - availableJRELocales = new ArrayList(allLocales.length); >>>> + List tmpList = new ArrayList<>(allLocales.length); >>>> for (Locale locale : allLocales) { >>>> - availableJRELocales.add(getLookupLocale(locale)); >>>> + tmpList.add(getLookupLocale(locale)); >>>> } >>>> + availableJRELocales = tmpList; >>>> } >>>> } >>>> } >>>> --- >>>> >>>> Naoto >>>> >>>> On 10/6/11 2:59 PM, Naoto Sato wrote: >>>>> Hi David, >>>>> >>>>> Thank you for the quick look and the fix! >>>>> >>>>> Naoto >>>>> >>>>> On 10/6/11 10:09 AM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> Thanks. Here's the bug: >>>>>> >>>>>> private List getJRELocales() { >>>>>> if (availableJRELocales == null) { >>>>>> synchronized (LocaleServiceProviderPool.class) { >>>>>> if (availableJRELocales == null) { >>>>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>>>> availableJRELocales = new ArrayList(allLocales.length); >>>>>> <<==== >>>>>> YIKES we just published an empty ArrayList >>>>>> for (Locale locale : allLocales) { >>>>>> availableJRELocales.add(getLookupLocale(locale)); >>>>>> } >>>>>> } >>>>>> } >>>>>> } >>>>>> return availableJRELocales; >>>>>> } >>>>>> >>>>>> >>>>>> availableJRELocales is a static variable shared across all pools. >>>>>> But it >>>>>> is being published before it gets populated. We need to use a >>>>>> temporary >>>>>> for the new ArrayList and only assign to availableJRELocales after >>>>>> it is >>>>>> populated. >>>>>> >>>>>> In addition, as you mentioned, availableJRELocales needs to be >>>>>> volatile >>>>>> for this DCL pattern to be correct. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>>>>>> I see several exceptions, similar to the following (numbers vary): >>>>>>> >>>>>>> Exception in thread "Thread-23" >>>>>>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>>>>>> at >>>>>>> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>>>>>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>>>>>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>>>>>> at java.util.HashSet.(HashSet.java:117) >>>>>>> at >>>>>>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> at Interrupter$TestThread.run(Interrupter.java:49) >>>>>> >>>>>> >>>>>>> >>>>>>> There would appear to be 156 JRE Locales ( at least on this >>>>>>> system ), >>>>>>> modCount is incremented for each add(), but when the iterator is >>>>>>> created >>>>>>> ( implicitly during the HastSet.addAll ) it sees a different value >>>>>>> for >>>>>>> modCount. >>>>>>> >>>>>>> I think there is a visibility issue here. availableJRELocales is >>>>>>> volatile, but the List reference returned from getJRELocales is >>>>>>> not. In >>>>>>> the case where availableJRELocales is not null there will be no >>>>>>> memory >>>>>>> barrier to force a HB relationship. Or maybe I've gotten this wrong? >>>>>>> His >>>>>>> is quite bizarre, or maybe it is just the overly complicated use of >>>>>>> locking/DCL in this class. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>>>>>> This might not be related to the CME problem, but here: >>>>>>>> >>>>>>>> public static LocaleServiceProviderPool getPool(Class>>>>>>> LocaleServiceProvider> providerClass) { >>>>>>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>>>>>> if (pool == null) { >>>>>>>> LocaleServiceProviderPool newPool = >>>>>>>> new LocaleServiceProviderPool(providerClass); >>>>>>>> pool = poolOfPools.put(providerClass, newPool); >>>>>>>> if (pool == null) { >>>>>>>> pool = newPool; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> return pool; >>>>>>>> } >>>>>>>> >>>>>>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>>>>>> newPool) >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>>>>>> I will look into this. Reopened the original CR. >>>>>>>>> >>>>>>>>> Naoto >>>>>>>>> >>>>>>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>>>>>> Chris Hegarty wrote: >>>>>>>>>>> Alan, Naoto, David >>>>>>>>>>> >>>>>>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>>>>>> intermittently. >>>>>>>>>>> >>>>>>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>>>>>> push it >>>>>>>>>>> to the tl repo. Job done! >>>>>>>>>> I assume there is also some underlying issue in the Locale code >>>>>>>>>> and >>>>>>>>>> this >>>>>>>>>> might get hidden if we fix the test (I"ve no objection to fixing >>>>>>>>>> the >>>>>>>>>> test of course, just thinking that we should study the Locale >>>>>>>>>> code to >>>>>>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>>>>>> causing >>>>>>>>>> the threads in this test not to terminate). >>>>>>>>>> >>>>>>>>>> -Alan >>>>>>>>> >>>>> >>>> >> From kelly.ohair at oracle.com Mon Oct 10 14:27:35 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 10 Oct 2011 16:27:35 +0200 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <1318251493.17552.6.camel@jazzette> References: <1318251493.17552.6.camel@jazzette> Message-ID: <6A735FB3-E7D6-4878-983D-685443EE578F@oracle.com> This patch looks fine to me. Have you been working with anyone to get your contributions pushed in? -kto On Oct 10, 2011, at 2:58 PM, Steve Poole wrote: > hi all, > > Please find attached a trivial patch to remove an unused variable in > jdk/src/solaris/bin/java_md.c > > The present of the variable causes the AIX build to fail since Dl_info > is not supported on AIX. The other use of Dl_info in the file is > safely wrapped with an #if defined(__solaris__) > > I have built with the change successfully on AIX and Linux. > > Cheers > > Steve > > > <4612.txt> From chris.hegarty at oracle.com Mon Oct 10 14:30:27 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 10 Oct 2011 14:30:27 +0000 Subject: hg: jdk8/tl/jdk: 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Message-ID: <20111010143049.3EF0047E51@hg.openjdk.java.net> Changeset: 2a36b8741363 Author: chegar Date: 2011-10-10 15:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a36b8741363 7098755: test/sun/misc/JarIndex/metaInfFilenames/Basic.java should use supported compiler interface Reviewed-by: mcimadamore ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java From neil.richards at ngmr.net Mon Oct 10 14:34:05 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 10 Oct 2011 15:34:05 +0100 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <6A735FB3-E7D6-4878-983D-685443EE578F@oracle.com> References: <1318251493.17552.6.camel@jazzette> <6A735FB3-E7D6-4878-983D-685443EE578F@oracle.com> Message-ID: <1318257245.7676.8.camel@chalkhill> On Mon, 2011-10-10 at 16:27 +0200, Kelly O'Hair wrote: > This patch looks fine to me. > > Have you been working with anyone to get your contributions pushed in? > > -kto > Hi Kelly, I've been looking for something with which to test my untold *powers* as a committer, so can I swipe this one to work through? (I suppose the next step is to get a Java bug raised for this change). Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Mon Oct 10 14:36:52 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Oct 2011 15:36:52 +0100 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <6A735FB3-E7D6-4878-983D-685443EE578F@oracle.com> References: <1318251493.17552.6.camel@jazzette> <6A735FB3-E7D6-4878-983D-685443EE578F@oracle.com> Message-ID: <4E930304.9070805@oracle.com> Thumps up from me too. -Chris. On 10/10/2011 15:27, Kelly O'Hair wrote: > This patch looks fine to me. > > Have you been working with anyone to get your contributions pushed in? > > -kto > > On Oct 10, 2011, at 2:58 PM, Steve Poole wrote: > >> hi all, >> >> Please find attached a trivial patch to remove an unused variable in >> jdk/src/solaris/bin/java_md.c >> >> The present of the variable causes the AIX build to fail since Dl_info >> is not supported on AIX. The other use of Dl_info in the file is >> safely wrapped with an #if defined(__solaris__) >> >> I have built with the change successfully on AIX and Linux. >> >> Cheers >> >> Steve >> >> >> <4612.txt> > From kelly.ohair at oracle.com Mon Oct 10 14:40:37 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 10 Oct 2011 16:40:37 +0200 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <1318257245.7676.8.camel@chalkhill> References: <1318251493.17552.6.camel@jazzette> <6A735FB3-E7D6-4878-983D-685443EE578F@oracle.com> <1318257245.7676.8.camel@chalkhill> Message-ID: Here is your CR, so use this as the first line in the changeset comment: 7099119: Remove unused dlinfo local variable in launcher code Line 2 should be: Reviewed-by: ohair, chegar Line 3 should be: Contributed-by: Steve Poole I think it is ok to push this into the jdk8/tl/jdk repository. -kto On Oct 10, 2011, at 4:34 PM, Neil Richards wrote: > On Mon, 2011-10-10 at 16:27 +0200, Kelly O'Hair wrote: >> This patch looks fine to me. >> >> Have you been working with anyone to get your contributions pushed in? >> >> -kto >> > > Hi Kelly, > I've been looking for something with which to test my untold *powers* as > a committer, so can I swipe this one to work through? > > (I suppose the next step is to get a Java bug raised for this change). > > Regards, Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From Alan.Bateman at oracle.com Mon Oct 10 14:52:13 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Oct 2011 15:52:13 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E9300D1.9000704@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> <4E9300D1.9000704@oracle.com> Message-ID: <4E93069D.1040609@oracle.com> Chris Hegarty wrote: > Naoto, > > Forgot to add, you can probably just push the changes for the test > along with your source changes. I modified it a little since last > review. Reproduces one in about every ten times on one of our Dual > core Linux x64 boxes. Is it the CME that duplicates for you? I'm still wondering about the original failure mode which was a timeout, presumably a looping thread or deadlock or something else. -Alan. From kumar.x.srinivasan at oracle.COM Mon Oct 10 15:04:43 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 10 Oct 2011 08:04:43 -0700 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <1318251493.17552.6.camel@jazzette> References: <1318251493.17552.6.camel@jazzette> Message-ID: <4E93098B.9030206@oracle.COM> Approved. Kumar > hi all, > > Please find attached a trivial patch to remove an unused variable in > jdk/src/solaris/bin/java_md.c > > The present of the variable causes the AIX build to fail since Dl_info > is not supported on AIX. The other use of Dl_info in the file is > safely wrapped with an #if defined(__solaris__) > > I have built with the change successfully on AIX and Linux. > > Cheers > > Steve > > From neil.richards at ngmr.net Mon Oct 10 15:21:32 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Mon, 10 Oct 2011 15:21:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111010152152.97C3B47E5A@hg.openjdk.java.net> Changeset: dd55467dd1f2 Author: ngmr Date: 2011-10-10 14:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2 7099119: Remove unused dlinfo local variable in launcher code Reviewed-by: ohair, chegar, ngmr Contributed-by: Steve Poole ! src/solaris/bin/java_md.c Changeset: 5f336e0d4d97 Author: ngmr Date: 2011-10-10 16:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f336e0d4d97 Merge From chris.hegarty at oracle.com Mon Oct 10 15:44:45 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Oct 2011 16:44:45 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E93069D.1040609@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> <4E9300D1.9000704@oracle.com> <4E93069D.1040609@oracle.com> Message-ID: <4E9312ED.8020303@oracle.com> On 10/10/2011 15:52, Alan Bateman wrote: > Chris Hegarty wrote: >> Naoto, >> >> Forgot to add, you can probably just push the changes for the test >> along with your source changes. I modified it a little since last >> review. Reproduces one in about every ten times on one of our Dual >> core Linux x64 boxes. > Is it the CME that duplicates for you? I'm still wondering about the > original failure mode which was a timeout, presumably a looping thread > or deadlock or something else. This duplicates CME and deadlock. The deadlock would appear to happen because jtreg tries to cleanup the thread that throws the CME, uncaught exception. Look for 0xea769858 below. "Thread-7" prio=10 tid=0x0a026c00 nid=0x3c30 in Object.wait() [0xd00fe000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xea769858> (a java.lang.Thread) at java.lang.Thread.join(Thread.java:1266) - locked <0xea769858> (a java.lang.Thread) at com.sun.javatest.regtest.MainAction$SameVMThreadGroup.cleanup(MainAction.java:760) at com.sun.javatest.regtest.MainAction$SameVMThreadGroup.uncaughtException(MainAction.java:727) - locked <0xea766988> (a com.sun.javatest.regtest.MainAction$SameVMThreadGroup) at java.lang.Thread.dispatchUncaughtException(Thread.java:1964) "Thread-6" prio=10 tid=0x0a022000 nid=0x3c2f waiting for monitor entry [0xd0256000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942) - waiting to lock <0xea766988> (a com.sun.javatest.regtest.MainAction$SameVMThreadGroup) at java.lang.Thread.exit(Thread.java:732) "SameVMThread" prio=10 tid=0xd058a000 nid=0x3c2e waiting for monitor entry [0xd02a6000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.ThreadGroup.add(ThreadGroup.java:885) - waiting to lock <0xea766988> (a com.sun.javatest.regtest.MainAction$SameVMThreadGroup) at java.lang.Thread.start(Thread.java:687) - locked <0xea790160> (a Bug6989440$TestThread) at Bug6989440.main(Bug6989440.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) at java.lang.Thread.run(Thread.java:722) ..... -Chris. > > -Alan. From naoto.sato at oracle.com Mon Oct 10 17:39:07 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 10 Oct 2011 10:39:07 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E9300D1.9000704@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> <4E9300D1.9000704@oracle.com> Message-ID: <4E932DBB.9040400@oracle.com> Thanks, Chris. Will do it after confirming all's well with the JPRT (currently it's down). Naoto On 10/10/11 7:27 AM, Chris Hegarty wrote: > Naoto, > > Forgot to add, you can probably just push the changes for the test along > with your source changes. I modified it a little since last review. > Reproduces one in about every ten times on one of our Dual core Linux > x64 boxes. > > > >: hg diff Bug6989440.java > diff -r 1e89a13d9d8f test/java/util/Locale/Bug6989440.java > --- a/test/java/util/Locale/Bug6989440.java Mon Oct 10 10:38:35 2011 +0100 > +++ b/test/java/util/Locale/Bug6989440.java Mon Oct 10 15:21:41 2011 +0100 > @@ -37,26 +37,49 @@ import sun.util.LocaleServiceProviderPoo > import sun.util.LocaleServiceProviderPool; > > public class Bug6989440 { > - public static void main(String[] args) { > - TestThread t1 = new TestThread(LocaleNameProvider.class); > - TestThread t2 = new TestThread(TimeZoneNameProvider.class); > - TestThread t3 = new TestThread(DateFormatProvider.class); > + static volatile boolean failed; // false > + static final int THREADS = 50; > > - t1.start(); > - t2.start(); > - t3.start(); > + public static void main(String[] args) throws Exception { > + Thread[] threads = new Thread[THREADS]; > + for (int i=0; i + threads[i] = new TestThread(); > + for (int i=0; i + threads[i].start(); > + for (int i=0; i + threads[i].join(); > + > + if (failed) > + throw new RuntimeException("Failed: check output"); > } > > static class TestThread extends Thread { > private Class cls; > + private static int count; > > public TestThread(Class providerClass) { > cls = providerClass; > } > > + public TestThread() { > + int which = count++ % 3; > + switch (which) { > + case 0 : cls = LocaleNameProvider.class; break; > + case 1 : cls = TimeZoneNameProvider.class; break; > + case 2 : cls = DateFormatProvider.class; break; > + default : throw new AssertionError("Should not reach here"); > + } > + } > + > public void run() { > - LocaleServiceProviderPool pool = LocaleServiceProviderPool.getPool(cls); > - pool.getAvailableLocales(); > + try { > + LocaleServiceProviderPool pool = LocaleServiceProviderPool.getPool(cls); > + pool.getAvailableLocales(); > + } catch (Exception e) { > + System.out.println(e); > + e.printStackTrace(); > + failed = true; > + } > } > } > } > > -Chris. > > On 10/10/2011 05:44, David Holmes wrote: >> On 10/10/2011 1:35 PM, Naoto Sato wrote: >>> Hi David, >>> >>> Thank you for your review. availableJRELocales is already declared with >>> volatile keyword in the current source, so no change is involved. >> >> Sorry - my mistake. I misread something Chris posted earlier. >> >> Cheers, >> David >> >>> Naoto >>> >>> On 10/9/11 6:22 PM, David Holmes wrote: >>>> Hi Naoto, >>>> >>>> This looks okay to me, but is missing the change to make >>>> availableJRELocales volatile (which is needed to ensure safe >>>> publication) >>>> >>>> David >>>> >>>> On 8/10/2011 4:40 AM, Naoto Sato wrote: >>>>> OK here is the proposed fix (including David's suggestion for using >>>>> putIfAbsent). Can anyone please review this? >>>>> >>>>> --- a/src/share/classes/sun/util/LocaleServiceProviderPool.java >>>>> +++ b/src/share/classes/sun/util/LocaleServiceProviderPool.java >>>>> @@ -40,6 +40,7 @@ >>>>> import java.util.ServiceLoader; >>>>> import java.util.Set; >>>>> import java.util.concurrent.ConcurrentHashMap; >>>>> +import java.util.concurrent.ConcurrentMap; >>>>> import java.util.spi.LocaleServiceProvider; >>>>> >>>>> import sun.util.logging.PlatformLogger; >>>>> @@ -57,8 +58,8 @@ >>>>> * A Map that holds singleton instances of this class. Each instance >>>>> holds a >>>>> * set of provider implementations of a particular locale sensitive >>>>> service. >>>>> */ >>>>> - private static Map poolOfPools = >>>>> - new ConcurrentHashMap(); >>>>> + private static ConcurrentMap >>>>> poolOfPools = >>>>> + new ConcurrentHashMap<>(); >>>>> >>>>> /** >>>>> * A Set containing locale service providers that implement the >>>>> @@ -109,7 +110,7 @@ >>>>> if (pool == null) { >>>>> LocaleServiceProviderPool newPool = >>>>> new LocaleServiceProviderPool(providerClass); >>>>> - pool = poolOfPools.put(providerClass, newPool); >>>>> + pool = poolOfPools.putIfAbsent(providerClass, newPool); >>>>> if (pool == null) { >>>>> pool = newPool; >>>>> } >>>>> @@ -257,10 +258,11 @@ >>>>> synchronized (LocaleServiceProviderPool.class) { >>>>> if (availableJRELocales == null) { >>>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>>> - availableJRELocales = new ArrayList(allLocales.length); >>>>> + List tmpList = new ArrayList<>(allLocales.length); >>>>> for (Locale locale : allLocales) { >>>>> - availableJRELocales.add(getLookupLocale(locale)); >>>>> + tmpList.add(getLookupLocale(locale)); >>>>> } >>>>> + availableJRELocales = tmpList; >>>>> } >>>>> } >>>>> } >>>>> --- >>>>> >>>>> Naoto >>>>> >>>>> On 10/6/11 2:59 PM, Naoto Sato wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for the quick look and the fix! >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 10/6/11 10:09 AM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> Thanks. Here's the bug: >>>>>>> >>>>>>> private List getJRELocales() { >>>>>>> if (availableJRELocales == null) { >>>>>>> synchronized (LocaleServiceProviderPool.class) { >>>>>>> if (availableJRELocales == null) { >>>>>>> Locale[] allLocales = LocaleData.getAvailableLocales(); >>>>>>> availableJRELocales = new ArrayList(allLocales.length); >>>>>>> <<==== >>>>>>> YIKES we just published an empty ArrayList >>>>>>> for (Locale locale : allLocales) { >>>>>>> availableJRELocales.add(getLookupLocale(locale)); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> return availableJRELocales; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> availableJRELocales is a static variable shared across all pools. >>>>>>> But it >>>>>>> is being published before it gets populated. We need to use a >>>>>>> temporary >>>>>>> for the new ArrayList and only assign to availableJRELocales after >>>>>>> it is >>>>>>> populated. >>>>>>> >>>>>>> In addition, as you mentioned, availableJRELocales needs to be >>>>>>> volatile >>>>>>> for this DCL pattern to be correct. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 6/10/2011 9:02 PM, Chris Hegarty wrote: >>>>>>>> I see several exceptions, similar to the following (numbers vary): >>>>>>>> >>>>>>>> Exception in thread "Thread-23" >>>>>>>> java.util.ConcurrentModificationException: Expected: 96, got: 156 >>>>>>>> at >>>>>>>> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819) >>>>>>>> at java.util.ArrayList$Itr.next(ArrayList.java:791) >>>>>>>> at java.util.AbstractCollection.addAll(AbstractCollection.java:333) >>>>>>>> at java.util.HashSet.(HashSet.java:117) >>>>>>>> at >>>>>>>> sun.util.LocaleServiceProviderPool.getAvailableLocales(LocaleServiceProviderPool.java:206) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> at Interrupter$TestThread.run(Interrupter.java:49) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> There would appear to be 156 JRE Locales ( at least on this >>>>>>>> system ), >>>>>>>> modCount is incremented for each add(), but when the iterator is >>>>>>>> created >>>>>>>> ( implicitly during the HastSet.addAll ) it sees a different value >>>>>>>> for >>>>>>>> modCount. >>>>>>>> >>>>>>>> I think there is a visibility issue here. availableJRELocales is >>>>>>>> volatile, but the List reference returned from getJRELocales is >>>>>>>> not. In >>>>>>>> the case where availableJRELocales is not null there will be no >>>>>>>> memory >>>>>>>> barrier to force a HB relationship. Or maybe I've gotten this >>>>>>>> wrong? >>>>>>>> His >>>>>>>> is quite bizarre, or maybe it is just the overly complicated use of >>>>>>>> locking/DCL in this class. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 10/ 5/11 07:01 PM, David Holmes wrote: >>>>>>>>> This might not be related to the CME problem, but here: >>>>>>>>> >>>>>>>>> public static LocaleServiceProviderPool getPool(Class>>>>>>>> LocaleServiceProvider> providerClass) { >>>>>>>>> LocaleServiceProviderPool pool = poolOfPools.get(providerClass); >>>>>>>>> if (pool == null) { >>>>>>>>> LocaleServiceProviderPool newPool = >>>>>>>>> new LocaleServiceProviderPool(providerClass); >>>>>>>>> pool = poolOfPools.put(providerClass, newPool); >>>>>>>>> if (pool == null) { >>>>>>>>> pool = newPool; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> return pool; >>>>>>>>> } >>>>>>>>> >>>>>>>>> we should probably be using poolOfPools.putIfAbsent(providerClass, >>>>>>>>> newPool) >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 6/10/2011 3:35 AM, Naoto Sato wrote: >>>>>>>>>> I will look into this. Reopened the original CR. >>>>>>>>>> >>>>>>>>>> Naoto >>>>>>>>>> >>>>>>>>>> On 10/5/11 9:58 AM, Alan Bateman wrote: >>>>>>>>>>> Chris Hegarty wrote: >>>>>>>>>>>> Alan, Naoto, David >>>>>>>>>>>> >>>>>>>>>>>> I filed CR 7098100: java/util/Locale/Bug6989440.java fails >>>>>>>>>>>> intermittently. >>>>>>>>>>>> >>>>>>>>>>>> If you're ok with it please review the patch (below) and I can >>>>>>>>>>>> push it >>>>>>>>>>>> to the tl repo. Job done! >>>>>>>>>>> I assume there is also some underlying issue in the Locale code >>>>>>>>>>> and >>>>>>>>>>> this >>>>>>>>>>> might get hidden if we fix the test (I"ve no objection to fixing >>>>>>>>>>> the >>>>>>>>>>> test of course, just thinking that we should study the Locale >>>>>>>>>>> code to >>>>>>>>>>> try to identify the deadlock or hang or whatever it is that is >>>>>>>>>>> causing >>>>>>>>>>> the threads in this test not to terminate). >>>>>>>>>>> >>>>>>>>>>> -Alan >>>>>>>>>> >>>>>> >>>>> >>> From mike.skells at talk21.com Mon Oct 10 21:39:42 2011 From: mike.skells at talk21.com (Mike Skells) Date: Mon, 10 Oct 2011 22:39:42 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> Message-ID: <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> Hi All, Trying to request a review again with different file types hopefully it will get through the filter Regards Mike >________________________________ >From: Mike Skells >To: Mike Skells ; Alan Bateman >Cc: Core-Libs-Dev >Sent: Monday, 10 October 2011, 9:17 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > > >The patch (.patch) and results (.xlsx) seem to be filtered out. What is the best format to submit files to avoid list filtering attachments? > > > >>________________________________ >>From: Mike Skells >>To: Alan Bateman >>Cc: Core-Libs-Dev >>Sent: Monday, 10 October 2011, 8:53 >>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >> >>Doh, >>This time with the patches, test code, and CPU usage stats attached >> >>Regard >> >>Mike? >> >> >> >>>________________________________ >>>From: Alan Bateman >>>To: mike.skells at talk21.com >>>Cc: Core-Libs-Dev >>>Sent: Monday, 10 October 2011, 0:15 >>>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >>> >>>mike.skells at talk21.com wrote: >>>> : >>>> >>>> >>>> I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) >>>>? >>>Mike - I don't think there is a patch attached to your mail. >>> >>> >>> >> >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TestThrow.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk_3852patch.txt URL: From mike.skells at talk21.com Mon Oct 10 22:30:20 2011 From: mike.skells at talk21.com (Mike Skells) Date: Mon, 10 Oct 2011 23:30:20 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> Message-ID: <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> Hi All, Last attempt - hopefully with all 3 files, a patch, test case and results. The patch and results are text format to avoid the filters on this list Hopefully you are not all to?irritated?with this posting to review it :-) Regards Mike >________________________________ >From: Mike Skells >To: Core-Libs-Dev >Sent: Monday, 10 October 2011, 22:39 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > >Hi All, >Trying to request a review again with different file types > >hopefully it will get through the filter > >Regards >Mike > > > >>________________________________ >>From: Mike Skells >>To: Mike Skells ; Alan Bateman >>Cc: Core-Libs-Dev >>Sent: Monday, 10 October 2011, 9:17 >>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >> >> >>The patch (.patch) and results (.xlsx) seem to be filtered out. What is the best format to submit files to avoid list filtering attachments? >> >> >> >>>________________________________ >>>From: Mike Skells >>>To: Alan Bateman >>>Cc: Core-Libs-Dev >>>Sent: Monday, 10 October 2011, 8:53 >>>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >>> >>>Doh, >>>This time with the patches, test code, and CPU usage stats attached >>> >>>Regard >>> >>>Mike? >>> >>> >>> >>>>________________________________ >>>>From: Alan Bateman >>>>To: mike.skells at talk21.com >>>>Cc: Core-Libs-Dev >>>>Sent: Monday, 10 October 2011, 0:15 >>>>Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >>>> >>>>mike.skells at talk21.com wrote: >>>>> : >>>>> >>>>> >>>>> I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) >>>>>? >>>>Mike - I don't think there is a patch attached to your mail. >>>> >>>> >>>> >>> >>> >> >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: result_csv.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TestThrow.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk_3852patch.txt URL: From david.holmes at oracle.com Mon Oct 10 23:00:31 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Oct 2011 09:00:31 +1000 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E9312ED.8020303@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> <4E9300D1.9000704@oracle.com> <4E93069D.1040609@oracle.com> <4E9312ED.8020303@oracle.com> Message-ID: <4E93790F.5090105@oracle.com> So the jtreg uncaughtException code is doing a join() on the target Thread while holding the monitor lock of the ThreadGroup - ouch! Where do we file jtreg bugs? David On 11/10/2011 1:44 AM, Chris Hegarty wrote: > On 10/10/2011 15:52, Alan Bateman wrote: >> Chris Hegarty wrote: >>> Naoto, >>> >>> Forgot to add, you can probably just push the changes for the test >>> along with your source changes. I modified it a little since last >>> review. Reproduces one in about every ten times on one of our Dual >>> core Linux x64 boxes. >> Is it the CME that duplicates for you? I'm still wondering about the >> original failure mode which was a timeout, presumably a looping thread >> or deadlock or something else. > > This duplicates CME and deadlock. The deadlock would appear to happen > because jtreg tries to cleanup the thread that throws the CME, uncaught > exception. Look for 0xea769858 below. > > "Thread-7" prio=10 tid=0x0a026c00 nid=0x3c30 in Object.wait() [0xd00fe000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xea769858> (a java.lang.Thread) > at java.lang.Thread.join(Thread.java:1266) > - locked <0xea769858> (a java.lang.Thread) > at > com.sun.javatest.regtest.MainAction$SameVMThreadGroup.cleanup(MainAction.java:760) > > at > com.sun.javatest.regtest.MainAction$SameVMThreadGroup.uncaughtException(MainAction.java:727) > > - locked <0xea766988> (a > com.sun.javatest.regtest.MainAction$SameVMThreadGroup) > at java.lang.Thread.dispatchUncaughtException(Thread.java:1964) > > "Thread-6" prio=10 tid=0x0a022000 nid=0x3c2f waiting for monitor entry > [0xd0256000] > java.lang.Thread.State: BLOCKED (on object monitor) > at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942) > - waiting to lock <0xea766988> (a > com.sun.javatest.regtest.MainAction$SameVMThreadGroup) > at java.lang.Thread.exit(Thread.java:732) > > "SameVMThread" prio=10 tid=0xd058a000 nid=0x3c2e waiting for monitor > entry [0xd02a6000] > java.lang.Thread.State: BLOCKED (on object monitor) > at java.lang.ThreadGroup.add(ThreadGroup.java:885) > - waiting to lock <0xea766988> (a > com.sun.javatest.regtest.MainAction$SameVMThreadGroup) > at java.lang.Thread.start(Thread.java:687) > - locked <0xea790160> (a Bug6989440$TestThread) > at Bug6989440.main(Bug6989440.java:47) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > at > com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) > at java.lang.Thread.run(Thread.java:722) > ..... > > > -Chris. > >> >> -Alan. From david.holmes at oracle.com Mon Oct 10 23:12:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Oct 2011 09:12:12 +1000 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> Message-ID: <4E937BCC.3070900@oracle.com> Hi Mike, I have one question. In part the existing code tends to use a single println with multiple string concatenations. Your changes optimize the string operations by using explicit, rather than implicit StringBuilders. Did you consider instead/aso using multiple print statmements top avoid the need for doing the concatenation in the first place? Eg: for (StackTraceElement traceElement : trace) s.println("\tat " + traceElement); becomes for (StackTraceElement traceElement : trace) { s.print("\tat "); s.println(traceElement); } Similarly for: for (int i = 0; i <= m; i++) s.println(prefix + "\tat " + trace[i]); Cheers, David Holmes On 11/10/2011 8:30 AM, Mike Skells wrote: > Hi All, > Last attempt - hopefully > > with all 3 files, a patch, test case and results. The patch and results are text format to avoid the filters on this list > > Hopefully you are not all to irritated with this posting to review it :-) > > Regards > Mike > > >> ________________________________ >> From: Mike Skells >> To: Core-Libs-Dev >> Sent: Monday, 10 October 2011, 22:39 >> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >> >> Hi All, >> Trying to request a review again with different file types >> >> hopefully it will get through the filter >> >> Regards >> Mike >> >> >> >>> ________________________________ >>> From: Mike Skells >>> To: Mike Skells; Alan Bateman >>> Cc: Core-Libs-Dev >>> Sent: Monday, 10 October 2011, 9:17 >>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >>> >>> >>> The patch (.patch) and results (.xlsx) seem to be filtered out. What is the best format to submit files to avoid list filtering attachments? >>> >>> >>> >>>> ________________________________ >>>> From: Mike Skells >>>> To: Alan Bateman >>>> Cc: Core-Libs-Dev >>>> Sent: Monday, 10 October 2011, 8:53 >>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >>>> >>>> Doh, >>>> This time with the patches, test code, and CPU usage stats attached >>>> >>>> Regard >>>> >>>> Mike >>>> >>>> >>>> >>>>> ________________________________ >>>>> From: Alan Bateman >>>>> To: mike.skells at talk21.com >>>>> Cc: Core-Libs-Dev >>>>> Sent: Monday, 10 October 2011, 0:15 >>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) >>>>> >>>>> mike.skells at talk21.com wrote: >>>>>> : >>>>>> >>>>>> >>>>>> I include the patch, a micro-benchmark and the results of the micro-benchmark which show an improvement of 80% throughput (ie it is almost twice as fast) >>>>>> >>>>> Mike - I don't think there is a patch attached to your mail. >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> From patrick at reini.net Tue Oct 11 05:39:12 2011 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 11 Oct 2011 07:39:12 +0200 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E937BCC.3070900@oracle.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> Message-ID: <4E93D680.7040908@reini.net> Hi David, In my opinion, this could be even written in this ways: for (StackTraceElement traceElement : trace) s.append("\tat ").println(traceElement); and Similarly for: for (int i = 0; i <= m; i++) s.append(prefix).append("\tat ").println(trace[i]); and the change would be only on one line ;-) Cheers, Patrick "Reini" Reinhart Am 11.10.11 01:12, schrieb David Holmes: > Hi Mike, > > I have one question. In part the existing code tends to use a single > println with multiple string concatenations. Your changes optimize the > string operations by using explicit, rather than implicit > StringBuilders. Did you consider instead/aso using multiple print > statmements top avoid the need for doing the concatenation in the > first place? Eg: > > for (StackTraceElement traceElement : trace) > s.println("\tat " + traceElement); > > becomes > > for (StackTraceElement traceElement : trace) { > s.print("\tat "); > s.println(traceElement); > } > > Similarly for: > > for (int i = 0; i <= m; i++) > s.println(prefix + "\tat " + trace[i]); > > > Cheers, > David Holmes > > On 11/10/2011 8:30 AM, Mike Skells wrote: >> Hi All, >> Last attempt - hopefully >> >> with all 3 files, a patch, test case and results. The patch and >> results are text format to avoid the filters on this list >> >> Hopefully you are not all to irritated with this posting to review it >> :-) >> >> Regards >> Mike >> >> >>> ________________________________ >>> From: Mike Skells >>> To: Core-Libs-Dev >>> Sent: Monday, 10 October 2011, 22:39 >>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>> usage) >>> >>> Hi All, >>> Trying to request a review again with different file types >>> >>> hopefully it will get through the filter >>> >>> Regards >>> Mike >>> >>> >>> >>>> ________________________________ >>>> From: Mike Skells >>>> To: Mike Skells; Alan >>>> Bateman >>>> Cc: Core-Libs-Dev >>>> Sent: Monday, 10 October 2011, 9:17 >>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>> usage) >>>> >>>> >>>> The patch (.patch) and results (.xlsx) seem to be filtered out. >>>> What is the best format to submit files to avoid list filtering >>>> attachments? >>>> >>>> >>>> >>>>> ________________________________ >>>>> From: Mike Skells >>>>> To: Alan Bateman >>>>> Cc: Core-Libs-Dev >>>>> Sent: Monday, 10 October 2011, 8:53 >>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>>> usage) >>>>> >>>>> Doh, >>>>> This time with the patches, test code, and CPU usage stats attached >>>>> >>>>> Regard >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>>> ________________________________ >>>>>> From: Alan Bateman >>>>>> To: mike.skells at talk21.com >>>>>> Cc: Core-Libs-Dev >>>>>> Sent: Monday, 10 October 2011, 0:15 >>>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced >>>>>> CPU usage) >>>>>> >>>>>> mike.skells at talk21.com wrote: >>>>>>> : >>>>>>> >>>>>>> >>>>>>> I include the patch, a micro-benchmark and the results of the >>>>>>> micro-benchmark which show an improvement of 80% throughput (ie >>>>>>> it is almost twice as fast) >>>>>>> >>>>>> Mike - I don't think there is a patch attached to your mail. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> From spoole at linux.vnet.ibm.com Tue Oct 11 06:40:04 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 11 Oct 2011 07:40:04 +0100 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <4E93098B.9030206@oracle.COM> References: <1318251493.17552.6.camel@jazzette> <4E93098B.9030206@oracle.COM> Message-ID: <1318315204.2591.0.camel@jazzette> On Mon, 2011-10-10 at 08:04 -0700, Kumar Srinivasan wrote: That was quick! Thanks to all for the quick turn around. > Approved. > > Kumar > > > hi all, > > > > Please find attached a trivial patch to remove an unused variable in > > jdk/src/solaris/bin/java_md.c > > > > The present of the variable causes the AIX build to fail since Dl_info > > is not supported on AIX. The other use of Dl_info in the file is > > safely wrapped with an #if defined(__solaris__) > > > > I have built with the change successfully on AIX and Linux. > > > > Cheers > > > > Steve > > > > > From kelly.ohair at oracle.com Tue Oct 11 08:55:54 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 11 Oct 2011 10:55:54 +0200 Subject: Request for review - removal of unused dlinfo variable in java_md.c In-Reply-To: <1318315204.2591.0.camel@jazzette> References: <1318251493.17552.6.camel@jazzette> <4E93098B.9030206@oracle.COM> <1318315204.2591.0.camel@jazzette> Message-ID: <48F5DB6A-1992-4486-8946-597CF59B1622@oracle.com> Please keep in mind that this was a very small, obviously safe, one line change. More significant changes could take longer. Just to set expectations. ;^) -kto On Oct 11, 2011, at 8:40 AM, Steve Poole wrote: > On Mon, 2011-10-10 at 08:04 -0700, Kumar Srinivasan wrote: > > That was quick! Thanks to all for the quick turn around. > >> Approved. >> >> Kumar >> >>> hi all, >>> >>> Please find attached a trivial patch to remove an unused variable in >>> jdk/src/solaris/bin/java_md.c >>> >>> The present of the variable causes the AIX build to fail since Dl_info >>> is not supported on AIX. The other use of Dl_info in the file is >>> safely wrapped with an #if defined(__solaris__) >>> >>> I have built with the change successfully on AIX and Linux. >>> >>> Cheers >>> >>> Steve >>> >>> >> > > From david.holmes at oracle.com Tue Oct 11 10:16:38 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Oct 2011 20:16:38 +1000 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E93D680.7040908@reini.net> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> Message-ID: <4E941786.8090709@oracle.com> Hi Patrick, On 11/10/2011 3:39 PM, Patrick Reinhart wrote: > > In my opinion, this could be even written in this ways: > > for (StackTraceElement traceElement : trace) > s.append("\tat ").println(traceElement); I think you are confusing your streams and your StringBuilders - s is a stream. David > > and Similarly for: > > for (int i = 0; i <= m; i++) > s.append(prefix).append("\tat ").println(trace[i]); > > and the change would be only on one line ;-) > > Cheers, > > Patrick "Reini" Reinhart > > > > Am 11.10.11 01:12, schrieb David Holmes: >> Hi Mike, >> >> I have one question. In part the existing code tends to use a single >> println with multiple string concatenations. Your changes optimize the >> string operations by using explicit, rather than implicit >> StringBuilders. Did you consider instead/aso using multiple print >> statmements top avoid the need for doing the concatenation in the >> first place? Eg: >> >> for (StackTraceElement traceElement : trace) >> s.println("\tat " + traceElement); >> >> becomes >> >> for (StackTraceElement traceElement : trace) { >> s.print("\tat "); >> s.println(traceElement); >> } >> >> Similarly for: >> >> for (int i = 0; i <= m; i++) >> s.println(prefix + "\tat " + trace[i]); >> >> >> Cheers, >> David Holmes >> >> On 11/10/2011 8:30 AM, Mike Skells wrote: >>> Hi All, >>> Last attempt - hopefully >>> >>> with all 3 files, a patch, test case and results. The patch and >>> results are text format to avoid the filters on this list >>> >>> Hopefully you are not all to irritated with this posting to review it >>> :-) >>> >>> Regards >>> Mike >>> >>> >>>> ________________________________ >>>> From: Mike Skells >>>> To: Core-Libs-Dev >>>> Sent: Monday, 10 October 2011, 22:39 >>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>> usage) >>>> >>>> Hi All, >>>> Trying to request a review again with different file types >>>> >>>> hopefully it will get through the filter >>>> >>>> Regards >>>> Mike >>>> >>>> >>>> >>>>> ________________________________ >>>>> From: Mike Skells >>>>> To: Mike Skells; Alan >>>>> Bateman >>>>> Cc: Core-Libs-Dev >>>>> Sent: Monday, 10 October 2011, 9:17 >>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>>> usage) >>>>> >>>>> >>>>> The patch (.patch) and results (.xlsx) seem to be filtered out. >>>>> What is the best format to submit files to avoid list filtering >>>>> attachments? >>>>> >>>>> >>>>> >>>>>> ________________________________ >>>>>> From: Mike Skells >>>>>> To: Alan Bateman >>>>>> Cc: Core-Libs-Dev >>>>>> Sent: Monday, 10 October 2011, 8:53 >>>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>>>> usage) >>>>>> >>>>>> Doh, >>>>>> This time with the patches, test code, and CPU usage stats attached >>>>>> >>>>>> Regard >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>> >>>>>>> ________________________________ >>>>>>> From: Alan Bateman >>>>>>> To: mike.skells at talk21.com >>>>>>> Cc: Core-Libs-Dev >>>>>>> Sent: Monday, 10 October 2011, 0:15 >>>>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced >>>>>>> CPU usage) >>>>>>> >>>>>>> mike.skells at talk21.com wrote: >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> I include the patch, a micro-benchmark and the results of the >>>>>>>> micro-benchmark which show an improvement of 80% throughput (ie >>>>>>>> it is almost twice as fast) >>>>>>>> >>>>>>> Mike - I don't think there is a patch attached to your mail. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> > From patrick at reini.net Tue Oct 11 11:34:26 2011 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 11 Oct 2011 13:34:26 +0200 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E941786.8090709@oracle.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> Message-ID: <20111011133426.17233w67936hkzia@webmail.nine.ch> Hi David, Well in the case of a "normal" Stream you are absolutely right, but in the Throwable case it's a PrintStream (or PrintWriter) with both do implement the java.lang.Appendable interface (as introduced in 1.5). This interface defines the append() method suggested in my examples. Cheers Patrick "Reini" Reinhart Zitat von "David Holmes" : > Hi Patrick, > > > On 11/10/2011 3:39 PM, Patrick Reinhart wrote: >> >> In my opinion, this could be even written in this ways: >> >> for (StackTraceElement traceElement : trace) >> s.append("\tat ").println(traceElement); > > I think you are confusing your streams and your StringBuilders - s > is a stream. > > David > > >> >> and Similarly for: >> >> for (int i = 0; i <= m; i++) >> s.append(prefix).append("\tat ").println(trace[i]); >> >> and the change would be only on one line ;-) >> >> Cheers, >> >> Patrick "Reini" Reinhart >> From Ulf.Zibis at gmx.de Tue Oct 11 11:36:57 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 11 Oct 2011 13:36:57 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E862AB2.7090605@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> Message-ID: <4E942A59.5070006@gmx.de> Hi Sherman, I didn't read anything from you since longer time. You are in holidays? Am 30.09.2011 22:46, schrieb Xueming Shen: > > I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because > the benchmark shows the "shift" version is slightly faster. Do you have any number > shows any difference now. My non-scientific benchmark still suggests the "shift" > type is faster on -server vm, no significant difference on -client vm. > In this sense, then you should do the same here: 87 private static boolean isNotContinuation(int b) { 88 return (b >> 6) != -2; 89 } ... + in all isMalformedxxx(). BTW, in all isMalformedxxx() you could replace all (bx & 0xc0) != 0x80 by isNotContinuation(bx) (would reduce the effort, checking the hex values manually, each time while reading) Additionally: Make private: 75 private static final void updatePositions( 76 Buffer src, int sp, Buffer dst, int dp) { -Ulf From Ulf.Zibis at gmx.de Tue Oct 11 13:22:14 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 11 Oct 2011 15:22:14 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E942A59.5070006@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E942A59.5070006@gmx.de> Message-ID: <4E944306.5010605@gmx.de> Am 11.10.2011 13:36, schrieb Ulf Zibis: > >> I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because >> the benchmark shows the "shift" version is slightly faster. Do you have any number >> shows any difference now. My non-scientific benchmark still suggests the "shift" >> type is faster on -server vm, no significant difference on -client vm. >> > > In this sense, then you should do the same here: > 87 private static boolean isNotContinuation(int b) { > 88 return (b >> 6) != -2; > 89 } > Another 3rd variant to compare for performance: (needs only 1 constant to load in cpu register, and is a 1-byte op code) 87 private static boolean isNotContinuation(byte b) { 88 return b >= (byte)0xc0; 89 } -Ulf From chris.hegarty at oracle.com Tue Oct 11 13:34:35 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 11 Oct 2011 13:34:35 +0000 Subject: hg: jdk8/tl/jdk: 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Message-ID: <20111011133453.E7ECA47F0C@hg.openjdk.java.net> Changeset: 5bfe2de1157b Author: chegar Date: 2011-10-11 12:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bfe2de1157b 7099488: TwoStacksPlainSocketImpl should invoke super.create(stream), typo in fix for 7098719 Reviewed-by: coffeys ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java From chris.hegarty at oracle.com Tue Oct 11 15:06:52 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 11 Oct 2011 16:06:52 +0100 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E93790F.5090105@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> <4E9300D1.9000704@oracle.com> <4E93069D.1040609@oracle.com> <4E9312ED.8020303@oracle.com> <4E93790F.5090105@oracle.com> Message-ID: <4E945B8C.1030208@oracle.com> David, I'm not sure where we can file bugs on jtreg, probably have to wait for Jon to come back on line and drop him a mail. This is even worse that I originally though. Any thread that throws an unchecked exception followed by another thread starting a thread ( or invoking any operation on the group requiring its monitor ) will encounter this hang. When run in samevm or agentvm mode. Minimal treg test to reproduce this: /* * @test */ import java.util.concurrent.Phaser; public class HangJtreg { static Phaser phaser = new Phaser(2); public static void main(String[] args) throws Exception { (new Thread(new Runnable() { public void run() { try { throw new RuntimeException("thrown from ThrowingThread"); } finally { phaser.arrive(); } } })).start(); phaser.arriveAndAwaitAdvance(); (new Thread()).start(); } } -Chris. On 10/11/11 12:00 AM, David Holmes wrote: > So the jtreg uncaughtException code is doing a join() on the target > Thread while holding the monitor lock of the ThreadGroup - ouch! Where > do we file jtreg bugs? > > David > > On 11/10/2011 1:44 AM, Chris Hegarty wrote: >> On 10/10/2011 15:52, Alan Bateman wrote: >>> Chris Hegarty wrote: >>>> Naoto, >>>> >>>> Forgot to add, you can probably just push the changes for the test >>>> along with your source changes. I modified it a little since last >>>> review. Reproduces one in about every ten times on one of our Dual >>>> core Linux x64 boxes. >>> Is it the CME that duplicates for you? I'm still wondering about the >>> original failure mode which was a timeout, presumably a looping thread >>> or deadlock or something else. >> >> This duplicates CME and deadlock. The deadlock would appear to happen >> because jtreg tries to cleanup the thread that throws the CME, uncaught >> exception. Look for 0xea769858 below. >> >> "Thread-7" prio=10 tid=0x0a026c00 nid=0x3c30 in Object.wait() >> [0xd00fe000] >> java.lang.Thread.State: TIMED_WAITING (on object monitor) >> at java.lang.Object.wait(Native Method) >> - waiting on <0xea769858> (a java.lang.Thread) >> at java.lang.Thread.join(Thread.java:1266) >> - locked <0xea769858> (a java.lang.Thread) >> at >> com.sun.javatest.regtest.MainAction$SameVMThreadGroup.cleanup(MainAction.java:760) >> >> >> at >> com.sun.javatest.regtest.MainAction$SameVMThreadGroup.uncaughtException(MainAction.java:727) >> >> >> - locked <0xea766988> (a >> com.sun.javatest.regtest.MainAction$SameVMThreadGroup) >> at java.lang.Thread.dispatchUncaughtException(Thread.java:1964) >> >> "Thread-6" prio=10 tid=0x0a022000 nid=0x3c2f waiting for monitor entry >> [0xd0256000] >> java.lang.Thread.State: BLOCKED (on object monitor) >> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942) >> - waiting to lock <0xea766988> (a >> com.sun.javatest.regtest.MainAction$SameVMThreadGroup) >> at java.lang.Thread.exit(Thread.java:732) >> >> "SameVMThread" prio=10 tid=0xd058a000 nid=0x3c2e waiting for monitor >> entry [0xd02a6000] >> java.lang.Thread.State: BLOCKED (on object monitor) >> at java.lang.ThreadGroup.add(ThreadGroup.java:885) >> - waiting to lock <0xea766988> (a >> com.sun.javatest.regtest.MainAction$SameVMThreadGroup) >> at java.lang.Thread.start(Thread.java:687) >> - locked <0xea790160> (a Bug6989440$TestThread) >> at Bug6989440.main(Bug6989440.java:47) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> >> at java.lang.reflect.Method.invoke(Method.java:601) >> at >> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) >> >> at java.lang.Thread.run(Thread.java:722) >> ..... >> >> >> -Chris. >> >>> >>> -Alan. From kumar.x.srinivasan at oracle.COM Tue Oct 11 16:38:33 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 11 Oct 2011 09:38:33 -0700 Subject: testcase failure java/util/Locale/Bug6989440.java In-Reply-To: <4E945B8C.1030208@oracle.com> References: <844B6B71-89DD-46A5-9617-073FE3D82364@oracle.com> <4E89206B.1040603@oracle.com> <4E89F6AD.1060401@oracle.com> <4E8A2849.60709@oracle.com> <4E8A9790.10303@oracle.com> <4E8ABFB7.40108@oracle.com> <4E8B08FB.4040703@oracle.com> <4E8B2E91.4020604@oracle.com> <4E8C6484.2010909@oracle.com> <4E8C706B.4040200@oracle.com> <4E8C7AE7.10807@oracle.com> <4E8C8CCA.7010100@oracle.com> <4E8C955E.6060502@oracle.com> <4E8C9B8F.8000205@oracle.com> <4E8D8AE1.8080902@oracle.com> <4E8DE0CD.3080401@oracle.com> <4E8E24C5.9090402@oracle.com> <4E8F479F.6070301@oracle.com> <4E9248E4.3040509@oracle.com> <4E926815.7020808@oracle.com> <4E927813.1000900@oracle.com> <4E9300D1.9000704@oracle.com> <4E93069D.1040609@oracle.com> <4E9312ED.8020303@oracle.com> <4E93790F.5090105@oracle.com> <4E945B8C.1030208@oracle.com> Message-ID: <4E947109.5030207@oracle.COM> You can file it as follows: Product: jct_tools Category: jct_tools Subcategory: regtest and for a good measure add jon to the interest list. Kumar > David, > > I'm not sure where we can file bugs on jtreg, probably have to wait > for Jon to come back on line and drop him a mail. > > This is even worse that I originally though. Any thread that throws an > unchecked exception followed by another thread starting a thread ( or > invoking any operation on the group requiring its monitor ) will > encounter this hang. When run in samevm or agentvm mode. > > Minimal treg test to reproduce this: > > /* > * @test > */ > import java.util.concurrent.Phaser; > > public class HangJtreg { > static Phaser phaser = new Phaser(2); > > public static void main(String[] args) throws Exception { > (new Thread(new Runnable() { > public void run() { > try { > throw new RuntimeException("thrown from > ThrowingThread"); > } finally { > phaser.arrive(); > } > } > })).start(); > > phaser.arriveAndAwaitAdvance(); > (new Thread()).start(); > } > } > > -Chris. > > On 10/11/11 12:00 AM, David Holmes wrote: >> So the jtreg uncaughtException code is doing a join() on the target >> Thread while holding the monitor lock of the ThreadGroup - ouch! Where >> do we file jtreg bugs? >> >> David >> >> On 11/10/2011 1:44 AM, Chris Hegarty wrote: >>> On 10/10/2011 15:52, Alan Bateman wrote: >>>> Chris Hegarty wrote: >>>>> Naoto, >>>>> >>>>> Forgot to add, you can probably just push the changes for the test >>>>> along with your source changes. I modified it a little since last >>>>> review. Reproduces one in about every ten times on one of our Dual >>>>> core Linux x64 boxes. >>>> Is it the CME that duplicates for you? I'm still wondering about the >>>> original failure mode which was a timeout, presumably a looping thread >>>> or deadlock or something else. >>> >>> This duplicates CME and deadlock. The deadlock would appear to happen >>> because jtreg tries to cleanup the thread that throws the CME, uncaught >>> exception. Look for 0xea769858 below. >>> >>> "Thread-7" prio=10 tid=0x0a026c00 nid=0x3c30 in Object.wait() >>> [0xd00fe000] >>> java.lang.Thread.State: TIMED_WAITING (on object monitor) >>> at java.lang.Object.wait(Native Method) >>> - waiting on <0xea769858> (a java.lang.Thread) >>> at java.lang.Thread.join(Thread.java:1266) >>> - locked <0xea769858> (a java.lang.Thread) >>> at >>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup.cleanup(MainAction.java:760) >>> >>> >>> >>> at >>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup.uncaughtException(MainAction.java:727) >>> >>> >>> >>> - locked <0xea766988> (a >>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup) >>> at java.lang.Thread.dispatchUncaughtException(Thread.java:1964) >>> >>> "Thread-6" prio=10 tid=0x0a022000 nid=0x3c2f waiting for monitor entry >>> [0xd0256000] >>> java.lang.Thread.State: BLOCKED (on object monitor) >>> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942) >>> - waiting to lock <0xea766988> (a >>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup) >>> at java.lang.Thread.exit(Thread.java:732) >>> >>> "SameVMThread" prio=10 tid=0xd058a000 nid=0x3c2e waiting for monitor >>> entry [0xd02a6000] >>> java.lang.Thread.State: BLOCKED (on object monitor) >>> at java.lang.ThreadGroup.add(ThreadGroup.java:885) >>> - waiting to lock <0xea766988> (a >>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup) >>> at java.lang.Thread.start(Thread.java:687) >>> - locked <0xea790160> (a Bug6989440$TestThread) >>> at Bug6989440.main(Bug6989440.java:47) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> >>> >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> >>> >>> at java.lang.reflect.Method.invoke(Method.java:601) >>> at >>> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) >>> >>> >>> at java.lang.Thread.run(Thread.java:722) >>> ..... >>> >>> >>> -Chris. >>> >>>> >>>> -Alan. From xueming.shen at oracle.com Tue Oct 11 17:49:01 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 11 Oct 2011 10:49:01 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E942A59.5070006@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E942A59.5070006@gmx.de> Message-ID: <4E94818D.2020800@oracle.com> On 10/11/2011 04:36 AM, Ulf Zibis wrote: > Am 30.09.2011 22:46, schrieb Xueming Shen: >> >> I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to >> 2009(?) because >> the benchmark shows the "shift" version is slightly faster. Do you >> have any number >> shows any difference now. My non-scientific benchmark still suggests >> the "shift" >> type is faster on -server vm, no significant difference on -client vm. >> > In this sense, then you should do the same here: > 87 private static boolean isNotContinuation(int b) { > 88 return (b >> 6) != -2; > 89 } I don't know which one is better, I did a run on private static boolean op1(int b) { return (b >> 6) != -2; } private static boolean op2(int b) { return (b & 0xc0) != 0x80; } private static boolean op3(byte b) { return b >= (byte)0xc0; } with 1000000 iteration on my linux machine, and got the scores op1=1149 op2=1147 op3=1146 I would interpret it as they are identical. > > > Additionally: > Make private: > 75 private static final void updatePositions( > 76 Buffer src, int sp, Buffer dst, int dp) { > updated accordingly -Sherman From weijun.wang at oracle.com Tue Oct 11 19:15:18 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2011 12:15:18 -0700 Subject: detect server VM in reg test? Message-ID: <4E9495C6.4030504@oracle.com> Hi All I have a test consuming quite a lot of memory and seems to be only working on server vms. I've added String vm = System.getProperty("java.vm.name"); if (!vm.equals("Java HotSpot(TM) Server VM")) { System.out.println("The test only runs on server VMs"); return; } Is there a better way to detect it? Thanks Max From david.holmes at oracle.com Tue Oct 11 21:34:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 07:34:12 +1000 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <20111011133426.17233w67936hkzia@webmail.nine.ch> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> <20111011133426.17233w67936hkzia@webmail.nine.ch> Message-ID: <4E94B654.8060600@oracle.com> On 11/10/2011 9:34 PM, Patrick Reinhart wrote: > Hi David, > > Well in the case of a "normal" Stream you are absolutely right, but in > the Throwable case it's a PrintStream (or PrintWriter) with both do > implement the java.lang.Appendable interface (as introduced in 1.5). > This interface defines the append() method suggested in my examples. Well what do you know! My apologies. David ------ > Cheers > > Patrick "Reini" Reinhart > > Zitat von "David Holmes" : > >> Hi Patrick, >> >> >> On 11/10/2011 3:39 PM, Patrick Reinhart wrote: >>> >>> In my opinion, this could be even written in this ways: >>> >>> for (StackTraceElement traceElement : trace) >>> s.append("\tat ").println(traceElement); >> >> I think you are confusing your streams and your StringBuilders - s is >> a stream. >> >> David >> >> >>> >>> and Similarly for: >>> >>> for (int i = 0; i <= m; i++) >>> s.append(prefix).append("\tat ").println(trace[i]); >>> >>> and the change would be only on one line ;-) >>> >>> Cheers, >>> >>> Patrick "Reini" Reinhart >>> > > From david.holmes at oracle.com Tue Oct 11 21:51:13 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 07:51:13 +1000 Subject: detect server VM in reg test? In-Reply-To: <4E9495C6.4030504@oracle.com> References: <4E9495C6.4030504@oracle.com> Message-ID: <4E94BA51.6090804@oracle.com> Hi Max, On 12/10/2011 5:15 AM, Weijun Wang wrote: > I have a test consuming quite a lot of memory and seems to be only > working on server vms. I've added > > String vm = System.getProperty("java.vm.name"); > if (!vm.equals("Java HotSpot(TM) Server VM")) { > System.out.println("The test only runs on server VMs"); > return; > } > > Is there a better way to detect it? Searching for contains("Server") would be less error-prone as the above will not work on 64-bit. But there is a better property to use: sun.management.compiler which will report eg "Hotspot Client Compiler". However, these days both properties might report Tiered rather than Server. Also for -Xint sun.management.compiler doesn't exist. That all said this seems like the wrong solution to the problem. Amount of memory used shouldn't be that dependent on client vs. server VM David From weijun.wang at oracle.com Tue Oct 11 22:21:37 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2011 15:21:37 -0700 Subject: detect server VM in reg test? In-Reply-To: <4E94BA51.6090804@oracle.com> References: <4E9495C6.4030504@oracle.com> <4E94BA51.6090804@oracle.com> Message-ID: <4E94C171.6080503@oracle.com> On 10/11/2011 2:51 PM, David Holmes wrote: > Hi Max, > > On 12/10/2011 5:15 AM, Weijun Wang wrote: >> I have a test consuming quite a lot of memory and seems to be only >> working on server vms. I've added >> >> String vm = System.getProperty("java.vm.name"); >> if (!vm.equals("Java HotSpot(TM) Server VM")) { >> System.out.println("The test only runs on server VMs"); >> return; >> } >> >> Is there a better way to detect it? > > Searching for contains("Server") would be less error-prone as the above > will not work on 64-bit. But there is a better property to use: > > sun.management.compiler > > which will report eg "Hotspot Client Compiler". However, these days both > properties might report Tiered rather than Server. Also for -Xint > sun.management.compiler doesn't exist. I'll use System.getProperty("java.vm.name").contains("Server") now since that looks more intuitive for me. > > That all said this seems like the wrong solution to the problem. Amount > of memory used shouldn't be that dependent on client vs. server VM I don't know. But here is my JPRT output http://javaweb/~ww155710/jprt/bigcrl/report.html The test BigCRL fails on all c1 (without*) and succeeds on all c2 (with*). It does look like it's easy to get more memory from c2. Thanks Max > > David From mike.skells at talk21.com Wed Oct 12 00:05:13 2011 From: mike.skells at talk21.com (Mike Skells) Date: Wed, 12 Oct 2011 01:05:13 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E941786.8090709@oracle.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> Message-ID: <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> Hi David, Patrick, re explicit StringBuilders I did try that but the overheads of calling the?PrintStreamOrWriter are minimally about the same ( for a StringWriter that I use for the test) but this will clearly depend on the writer that you are using. In my config the end result was slower than what I presented I did also consider batching multiple lines together but this requires the Throwable to take control of the line endings rather than delegating it to the streams, event though this is a cut across the concerns, but it was slower than what I presented? I also tried making?PrintStreamOrWriter extend AbstractStringBuffer and writing to it directly, and then flushing, but again this did not achieve any better results The majority of the CPu reduction comes from removing the creation of implicit StringBuilders and their resizing Patrick?- this is why you idea doesn't really provide the answer, there is still a StringBuilder created for each line of stack trace printed, and probably a resize as the line is probably > 16 chars, as well as 2 writes for each line regards Mike >________________________________ >From: David Holmes >To: Patrick Reinhart >Cc: mike.skells at talk21.com; "core-libs-dev at openjdk.java.net" >Sent: Tuesday, 11 October 2011, 11:16 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > >Hi Patrick, > > >On 11/10/2011 3:39 PM, Patrick Reinhart wrote: >> >> In my opinion, this could be even written in this ways: >> >> for (StackTraceElement traceElement : trace) >> s.append("\tat ").println(traceElement); > >I think you are confusing your streams and your StringBuilders - s is a >stream. > >David > > >> >> and Similarly for: >> >> for (int i = 0; i <= m; i++) >> s.append(prefix).append("\tat ").println(trace[i]); >> >> and the change would be only on one line ;-) >> >> Cheers, >> >> Patrick "Reini" Reinhart >> >> >> >> Am 11.10.11 01:12, schrieb David Holmes: >>> Hi Mike, >>> >>> I have one question. In part the existing code tends to use a single >>> println with multiple string concatenations. Your changes optimize the >>> string operations by using explicit, rather than implicit >>> StringBuilders. Did you consider instead/aso using multiple print >>> statmements top avoid the need for doing the concatenation in the >>> first place? Eg: >>> >>> for (StackTraceElement traceElement : trace) >>> s.println("\tat " + traceElement); >>> >>> becomes >>> >>> for (StackTraceElement traceElement : trace) { >>> s.print("\tat "); >>> s.println(traceElement); >>> } >>> >>> Similarly for: >>> >>> for (int i = 0; i <= m; i++) >>> s.println(prefix + "\tat " + trace[i]); >>> >>> >>> Cheers, >>> David Holmes >>> >>> On 11/10/2011 8:30 AM, Mike Skells wrote: >>>> Hi All, >>>> Last attempt - hopefully >>>> >>>> with all 3 files, a patch, test case and results. The patch and >>>> results are text format to avoid the filters on this list >>>> >>>> Hopefully you are not all to irritated with this posting to review it >>>> :-) >>>> >>>> Regards >>>> Mike >>>> >>>> >>>>> ________________________________ >>>>> From: Mike Skells >>>>> To: Core-Libs-Dev >>>>> Sent: Monday, 10 October 2011, 22:39 >>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>>> usage) >>>>> >>>>> Hi All, >>>>> Trying to request a review again with different file types >>>>> >>>>> hopefully it will get through the filter >>>>> >>>>> Regards >>>>> Mike >>>>> >>>>> >>>>> >>>>>> ________________________________ >>>>>> From: Mike Skells >>>>>> To: Mike Skells; Alan >>>>>> Bateman >>>>>> Cc: Core-Libs-Dev >>>>>> Sent: Monday, 10 October 2011, 9:17 >>>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>>>> usage) >>>>>> >>>>>> >>>>>> The patch (.patch) and results (.xlsx) seem to be filtered out. >>>>>> What is the best format to submit files to avoid list filtering >>>>>> attachments? >>>>>> >>>>>> >>>>>> >>>>>>> ________________________________ >>>>>>> From: Mike Skells >>>>>>> To: Alan Bateman >>>>>>> Cc: Core-Libs-Dev >>>>>>> Sent: Monday, 10 October 2011, 8:53 >>>>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU >>>>>>> usage) >>>>>>> >>>>>>> Doh, >>>>>>> This time with the patches, test code, and CPU usage stats attached >>>>>>> >>>>>>> Regard >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: Alan Bateman >>>>>>>> To: mike.skells at talk21.com >>>>>>>> Cc: Core-Libs-Dev >>>>>>>> Sent: Monday, 10 October 2011, 0:15 >>>>>>>> Subject: Re: Patch to Throwable and StackTraceElement (reduced >>>>>>>> CPU usage) >>>>>>>> >>>>>>>> mike.skells at talk21.com wrote: >>>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> I include the patch, a micro-benchmark and the results of the >>>>>>>>> micro-benchmark which show an improvement of 80% throughput (ie >>>>>>>>> it is almost twice as fast) >>>>>>>>> >>>>>>>> Mike - I don't think there is a patch attached to your mail. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >> > > > From david.holmes at oracle.com Wed Oct 12 00:34:47 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 10:34:47 +1000 Subject: detect server VM in reg test? In-Reply-To: <4E94C171.6080503@oracle.com> References: <4E9495C6.4030504@oracle.com> <4E94BA51.6090804@oracle.com> <4E94C171.6080503@oracle.com> Message-ID: <4E94E0A7.2090602@oracle.com> On 12/10/2011 8:21 AM, Weijun Wang wrote: > On 10/11/2011 2:51 PM, David Holmes wrote: >> Searching for contains("Server") would be less error-prone as the above >> will not work on 64-bit. But there is a better property to use: >> >> sun.management.compiler >> >> which will report eg "Hotspot Client Compiler". However, these days both >> properties might report Tiered rather than Server. Also for -Xint >> sun.management.compiler doesn't exist. > > I'll use System.getProperty("java.vm.name").contains("Server") now since > that looks more intuitive for me. > >> >> That all said this seems like the wrong solution to the problem. Amount >> of memory used shouldn't be that dependent on client vs. server VM > > I don't know. But here is my JPRT output > > http://javaweb/~ww155710/jprt/bigcrl/report.html > > The test BigCRL fails on all c1 (without*) and succeeds on all c2 > (with*). It does look like it's easy to get more memory from c2. Ah! It's different ergomics settings for client vs server. You are getting different heap size (larger for server) and possibly different GC - but I think it is the default heap size that is tripping up your test. David > Thanks > Max > >> >> David From Alan.Bateman at oracle.com Wed Oct 12 00:48:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Oct 2011 01:48:57 +0100 Subject: detect server VM in reg test? In-Reply-To: <4E94C171.6080503@oracle.com> References: <4E9495C6.4030504@oracle.com> <4E94BA51.6090804@oracle.com> <4E94C171.6080503@oracle.com> Message-ID: <4E94E3F9.5040802@oracle.com> Weijun Wang wrote: > > : > > The test BigCRL fails on all c1 (without*) and succeeds on all c2 > (with*). It does look like it's easy to get more memory from c2. Have you considered passing the max heap size to the @run tag so that you aren't dependent on the default heap size? -Alan. From david.holmes at oracle.com Wed Oct 12 00:55:58 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 10:55:58 +1000 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> Message-ID: <4E94E59E.1010100@oracle.com> Hi Mike, On 12/10/2011 10:05 AM, Mike Skells wrote: > The majority of the CPu reduction comes from removing the creation of > implicit StringBuilders and their resizing > > Patrick - this is why you idea doesn't really provide the answer, there > is still a StringBuilder created for each line of stack trace printed, > and probably a resize as the line is probably > 16 chars, as well as 2 > writes for each line Ah I see. I missed the key point that you now use a single SB across the entire process of printing the stacktrace. I guess my only additional comment on that is that it would seem to be be a good idea to increase the initial size of that single SB as it is likely to grow on its very first use. Also a minor gain might be had to change println(sb) to be println(sb.toString()) and avoid the String.valueOf intermediate call (and null check). Aside: can't help but feel that the streams should directly support CharSequences so that we don't need to convert to intermediate Strings. Cheers, David From littlee at linux.vnet.ibm.com Wed Oct 12 06:26:08 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 12 Oct 2011 14:26:08 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 Message-ID: <4E953300.9000208@linux.vnet.ibm.com> Hi guys, sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have changed them to unistd.h and fcntl.h. The patch has been tested on both linux and aix. I also change the header file in solaris, though I do not have a solaris machine on the hand. Hope it will not break the build :-) The patch and webrev has been attached. -- Yours Charles From littlee at linux.vnet.ibm.com Wed Oct 12 07:08:56 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 12 Oct 2011 15:08:56 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E953300.9000208@linux.vnet.ibm.com> References: <4E953300.9000208@linux.vnet.ibm.com> Message-ID: <4E953D08.5090009@linux.vnet.ibm.com> On 10/12/2011 02:26 PM, Charles Lee wrote: > Hi guys, > > sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to > the POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I > have changed them to unistd.h and fcntl.h. The patch has been tested > on both linux and aix. > > I also change the header file in solaris, though I do not have a > solaris machine on the hand. Hope it will not break the build :-) > > The patch and webrev has been attached. > The attachment seems to be filtered. Try to attach webrev again. -- Yours Charles From david.holmes at oracle.com Wed Oct 12 07:12:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 17:12:12 +1000 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E953300.9000208@linux.vnet.ibm.com> References: <4E953300.9000208@linux.vnet.ibm.com> Message-ID: <4E953DCC.5060600@oracle.com> Hi Charles, On 12/10/2011 4:26 PM, Charles Lee wrote: > sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the > POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have > changed them to unistd.h and fcntl.h. The patch has been tested on both > linux and aix. > > I also change the header file in solaris, though I do not have a solaris > machine on the hand. Hope it will not break the build :-) unistd.h and fcntl.h are already used extensively on Solaris > The patch and webrev has been attached. Looks like they were stripped of the email. (And of the second attempt.) By grepping I assume the splashscreen_config.h file is one place this was fixed for unistd.h. It is interesting to note that in some cases at least (eg splashscreen_sys.c) the C file includes anyway. We'll need to verify the changes for in the genUnixConstants code. There tends to be a reason (often historical and possibly no longer applicable) for using the sys variants (though sometimes it was just that the non-sys version didn't exist at some point in time). Cheers, David Holmes From littlee at linux.vnet.ibm.com Wed Oct 12 07:23:18 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 12 Oct 2011 15:23:18 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E953DCC.5060600@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> Message-ID: <4E954066.9030001@linux.vnet.ibm.com> On 10/12/2011 03:12 PM, David Holmes wrote: > Hi Charles, > > On 12/10/2011 4:26 PM, Charles Lee wrote: >> sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the >> POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have >> changed them to unistd.h and fcntl.h. The patch has been tested on both >> linux and aix. >> >> I also change the header file in solaris, though I do not have a solaris >> machine on the hand. Hope it will not break the build :-) > > unistd.h and fcntl.h are already used extensively on Solaris > >> The patch and webrev has been attached. > > Looks like they were stripped of the email. (And of the second attempt.) > > By grepping I assume the splashscreen_config.h file is one place this > was fixed for unistd.h. It is interesting to note that in some cases > at least (eg splashscreen_sys.c) the C file includes anyway. Yes. Only splashscreen_config.h has > > We'll need to verify the changes for in the > genUnixConstants code. There tends to be a reason (often historical > and possibly no longer applicable) for using the sys variants (though > sometimes it was just that the non-sys version didn't exist at some > point in time). > By grep, only genUnixConstants.c and genSolarisConstants.c use in the jdk repository. And more than 20 files use > Cheers, > David Holmes Trying to attach a plain diff file again and again.... -- Yours Charles From david.holmes at oracle.com Wed Oct 12 07:36:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Oct 2011 17:36:12 +1000 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E954066.9030001@linux.vnet.ibm.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E954066.9030001@linux.vnet.ibm.com> Message-ID: <4E95436C.10307@oracle.com> On 12/10/2011 5:23 PM, Charles Lee wrote: > On 10/12/2011 03:12 PM, David Holmes wrote: >> On 12/10/2011 4:26 PM, Charles Lee wrote: >>> sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the >>> POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have >>> changed them to unistd.h and fcntl.h. The patch has been tested on both >>> linux and aix. >>> >>> I also change the header file in solaris, though I do not have a solaris >>> machine on the hand. Hope it will not break the build :-) >> >> unistd.h and fcntl.h are already used extensively on Solaris >> >>> The patch and webrev has been attached. >> >> Looks like they were stripped of the email. (And of the second attempt.) >> >> By grepping I assume the splashscreen_config.h file is one place this >> was fixed for unistd.h. It is interesting to note that in some cases >> at least (eg splashscreen_sys.c) the C file includes anyway. > > Yes. Only splashscreen_config.h has Ok. I've cc'ed awt-dev as this is awt code. >> >> We'll need to verify the changes for in the >> genUnixConstants code. There tends to be a reason (often historical >> and possibly no longer applicable) for using the sys variants (though >> sometimes it was just that the non-sys version didn't exist at some >> point in time). >> > > By grep, only genUnixConstants.c and genSolarisConstants.c use > in the jdk repository. And more than 20 files use Yep. And the fcntl manpage on Solaris says to #include and - so I think we're okay there. I suspect Solaris 8 may be a different story but that's only an issue for JDK6. David >> Cheers, >> David Holmes > > Trying to attach a plain diff file again and again.... > Patch inlined for AWT-dev folk to see. diff --git src/solaris/native/sun/awt/splashscreen/splashscreen_config.h src/solaris/native/sun/awt/splashscreen/splashscreen_config.h index bb03165..e312c2b 100644 --- src/solaris/native/sun/awt/splashscreen/splashscreen_config.h +++ src/solaris/native/sun/awt/splashscreen/splashscreen_config.h @@ -32,7 +32,7 @@ #include #include #include -#include +#include #include #include #include diff --git src/solaris/native/sun/nio/fs/genSolarisConstants.c src/solaris/native/sun/nio/fs/genSolarisConstants.c index df46398..346bfbb 100644 --- src/solaris/native/sun/nio/fs/genSolarisConstants.c +++ src/solaris/native/sun/nio/fs/genSolarisConstants.c @@ -27,7 +27,7 @@ #include #include #include -#include +#include #include /** diff --git src/solaris/native/sun/nio/fs/genUnixConstants.c src/solaris/native/sun/nio/fs/genUnixConstants.c index ea48d4d..56984a7 100644 --- src/solaris/native/sun/nio/fs/genUnixConstants.c +++ src/solaris/native/sun/nio/fs/genUnixConstants.c @@ -26,7 +26,7 @@ #include #include #include -#include +#include #include /** From littlee at linux.vnet.ibm.com Wed Oct 12 07:52:50 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 12 Oct 2011 15:52:50 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E95436C.10307@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E954066.9030001@linux.vnet.ibm.com> <4E95436C.10307@oracle.com> Message-ID: <4E954752.4070306@linux.vnet.ibm.com> On 10/12/2011 03:36 PM, David Holmes wrote: > On 12/10/2011 5:23 PM, Charles Lee wrote: >> On 10/12/2011 03:12 PM, David Holmes wrote: >>> On 12/10/2011 4:26 PM, Charles Lee wrote: >>>> sys/unistd.h, sys/fcntl.h are not supported in AIX. And according >>>> to the >>>> POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I >>>> have >>>> changed them to unistd.h and fcntl.h. The patch has been tested on >>>> both >>>> linux and aix. >>>> >>>> I also change the header file in solaris, though I do not have a >>>> solaris >>>> machine on the hand. Hope it will not break the build :-) >>> >>> unistd.h and fcntl.h are already used extensively on Solaris >>> >>>> The patch and webrev has been attached. >>> >>> Looks like they were stripped of the email. (And of the second >>> attempt.) >>> >>> By grepping I assume the splashscreen_config.h file is one place this >>> was fixed for unistd.h. It is interesting to note that in some cases >>> at least (eg splashscreen_sys.c) the C file includes anyway. >> >> Yes. Only splashscreen_config.h has > > Ok. I've cc'ed awt-dev as this is awt code. > >>> >>> We'll need to verify the changes for in the >>> genUnixConstants code. There tends to be a reason (often historical >>> and possibly no longer applicable) for using the sys variants (though >>> sometimes it was just that the non-sys version didn't exist at some >>> point in time). >>> >> >> By grep, only genUnixConstants.c and genSolarisConstants.c use >> in the jdk repository. And more than 20 files use >> > > Yep. And the fcntl manpage on Solaris says to #include and > - so I think we're okay there. I suspect Solaris 8 may be a > different story but that's only an issue for JDK6. > > David > >>> Cheers, >>> David Holmes >> >> Trying to attach a plain diff file again and again.... >> > Patch inlined for AWT-dev folk to see. > > diff --git > src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > index bb03165..e312c2b 100644 > --- src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > +++ src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > @@ -32,7 +32,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > diff --git src/solaris/native/sun/nio/fs/genSolarisConstants.c > src/solaris/native/sun/nio/fs/genSolarisConstants.c > index df46398..346bfbb 100644 > --- src/solaris/native/sun/nio/fs/genSolarisConstants.c > +++ src/solaris/native/sun/nio/fs/genSolarisConstants.c > @@ -27,7 +27,7 @@ > #include > #include > #include > -#include > +#include > #include > > /** > diff --git src/solaris/native/sun/nio/fs/genUnixConstants.c > src/solaris/native/sun/nio/fs/genUnixConstants.c > index ea48d4d..56984a7 100644 > --- src/solaris/native/sun/nio/fs/genUnixConstants.c > +++ src/solaris/native/sun/nio/fs/genUnixConstants.c > @@ -26,7 +26,7 @@ > #include > #include > #include > -#include > +#include > #include > > /** > Wow. Thank you David. -- Yours Charles From mike.skells at talk21.com Wed Oct 12 08:16:13 2011 From: mike.skells at talk21.com (mike.skells at talk21.com) Date: Wed, 12 Oct 2011 09:16:13 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) Message-ID: <1318407373.59328.androidMobile@web86604.mail.ird.yahoo.com> Hi David I will update and retest by the end of week Regards Mike From patrick at reini.net Wed Oct 12 08:28:49 2011 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 12 Oct 2011 10:28:49 +0200 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E94E59E.1010100@oracle.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> <4E94E59E.1010100@oracle.com> Message-ID: <20111012102849.12531k3qqspae56p@webmail.nine.ch> Hi Mike Zitat von "David Holmes" : >> Patrick - this is why you idea doesn't really provide the answer, there >> is still a StringBuilder created for each line of stack trace printed, >> and probably a resize as the line is probably > 16 chars, as well as 2 >> writes for each line Ups, I missed the toString() part of the StackTraceElement - shame on me :-) What if you would define a java.lang.Appendable implementation instead of StringBuilder in your StackStraceElement.appendTo() method. You would then be able to write the Throwable print stacktrace methods it this way: for (StackTraceElement traceElement : trace) s.append("\tat "); tranceElement.appendTo(s); s.println(); and Similarly for: for (int i = 0; i <= m; i++) s.append(prefix).append("\tat "); tranceElement.appendTo(trace[i]); s.println(); In this case you would pass the actual PrintStream/Writer instance instead of creating new StringBuilders at all and your toString() method using a new StringBuilder still would work the same way. Or did I still miss something? Cheers, Patrick "Reini" Reinhart > > Ah I see. I missed the key point that you now use a single SB across > the entire process of printing the stacktrace. I guess my only > additional comment on that is that it would seem to be be a good > idea to increase the initial size of that single SB as it is likely > to grow on its very first use. > > Also a minor gain might be had to change println(sb) to be > println(sb.toString()) and avoid the String.valueOf intermediate > call (and null check). > > Aside: can't help but feel that the streams should directly support > CharSequences so that we don't need to convert to intermediate > Strings. > > > Cheers, > David > From xuelei.fan at oracle.com Wed Oct 12 09:11:48 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 12 Oct 2011 09:11:48 +0000 Subject: hg: jdk8/tl/jdk: 7092375: Security Libraries don't build with javac -Werror Message-ID: <20111012091207.D105347F6C@hg.openjdk.java.net> Changeset: ffa762153af4 Author: xuelei Date: 2011-09-28 15:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffa762153af4 7092375: Security Libraries don't build with javac -Werror Summary: Changes to security related java and make files to remove warnings Reviewed-by: xuelei Contributed-by: kurchi.subhra.hazra at oracle.com ! make/java/security/Makefile ! make/javax/Makefile ! make/javax/others/Makefile + make/javax/security/Makefile ! make/org/ietf/jgss/Makefile ! make/sun/security/other/Makefile ! src/share/classes/java/security/Signature.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/auth/x500/X500Principal.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/CertificateParsingException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! src/share/classes/sun/security/x509/X509CertImpl.java From anthony.petrov at oracle.com Wed Oct 12 09:34:18 2011 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 12 Oct 2011 13:34:18 +0400 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E95436C.10307@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E954066.9030001@linux.vnet.ibm.com> <4E95436C.10307@oracle.com> Message-ID: <4E955F1A.6010501@oracle.com> Changes to the splashscreen_config.h look fine. Thanks. -- best regards, Anthony On 10/12/2011 11:36 AM, David Holmes wrote: > On 12/10/2011 5:23 PM, Charles Lee wrote: >> On 10/12/2011 03:12 PM, David Holmes wrote: >>> On 12/10/2011 4:26 PM, Charles Lee wrote: >>>> sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to >>>> the >>>> POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have >>>> changed them to unistd.h and fcntl.h. The patch has been tested on both >>>> linux and aix. >>>> >>>> I also change the header file in solaris, though I do not have a >>>> solaris >>>> machine on the hand. Hope it will not break the build :-) >>> >>> unistd.h and fcntl.h are already used extensively on Solaris >>> >>>> The patch and webrev has been attached. >>> >>> Looks like they were stripped of the email. (And of the second attempt.) >>> >>> By grepping I assume the splashscreen_config.h file is one place this >>> was fixed for unistd.h. It is interesting to note that in some cases >>> at least (eg splashscreen_sys.c) the C file includes anyway. >> >> Yes. Only splashscreen_config.h has > > Ok. I've cc'ed awt-dev as this is awt code. > >>> >>> We'll need to verify the changes for in the >>> genUnixConstants code. There tends to be a reason (often historical >>> and possibly no longer applicable) for using the sys variants (though >>> sometimes it was just that the non-sys version didn't exist at some >>> point in time). >>> >> >> By grep, only genUnixConstants.c and genSolarisConstants.c use >> in the jdk repository. And more than 20 files use > > Yep. And the fcntl manpage on Solaris says to #include and > - so I think we're okay there. I suspect Solaris 8 may be a > different story but that's only an issue for JDK6. > > David > >>> Cheers, >>> David Holmes >> >> Trying to attach a plain diff file again and again.... >> > Patch inlined for AWT-dev folk to see. > > diff --git src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > index bb03165..e312c2b 100644 > --- src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > +++ src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > @@ -32,7 +32,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > diff --git src/solaris/native/sun/nio/fs/genSolarisConstants.c > src/solaris/native/sun/nio/fs/genSolarisConstants.c > index df46398..346bfbb 100644 > --- src/solaris/native/sun/nio/fs/genSolarisConstants.c > +++ src/solaris/native/sun/nio/fs/genSolarisConstants.c > @@ -27,7 +27,7 @@ > #include > #include > #include > -#include > +#include > #include > > /** > diff --git src/solaris/native/sun/nio/fs/genUnixConstants.c > src/solaris/native/sun/nio/fs/genUnixConstants.c > index ea48d4d..56984a7 100644 > --- src/solaris/native/sun/nio/fs/genUnixConstants.c > +++ src/solaris/native/sun/nio/fs/genUnixConstants.c > @@ -26,7 +26,7 @@ > #include > #include > #include > -#include > +#include > #include > > /** From Alan.Bateman at oracle.com Wed Oct 12 14:16:16 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Oct 2011 15:16:16 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E953DCC.5060600@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> Message-ID: <4E95A130.80903@oracle.com> David Holmes wrote: > : > > We'll need to verify the changes for in the > genUnixConstants code. There tends to be a reason (often historical > and possibly no longer applicable) for using the sys variants (though > sometimes it was just that the non-sys version didn't exist at some > point in time). This one is just an oversight, it can be changed to fcntl.h. There is another one in genSolarisConstants.c that can also be changed but that one is probably not an issue for AIX as that source file is Solaris specific. I've created a bug to track this: 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h -Alan. From naoto.sato at oracle.com Wed Oct 12 19:13:38 2011 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 12 Oct 2011 19:13:38 +0000 Subject: hg: jdk8/tl/jdk: 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Message-ID: <20111012191400.22A9A47FAA@hg.openjdk.java.net> Changeset: 829c3a8d23fa Author: naoto Date: 2011-10-12 12:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/829c3a8d23fa 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: dholmes, chegar ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java From littlee at linux.vnet.ibm.com Thu Oct 13 04:54:51 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Thu, 13 Oct 2011 12:54:51 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E95A130.80903@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> Message-ID: <4E966F1B.5040107@linux.vnet.ibm.com> On 10/12/2011 10:16 PM, Alan Bateman wrote: > David Holmes wrote: >> : >> >> We'll need to verify the changes for in the >> genUnixConstants code. There tends to be a reason (often historical >> and possibly no longer applicable) for using the sys variants (though >> sometimes it was just that the non-sys version didn't exist at some >> point in time). > This one is just an oversight, it can be changed to fcntl.h. There is > another one in genSolarisConstants.c that can also be changed but that > one is probably not an issue for AIX as that source file is Solaris > specific. > > I've created a bug to track this: > 7100054: (porting) Native code should include fcntl.h and unistd.h > rather than sys/fcntl.h and sys/unistd.h > > -Alan. > Thanks Alan. Below is the patch I am failed to attach. It is trivial... By the way, is there any network problem in openjdk these days? I used to attach a webrev successfully, but fail now for many many attempts. The webrev is only 76k big... diff --git src/solaris/native/sun/awt/splashscreen/splashscreen_config.h src/solaris/native/sun/awt/splashscreen/splashscreen_config.h index bb03165..e312c2b 100644 --- src/solaris/native/sun/awt/splashscreen/splashscreen_config.h +++ src/solaris/native/sun/awt/splashscreen/splashscreen_config.h @@ -32,7 +32,7 @@ #include #include #include -#include +#include #include #include #include diff --git src/solaris/native/sun/nio/fs/genSolarisConstants.c src/solaris/native/sun/nio/fs/genSolarisConstants.c index df46398..346bfbb 100644 --- src/solaris/native/sun/nio/fs/genSolarisConstants.c +++ src/solaris/native/sun/nio/fs/genSolarisConstants.c @@ -27,7 +27,7 @@ #include #include #include -#include +#include #include /** diff --git src/solaris/native/sun/nio/fs/genUnixConstants.c src/solaris/native/sun/nio/fs/genUnixConstants.c index ea48d4d..56984a7 100644 --- src/solaris/native/sun/nio/fs/genUnixConstants.c +++ src/solaris/native/sun/nio/fs/genUnixConstants.c @@ -26,7 +26,7 @@ #include #include #include -#include +#include #include /** -- Yours Charles From david.holmes at oracle.com Thu Oct 13 05:11:08 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Oct 2011 15:11:08 +1000 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E966F1B.5040107@linux.vnet.ibm.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> Message-ID: <4E9672EC.2010201@oracle.com> Hi Charles, On 13/10/2011 2:54 PM, Charles Lee wrote: > Thanks Alan. Below is the patch I am failed to attach. It is trivial... Do you need someone to sponsor this for you, or are you able to drive this via other IBM folk that can generate webrevs on cr.openjdk.java.net and ultimately do the push? > By the way, is there any network problem in openjdk these days? I used > to attach a webrev successfully, but fail now for many many attempts. > The webrev is only 76k big... I reported this on the web-discuss list and a couple of tweaks have been made to the mailman settings. Can you try again? If it fails can you point me to a posting where you did attach the webrev successfully and then someone will be able to compare the two situations. Thanks, David > diff --git src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > index bb03165..e312c2b 100644 > --- src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > +++ src/solaris/native/sun/awt/splashscreen/splashscreen_config.h > @@ -32,7 +32,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > diff --git src/solaris/native/sun/nio/fs/genSolarisConstants.c > src/solaris/native/sun/nio/fs/genSolarisConstants.c > index df46398..346bfbb 100644 > --- src/solaris/native/sun/nio/fs/genSolarisConstants.c > +++ src/solaris/native/sun/nio/fs/genSolarisConstants.c > @@ -27,7 +27,7 @@ > #include > #include > #include > -#include > +#include > #include > > /** > diff --git src/solaris/native/sun/nio/fs/genUnixConstants.c > src/solaris/native/sun/nio/fs/genUnixConstants.c > index ea48d4d..56984a7 100644 > --- src/solaris/native/sun/nio/fs/genUnixConstants.c > +++ src/solaris/native/sun/nio/fs/genUnixConstants.c > @@ -26,7 +26,7 @@ > #include > #include > #include > -#include > +#include > #include > > /** > From littlee at linux.vnet.ibm.com Thu Oct 13 08:03:47 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Thu, 13 Oct 2011 16:03:47 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E9672EC.2010201@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> Message-ID: <4E969B63.8030600@linux.vnet.ibm.com> On 10/13/2011 01:11 PM, David Holmes wrote: > Hi Charles, > > On 13/10/2011 2:54 PM, Charles Lee wrote: >> Thanks Alan. Below is the patch I am failed to attach. It is trivial... > > Do you need someone to sponsor this for you, or are you able to drive > this via other IBM folk that can generate webrevs on > cr.openjdk.java.net and ultimately do the push? Neil may help me with generating webrevs on cr.openjdk.java.net. > >> By the way, is there any network problem in openjdk these days? I used >> to attach a webrev successfully, but fail now for many many attempts. >> The webrev is only 76k big... > > I reported this on the web-discuss list and a couple of tweaks have > been made to the mailman settings. Can you try again? If it fails can > you point me to a posting where you did attach the webrev successfully > and then someone will be able to compare the two situations. Trying to attach the webrev. If fail, please check the thread http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001755.html . I used to attach a webrev successfully on the swing-dev mailing list. > > Thanks, > David > >> diff --git src/solaris/native/sun/awt/splashscreen/splashscreen_config.h >> src/solaris/native/sun/awt/splashscreen/splashscreen_config.h >> index bb03165..e312c2b 100644 >> --- src/solaris/native/sun/awt/splashscreen/splashscreen_config.h >> +++ src/solaris/native/sun/awt/splashscreen/splashscreen_config.h >> @@ -32,7 +32,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> #include >> #include >> #include >> diff --git src/solaris/native/sun/nio/fs/genSolarisConstants.c >> src/solaris/native/sun/nio/fs/genSolarisConstants.c >> index df46398..346bfbb 100644 >> --- src/solaris/native/sun/nio/fs/genSolarisConstants.c >> +++ src/solaris/native/sun/nio/fs/genSolarisConstants.c >> @@ -27,7 +27,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> #include >> >> /** >> diff --git src/solaris/native/sun/nio/fs/genUnixConstants.c >> src/solaris/native/sun/nio/fs/genUnixConstants.c >> index ea48d4d..56984a7 100644 >> --- src/solaris/native/sun/nio/fs/genUnixConstants.c >> +++ src/solaris/native/sun/nio/fs/genUnixConstants.c >> @@ -26,7 +26,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> #include >> >> /** >> > -- Yours Charles From neil.richards at ngmr.net Thu Oct 13 12:22:02 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 13 Oct 2011 13:22:02 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E9672EC.2010201@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> Message-ID: <1318508522.5288.82.camel@chalkhill> On Thu, 2011-10-13 at 15:11 +1000, David Holmes wrote: > Hi Charles, > > On 13/10/2011 2:54 PM, Charles Lee wrote: > > Thanks Alan. Below is the patch I am failed to attach. It is trivial... > > Do you need someone to sponsor this for you, or are you able to drive > this via other IBM folk that can generate webrevs on cr.openjdk.java.net > and ultimately do the push? > Hi David, "As if by magic, the shopkeeper appeared." [1] For ease of review, I've uploaded the suggested changes onto cr.openjdk.java.net as two webrevs, one for awt [2], the other for tl [3]. I'll be happy to push the changes, too. Will there need to be two bug numbers for this: one for awt & one for tl ? I'm currently laboring under the (mistaken?) belief that it's easier (read: swifter) for Oracle folk to drive the mechanics of getting Java bugs raised for these items than for "outsiders" to do so. If this is so, could you do this bit of bookkeeping for me, and let me know the bug numbers / abstracts to slot into changes ? (Feel free to disabuse me of this belief if you think it is unfounded). Thanks, Neil [1] http://en.wikipedia.org/wiki/Mr_Benn [2] http://cr.openjdk.java.net/~ngmr/ojdk-243.1/webrev.01/ [3] http://cr.openjdk.java.net/~ngmr/ojdk-243.2/webrev.00/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Thu Oct 13 12:43:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Oct 2011 13:43:57 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <1318508522.5288.82.camel@chalkhill> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> <1318508522.5288.82.camel@chalkhill> Message-ID: <4E96DD0D.1060002@oracle.com> Neil Richards wrote: > : > Will there need to be two bug numbers for this: one for awt & one for > tl ? > I think one bugID is fine for this: 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h -Alan. From chris.hegarty at oracle.com Thu Oct 13 13:03:49 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Oct 2011 14:03:49 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E96DD0D.1060002@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> <1318508522.5288.82.camel@chalkhill> <4E96DD0D.1060002@oracle.com> Message-ID: <4E96E1B5.1040009@oracle.com> I think I seen in a previous mail that you didn't have access to Solaris machines? I'll grab your patch, apply to a latest jdk8 TL repo and do some sanity builds on Solaris if you like? -Chris. On 10/13/11 01:43 PM, Alan Bateman wrote: > Neil Richards wrote: >> : >> Will there need to be two bug numbers for this: one for awt & one for >> tl ? > I think one bugID is fine for this: > 7100054: (porting) Native code should include fcntl.h and unistd.h > rather than sys/fcntl.h and sys/unistd.h > > -Alan. From neil.richards at ngmr.net Thu Oct 13 14:05:10 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 13 Oct 2011 15:05:10 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E96E1B5.1040009@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> <1318508522.5288.82.camel@chalkhill> <4E96DD0D.1060002@oracle.com> <4E96E1B5.1040009@oracle.com> Message-ID: <1318514710.5288.99.camel@chalkhill> On Thu, 2011-10-13 at 14:03 +0100, Chris Hegarty wrote: > I think I seen in a previous mail that you didn't have access to Solaris > machines? I'll grab your patch, apply to a latest jdk8 TL repo and do > some sanity builds on Solaris if you like? > > -Chris. > Hi Chris, Thank you, that would be really useful. Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From vincent.x.ryan at oracle.com Thu Oct 13 14:58:51 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 13 Oct 2011 14:58:51 +0000 Subject: hg: jdk8/tl/jdk: 7099228: Use a PKCS11 config attribute to control encoding of an EC point Message-ID: <20111013145917.0FB9A47FDE@hg.openjdk.java.net> Changeset: 2b27e14a4c82 Author: vinnie Date: 2011-10-13 12:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b27e14a4c82 7099228: Use a PKCS11 config attribute to control encoding of an EC point Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! test/ProblemList.txt From Ulf.Zibis at gmx.de Thu Oct 13 16:55:14 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 13 Oct 2011 18:55:14 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E94818D.2020800@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E942A59.5070006@gmx.de> <4E94818D.2020800@oracle.com> Message-ID: <4E9717F2.2010605@gmx.de> Am 11.10.2011 19:49, schrieb Xueming Shen: > > I don't know which one is better, I did a run on > > private static boolean op1(int b) { > return (b >> 6) != -2; > } > private static boolean op2(int b) { > return (b & 0xc0) != 0x80; > } > private static boolean op3(byte b) { > return b >= (byte)0xc0; > } > > with 1000000 iteration on my linux machine, and got the scores > > op1=1149 > op2=1147 > op3=1146 > > I would interpret it as they are identical. Me too. thanks for your effort. Maybe the comparison would differ on different architectures. So I would prefer opt3, because the others ... 1. in question need 1 more CPU register to save the original value of b for later usage 2. need 1 more constant to load into CPU and opt 3 ... 3. is the best readable source code 4. in question seems best to help Hotspot finding best optimization on arbitrary architectures. Additionally I guess using always byte variables would in question help HotSpot to optimize with 1-byte-operand CPU instructions. Don't you like to replace all "(bx & 0xc0) != 0x80" by "isNotContinuation(bx)" ? -Ulf From chris.hegarty at oracle.com Thu Oct 13 17:34:12 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Oct 2011 18:34:12 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <1318514710.5288.99.camel@chalkhill> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> <1318508522.5288.82.camel@chalkhill> <4E96DD0D.1060002@oracle.com> <4E96E1B5.1040009@oracle.com> <1318514710.5288.99.camel@chalkhill> Message-ID: <4E972114.1010708@oracle.com> Neil, All builds complete with your patches (on top of the latest JDK8 TL repo) from : http://cr.openjdk.java.net/~ngmr/ojdk-243.1/webrev.01/ http://cr.openjdk.java.net/~ngmr/ojdk-243.2/webrev.00/ solaris_sparc_5.10-product solaris_sparcv9_5.10-product solaris_i586_5.10-product solaris_x64_5.10-product linux_i586_2.6-product -Chris. On 10/13/11 03:05 PM, Neil Richards wrote: > On Thu, 2011-10-13 at 14:03 +0100, Chris Hegarty wrote: >> I think I seen in a previous mail that you didn't have access to Solaris >> machines? I'll grab your patch, apply to a latest jdk8 TL repo and do >> some sanity builds on Solaris if you like? >> >> -Chris. >> > > Hi Chris, > Thank you, that would be really useful. > > Neil > From sean.mullan at oracle.com Thu Oct 13 18:14:19 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 13 Oct 2011 18:14:19 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111013181458.B1A5147FE2@hg.openjdk.java.net> Changeset: 01615d3e74ed Author: mullan Date: 2011-10-13 13:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01615d3e74ed 6953295: Move few sun.security.{util, x509, pkcs} classes used by keytool/jarsigner to another package Reviewed-by: mchung ! make/sun/security/other/Makefile - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java + src/share/classes/sun/security/pkcs10/PKCS10.java + src/share/classes/sun/security/pkcs10/PKCS10Attribute.java + src/share/classes/sun/security/pkcs10/PKCS10Attributes.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java + src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java + src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java + src/share/classes/sun/security/tools/PathList.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 04ecbd2bcf5a Author: mullan Date: 2011-10-13 13:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04ecbd2bcf5a Merge From xueming.shen at oracle.com Thu Oct 13 19:13:42 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 13 Oct 2011 12:13:42 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E9717F2.2010605@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E942A59.5070006@gmx.de> <4E94818D.2020800@oracle.com> <4E9717F2.2010605@gmx.de> Message-ID: <4E973866.4000608@oracle.com> On 10/13/2011 09:55 AM, Ulf Zibis wrote: > Am 11.10.2011 19:49, schrieb Xueming Shen: >> >> I don't know which one is better, I did a run on >> >> private static boolean op1(int b) { >> return (b >> 6) != -2; >> } >> private static boolean op2(int b) { >> return (b & 0xc0) != 0x80; >> } >> private static boolean op3(byte b) { >> return b >= (byte)0xc0; >> } >> >> with 1000000 iteration on my linux machine, and got the scores >> >> op1=1149 >> op2=1147 >> op3=1146 >> >> I would interpret it as they are identical. > Me too. thanks for your effort. > Maybe the comparison would differ on different architectures. > > So I would prefer opt3, because the others ... > 1. in question need 1 more CPU register to save the original value of > b for later usage > 2. need 1 more constant to load into CPU > and opt 3 ... > 3. is the best readable source code > 4. in question seems best to help Hotspot finding best optimization on > arbitrary architectures. I doubt it's more "readable":-), given it's the "byte operation" means "<0x80 && >= 0xc0" in int. You need "b" to be byte for b >= (byte)0xc0 to be the equivalent of "<0x80 && >= 0xc0" and all use cases in UTF-8 existing implementation the "b" has been stored in "int" already. Arguably you can update the whole implementation to achieve this, but personally I would like to just stick to the problem this proposal is trying to solve. And, no, for the same reason I don't want to replace all "(b & 0xc0) != 0x80 by "isNotContinuation(b)", they just look fine for me, together with their neighbors, such as "<0x80 && >= 0xc0". -Sherman > > Additionally I guess using always byte variables would in question > help HotSpot to optimize with 1-byte-operand CPU instructions. > > Don't you like to replace all "(bx & 0xc0) != 0x80" by > "isNotContinuation(bx)" ? > > -Ulf > From mike.skells at talk21.com Thu Oct 13 23:06:52 2011 From: mike.skells at talk21.com (Mike Skells) Date: Fri, 14 Oct 2011 00:06:52 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <20111012102849.12531k3qqspae56p@webmail.nine.ch> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> <4E94E59E.1010100@oracle.com> <20111012102849.12531k3qqspae56p@webmail.nine.ch> Message-ID: <1318547212.71089.YahooMailNeo@web86602.mail.ird.yahoo.com> Hi Patrick, David, David - I tried your suggestions, and I agree it must be faster, but it is in the noise of my test env. not very satisfactory .... Patrick - Unfortunately Appendable doesn't provide all of the interface that you need. All of the methods throw IOException and you cannot append an int (for the line number) I did follow part of the same route as you suggested though to let 1. the?WrappedPrintWriter extend AbstractStringBuffer, 2. write an optimised character buffer that is specific to the needs (overly optimised)? in the first case it was slightly slower, and in the second much slower,? I suspect that my testing regime is (A) not valid or (B) I am falling foul of some optimisation in the system classes or the JIT that is not visible at the java level ... (C) maybe I am missing the obvious though. I enclose an updated Throwable (as per 2) in case (C) if true and you can point out the error of my ways .... Regards Mike >________________________________ >From: Patrick Reinhart >To: Mike Skells >Cc: David Holmes ; "core-libs-dev at openjdk.java.net" >Sent: Wednesday, 12 October 2011, 9:28 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > > >Hi Mike > >Zitat von "David Holmes" : > >>> Patrick - this is why you idea doesn't really provide the answer, there >>> is still a StringBuilder created for each line of stack trace printed, >>> and probably a resize as the line is probably > 16 chars, as well as 2 >>> writes for each line > >Ups, I missed the toString() part of the StackTraceElement - shame on me :-) > >What if you would define a java.lang.Appendable implementation instead of >StringBuilder in your StackStraceElement.appendTo() method. You would then be >able to write the Throwable print stacktrace methods it this way: > >? ? ? for (StackTraceElement traceElement : trace) >? ? ? ? ? s.append("\tat "); >? ? ? ? ? tranceElement.appendTo(s); >? ? ? ? ? s.println(); > >and Similarly for: > >? ? ? for (int i = 0; i <= m; i++) >? ? ? ? ? s.append(prefix).append("\tat "); >? ? ? ? ? tranceElement.appendTo(trace[i]); >? ? ? ? ? s.println(); > > >In this case you would pass the actual PrintStream/Writer instance instead of >creating new StringBuilders at all and your toString() method using a new >StringBuilder still would work the same way. > >Or did I still miss something? > >Cheers, > >Patrick "Reini" Reinhart > > >> >> Ah I see. I missed the key point that you now use a single SB across the entire process of printing the stacktrace. I guess my only additional comment on that is that it would seem to be be a good idea to increase the initial size of that single SB as it is likely to grow on its very first use. >> >> Also a minor gain might be had to change println(sb) to be println(sb.toString()) and avoid the String.valueOf intermediate call (and null check). >> >> Aside: can't help but feel that the streams should directly support CharSequences so that we don't need to convert to intermediate Strings. >> >> >> Cheers, >> David >> > > > > > From patrick at reini.net Fri Oct 14 05:35:43 2011 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 14 Oct 2011 07:35:43 +0200 Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <1318547212.71089.YahooMailNeo@web86602.mail.ird.yahoo.com> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> <4E94E59E.1010100@oracle.com> <20111012102849.12531k3qqspae56p@webmail.nine.ch> <1318547212.71089.YahooMailNeo@web86602.mail.ird.yahoo.com> Message-ID: <4E97CA2F.6030008@reini.net> Am 14.10.11 01:06, schrieb Mike Skells: > Hi Patrick, David, > > David - I tried your suggestions, and I agree it must be faster, but > it is in the noise of my test env. not very satisfactory .... > > Patrick - Unfortunately Appendable doesn't provide all of the > interface that you need. All of the methods throw IOException and you > cannot append an int (for the line number) > I seem to be blind :-( I only did a look on the implementers PrintWriter and PrintStream (which do not declare the IOException...), sorry. Also you got right with the line number, besides to use something as Integer.toString(int) makes the thing even slower I guess :-( Cheers Patrick "Reini" Reinhart From mike.skells at talk21.com Fri Oct 14 07:54:07 2011 From: mike.skells at talk21.com (Mike Skells) Date: Fri, 14 Oct 2011 08:54:07 +0100 (BST) Subject: Patch to Throwable and StackTraceElement (reduced CPU usage) In-Reply-To: <4E97CA2F.6030008@reini.net> References: <344872.12231.qm@web86602.mail.ird.yahoo.com> <4DF9C84B.1080304@oracle.com> <1317936350.37615.YahooMailNeo@web86605.mail.ird.yahoo.com> <1317937551.93053.YahooMailNeo@web86606.mail.ird.yahoo.com> <1318197640.59417.YahooMailNeo@web86605.mail.ird.yahoo.com> <4E922B2E.60701@oracle.com> <1318233230.27193.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318234667.75517.YahooMailNeo@web86607.mail.ird.yahoo.com> <1318282782.90399.YahooMailNeo@web86605.mail.ird.yahoo.com> <1318285820.9308.YahooMailNeo@web86603.mail.ird.yahoo.com> <4E937BCC.3070900@oracle.com> <4E93D680.7040908@reini.net> <4E941786.8090709@oracle.com> <1318377913.95862.YahooMailNeo@web86601.mail.ird.yahoo.com> <4E94E59E.1010100@oracle.com> <20111012102849.12531k3qqspae56p@webmail.nine.ch> <1318547212.71089.YahooMailNeo@web86602.mail.ird.yahoo.com> <4E97CA2F.6030008@reini.net> Message-ID: <1318578847.31381.YahooMailNeo@web86607.mail.ird.yahoo.com> Hi Patrick, you may be blind but I seem to have forgotten how to use email :-(( This time with the attachments I hasten to add that this is not a proposal - it is overly optimised regards Mike >________________________________ >From: Patrick Reinhart >To: Mike Skells >Cc: David Holmes ; "core-libs-dev at openjdk.java.net" >Sent: Friday, 14 October 2011, 6:35 >Subject: Re: Patch to Throwable and StackTraceElement (reduced CPU usage) > > >Am 14.10.11 01:06, schrieb Mike Skells: >Hi Patrick, David, >> >> >>David - I tried your suggestions, and I agree it must be faster, but it is in the noise of my test env. not very satisfactory .... >> >> >>Patrick - Unfortunately Appendable doesn't provide all of the interface that you need. All of the methods throw IOException and you cannot append an int (for the line number) >> >> I seem to be blind :-(? I only did a look on the implementers PrintWriter and PrintStream (which do not declare the IOException...), sorry. > >Also you got right with the line number, besides to use something as Integer.toString(int) makes the thing even slower I guess :-( > >Cheers > >Patrick "Reini" Reinhart > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Throwable.java URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: StackTraceElement.java URL: From Ulf.Zibis at gmx.de Fri Oct 14 08:30:46 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 14 Oct 2011 10:30:46 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E973866.4000608@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E942A59.5070006@gmx.de> <4E94818D.2020800@oracle.com> <4E9717F2.2010605@gmx.de> <4E973866.4000608@oracle.com> Message-ID: <4E97F336.4090307@gmx.de> Am 13.10.2011 21:13, schrieb Xueming Shen: > On 10/13/2011 09:55 AM, Ulf Zibis wrote: >> Am 11.10.2011 19:49, schrieb Xueming Shen: >>> >>> I don't know which one is better, I did a run on >>> >>> private static boolean op1(int b) { >>> return (b >> 6) != -2; >>> } >>> private static boolean op2(int b) { >>> return (b & 0xc0) != 0x80; >>> } >>> private static boolean op3(byte b) { >>> return b >= (byte)0xc0; >>> } >>> >>> with 1000000 iteration on my linux machine, and got the scores >>> >>> op1=1149 >>> op2=1147 >>> op3=1146 >>> >>> I would interpret it as they are identical. >> Me too. thanks for your effort. >> Maybe the comparison would differ on different architectures. >> >> So I would prefer opt3, because the others ... >> 1. in question need 1 more CPU register to save the original value of b for later usage >> 2. need 1 more constant to load into CPU >> and opt 3 ... >> 3. is the best readable source code >> 4. in question seems best to help Hotspot finding best optimization on arbitrary architectures. 5. is the smallest in bytecode footprint 6. so interpreter would be faster too. > I doubt it's more "readable":-), given it's the "byte operation" means > "<0x80 && >= 0xc0" in int. If b would be an unsigned int in range [0..0xFF], half yes (it would be: b<0x80 || b>=0xc0). But b is in range [-0x80..0x7F] due to it's origin from a byte array, so the operation translated to int would be: "b < -0x80 || b >= -0x40" > You need "b" to be byte for b >= (byte)0xc0 No, it works as same for int, because the lower limit -0x80 will never be exceeded and (byte)0xc0 is -0x40. So the notation "b >= (byte)0xc0" looks most close to its real unsigned counterpart. > to be the equivalent of "<0x80 && >= 0xc0" and all use cases in UTF-8 > existing implementation the "b" has been stored in "int" already. Arguably > you can update the whole implementation to achieve this, yes, that's exactly what I wanted to say. > but personally > I would like to just stick to the problem this proposal is trying to solve. I agree, but it's not much more than declaring the bx as byte. > > And, no, for the same reason I don't want to replace all "(b & 0xc0) != 0x80 > by "isNotContinuation(b)", they just look fine for me, together with their > neighbors, such as "<0x80 && >= 0xc0". Yes, they look fine, but the reader always must put in mind, that "(b & 0xc0) != 0x80" is semantically same than "isNotContinuation(b)". Why you introduce isNotContinuation(b) at all? It could always be inlined, as I don't think, the tiny operation has any effect on HotSpot's optimization strategy, and as a side effect, I guess C1 code would be faster. -Ulf > > -Sherman > >> >> Additionally I guess using always byte variables would in question help HotSpot to optimize with >> 1-byte-operand CPU instructions. >> >> Don't you like to replace all "(bx & 0xc0) != 0x80" by "isNotContinuation(bx)" ? >> >> -Ulf >> > From Ulf.Zibis at gmx.de Fri Oct 14 08:47:05 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 14 Oct 2011 10:47:05 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E862AB2.7090605@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> Message-ID: <4E97F709.7080600@gmx.de> Am 30.09.2011 22:46, schrieb Xueming Shen: > I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because > the benchmark shows the "shift" version is slightly faster. Do you have any number > shows any difference now. My non-scientific benchmark still suggests the "shift" > type is faster on -server vm, no significant difference on -client vm. My new guess for the reason: The unfolding of the bytes to int to serve the isNotContinuation / isMalformedxx methods. So those methods should be coded in byte logic too. But there remains the big question, why c1 is faster than c2, except for 1b. -Ulf > > ------------------ your new switch--------------- > (1) -server > Method Millis Ratio > Decoding 1b UTF-8 : 125 1.000 > Decoding 2b UTF-8 : 2558 20.443 > Decoding 3b UTF-8 : 3439 27.481 > Decoding 4b UTF-8 : 2030 16.221 > (2) -client > Decoding 1b UTF-8 : 335 1.000 > Decoding 2b UTF-8 : 1041 3.105 > Decoding 3b UTF-8 : 2245 6.694 > Decoding 4b UTF-8 : 1254 3.741 > > ------------------ existing "shift"--------------- > (1) -server > Decoding 1b UTF-8 : 134 1.000 > Decoding 2b UTF-8 : 1891 14.106 > Decoding 3b UTF-8 : 2934 21.886 > Decoding 4b UTF-8 : 2133 15.913 > (2) -client > Decoding 1b UTF-8 : 341 1.000 > Decoding 2b UTF-8 : 949 2.560 > Decoding 3b UTF-8 : 2321 6.255 > Decoding 4b UTF-8 : 1278 3.446 > > > > -sherman > From Ulf.Zibis at gmx.de Fri Oct 14 09:23:33 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 14 Oct 2011 11:23:33 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E97F709.7080600@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> <4E862AB2.7090605@oracle.com> <4E97F709.7080600@gmx.de> Message-ID: <4E97FF95.5090502@gmx.de> Am 14.10.2011 10:47, schrieb Ulf Zibis: > My new guess for the reason: > The unfolding of the bytes to int to serve the isNotContinuation / isMalformedxx methods. > So those methods should be coded in byte logic too. + use the "bx <= (byte)abc" logic instead "shift" or "(bx & abc) != def". -Ulf From weijun.wang at oracle.com Mon Oct 17 09:12:16 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 17 Oct 2011 09:12:16 +0000 Subject: hg: jdk8/tl/jdk: 7099399: cannot deal with CRL file larger than 16MB Message-ID: <20111017091244.41C8347017@hg.openjdk.java.net> Changeset: 6cb07b35acf5 Author: weijun Date: 2011-10-17 17:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cb07b35acf5 7099399: cannot deal with CRL file larger than 16MB Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/provider/X509Factory.java + test/sun/security/provider/X509Factory/BigCRL.java From maurizio.cimadamore at oracle.com Mon Oct 17 11:59:44 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 17 Oct 2011 11:59:44 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111017115950.696AA4701E@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java From sean.coffey at oracle.com Mon Oct 17 16:02:44 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 17 Oct 2011 17:02:44 +0100 Subject: Code review request: 7101658 : Backout 7082769 changes Message-ID: <4E9C51A4.1070809@oracle.com> bug ID : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7101658 (bug report not visible yet) changes for 7082769 fix have led to behavioral changes which can lead to native file descriptor exhaustion. Basically - file descriptors are not released until all streams referencing them are closed. For the short term, we should backout the 7082769 changes until a full solution which doesn't cause issue in terms of compatibility is found. I'm hoping to get this change into 7u2. webrev : http://cr.openjdk.java.net/~coffeys/webrev.7101658/ regards, Sean. From Alan.Bateman at oracle.com Mon Oct 17 17:29:25 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Oct 2011 18:29:25 +0100 Subject: Code review request: 7101658 : Backout 7082769 changes In-Reply-To: <4E9C51A4.1070809@oracle.com> References: <4E9C51A4.1070809@oracle.com> Message-ID: <4E9C65F5.6060100@oracle.com> Se?n Coffey wrote: > > bug ID : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7101658 > (bug report not visible yet) > > changes for 7082769 fix have led to behavioral changes which can lead > to native file descriptor exhaustion. Basically - file descriptors are > not released until all streams referencing them are closed. > > For the short term, we should backout the 7082769 changes until a full > solution which doesn't cause issue in terms of compatibility is found. > > I'm hoping to get this change into 7u2. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7101658/ The anti-delta looks fine. [ As background I should explain that I asked Se?n off-list to back out these changes because it means that closing a stream that is sharing a file descriptor with another stream no longer closes the underlying file as existing code expects. In order to fix 7082769 properly it will likely require that FileDescriptor be changed to keep a reference to each of the closeables (stream and channels) that use it. That way when a stream is closed then it will cause all stream and channels using the file descriptor to be closed. This should be fixed in 8 first and bake for a while before considering 7u. In the mean-time 7u needs to be resorted to fix the current regression ]. -Alan. From rob.mckenna at oracle.com Mon Oct 17 22:27:56 2011 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 17 Oct 2011 23:27:56 +0100 Subject: Code review request: 7101658 : Backout 7082769 changes In-Reply-To: <4E9C65F5.6060100@oracle.com> References: <4E9C51A4.1070809@oracle.com> <4E9C65F5.6060100@oracle.com> Message-ID: <4E9CABEC.5050109@oracle.com> Looks good. -Rob On 17/10/11 18:29, Alan Bateman wrote: > Se?n Coffey wrote: >> >> bug ID : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7101658 >> (bug report not visible yet) >> >> changes for 7082769 fix have led to behavioral changes which can lead >> to native file descriptor exhaustion. Basically - file descriptors >> are not released until all streams referencing them are closed. >> >> For the short term, we should backout the 7082769 changes until a >> full solution which doesn't cause issue in terms of compatibility is >> found. >> >> I'm hoping to get this change into 7u2. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7101658/ > The anti-delta looks fine. > > [ As background I should explain that I asked Se?n off-list to back > out these changes because it means that closing a stream that is > sharing a file descriptor with another stream no longer closes the > underlying file as existing code expects. In order to fix 7082769 > properly it will likely require that FileDescriptor be changed to keep > a reference to each of the closeables (stream and channels) that use > it. That way when a stream is closed then it will cause all stream and > channels using the file descriptor to be closed. This should be fixed > in 8 first and bake for a while before considering 7u. In the > mean-time 7u needs to be resorted to fix the current regression ]. > > -Alan. From zhouyx at linux.vnet.ibm.com Tue Oct 18 07:53:25 2011 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 18 Oct 2011 15:53:25 +0800 Subject: Add Look&Feel support for AIX platform Message-ID: Hi all, This is a simple patch to add LookAndFeel support for AIX platform to help bring up GUI application. This is part of the series of AIX patches. -- Best Regards, Sean Chou From sean.mullan at oracle.com Tue Oct 18 14:35:48 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 18 Oct 2011 14:35:48 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111018143617.B1F554703C@hg.openjdk.java.net> Changeset: 9bf526cc4046 Author: mullan Date: 2011-10-18 10:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bf526cc4046 7092897: sun.security.util.Cache should be generified Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/KeyCache.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/X509CertificatePair.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java Changeset: f566cd364a90 Author: mullan Date: 2011-10-18 10:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f566cd364a90 Merge ! src/share/classes/sun/security/provider/X509Factory.java From bradford.wetmore at oracle.com Tue Oct 18 19:03:49 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Tue, 18 Oct 2011 19:03:49 +0000 Subject: hg: jdk8/tl/jdk: 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Message-ID: <20111018190407.093524703E@hg.openjdk.java.net> Changeset: 8640b7185be1 Author: wetmore Date: 2011-10-18 11:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8640b7185be1 7031830: bad_record_mac failure on TLSv1.2 enabled connection with SSLEngine Reviewed-by: xuelei, weijun, asaha ! src/share/classes/sun/security/ssl/CipherBox.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java From sean.mullan at oracle.com Wed Oct 19 14:29:53 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 19 Oct 2011 14:29:53 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111019143023.0F3A94707E@hg.openjdk.java.net> Changeset: 57eb9136b73b Author: mullan Date: 2011-10-19 10:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57eb9136b73b 7102686: Restructure timestamp code so that jars and modules can more easily share the same code Reviewed-by: mchung ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java ! src/share/classes/sun/security/timestamp/TSRequest.java ! src/share/classes/sun/security/timestamp/TSResponse.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: 15078025eed9 Author: mullan Date: 2011-10-19 10:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15078025eed9 Merge From maurizio.cimadamore at oracle.com Wed Oct 19 15:57:10 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 19 Oct 2011 15:57:10 +0000 Subject: hg: jdk8/tl/langtools: 7102515: javac running very very long and not returning Message-ID: <20111019155714.7885247085@hg.openjdk.java.net> Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out From mike.duigou at oracle.com Wed Oct 19 22:23:44 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 19 Oct 2011 22:23:44 +0000 Subject: hg: jdk8/tl/jdk: 5029031: Add Collections.checkedQueue() Message-ID: <20111019222354.E00AF47099@hg.openjdk.java.net> Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java From jonathan.gibbons at oracle.com Wed Oct 19 22:30:02 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 19 Oct 2011 22:30:02 +0000 Subject: hg: jdk8/tl/langtools: 7101146: Paths should more directly managed by BaseFileManager Message-ID: <20111019223004.5AD124709A@hg.openjdk.java.net> Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java From chris.hegarty at oracle.com Thu Oct 20 08:09:09 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 20 Oct 2011 08:09:09 +0000 Subject: hg: jdk8/tl/jdk: 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Message-ID: <20111020080928.DE1124709B@hg.openjdk.java.net> Changeset: 634cd6f050ba Author: chegar Date: 2011-10-20 09:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/634cd6f050ba 7102704: test/java/net/DatagramSocket/ChangingAddress.java failing Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com - test/java/net/DatagramSocket/ChangingAddress.java From michael.x.mcmahon at oracle.com Thu Oct 20 08:27:19 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 20 Oct 2011 08:27:19 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111020082739.7BD904709D@hg.openjdk.java.net> Changeset: 2d89c3f74aa5 Author: michaelm Date: 2011-10-20 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d89c3f74aa5 7102665: Move tests to Problemlist Reviewed-by: chegar, alanb ! test/ProblemList.txt Changeset: 52c2dd336207 Author: michaelm Date: 2011-10-20 09:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52c2dd336207 Merge - test/java/net/DatagramSocket/ChangingAddress.java From neil.richards at ngmr.net Thu Oct 20 13:56:22 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Thu, 20 Oct 2011 13:56:22 +0000 Subject: hg: jdk8/tl/jdk: 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Message-ID: <20111020135641.19E52470A4@hg.openjdk.java.net> Changeset: c3da0672a882 Author: ngmr Date: 2011-10-13 12:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3da0672a882 7100054: (porting) Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: dholmes, alanb, chegar, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c From neil.richards at ngmr.net Thu Oct 20 14:06:08 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 20 Oct 2011 15:06:08 +0100 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <4E972114.1010708@oracle.com> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> <1318508522.5288.82.camel@chalkhill> <4E96DD0D.1060002@oracle.com> <4E96E1B5.1040009@oracle.com> <1318514710.5288.99.camel@chalkhill> <4E972114.1010708@oracle.com> Message-ID: <1319119568.9882.42.camel@chalkhill> On Thu, 2011-10-13 at 18:34 +0100, Chris Hegarty wrote: > Neil, > > All builds complete with your patches (on top of the latest JDK8 TL > repo) from : > http://cr.openjdk.java.net/~ngmr/ojdk-243.1/webrev.01/ > http://cr.openjdk.java.net/~ngmr/ojdk-243.2/webrev.00/ > > solaris_sparc_5.10-product > solaris_sparcv9_5.10-product > solaris_i586_5.10-product > solaris_x64_5.10-product > linux_i586_2.6-product > > -Chris. > Hi Chris, Thanks for helping to verify that the suggested change is good. I've now pushed the change to the component repositories. Thanks for all for their help in reviewing this. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Thu Oct 20 15:10:00 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 20 Oct 2011 16:10:00 +0100 Subject: Add Look&Feel support for AIX platform In-Reply-To: References: Message-ID: <1319123400.9882.48.camel@chalkhill> On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote: > Hi all, > > > This is a simple patch to add LookAndFeel support for AIX platform > to help bring > up GUI application. > > > This is part of the series of AIX patches. > -- > Best Regards, > Sean Chou > > For ease of review, I've uploaded this suggested fix as a webrev [1]. The change looks good to me. Regards, Neil [1] http://cr.openjdk.java.net/~ngmr/ojdk-167/webrev.00/index.html -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Thu Oct 20 18:15:45 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 20 Oct 2011 19:15:45 +0100 Subject: Request for review: [NEW BUG] Printer spoolers ignore result from spool process Message-ID: <1319134545.5671.97.camel@chalkhill> Hi all, Whilst trying to debug a printing problem, I noticed that the (Unix and PostScript) printer spoolers in Java do not check what the result is of trying to launch the OS print spooler command (often 'lpr' or 'lp'). As a result, if that exec'd command fails for any reason, that result (and that reason) is lost, and the user left without any clue that something is amiss. To address this, I've created a suggested fix [1], which checks the exit code for the exec'd command and, if it's bad, throws an exception which captures any text from the command's error stream. It does this in both sun.print.PSPrinterJob and sun.print.UnixPrinterJob (they are very similar in composition and function). Please review this suggested change. Thanks, Neil [1] http://cr.openjdk.java.net/~ngmr/ojdk-201/webrev.00/index.html -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Thu Oct 20 18:29:00 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Oct 2011 19:29:00 +0100 Subject: Request for review: [NEW BUG] Printer spoolers ignore result from spool process In-Reply-To: <1319134545.5671.97.camel@chalkhill> References: <1319134545.5671.97.camel@chalkhill> Message-ID: <4EA0686C.9030508@oracle.com> Neil Richards wrote: > Hi all, > Whilst trying to debug a printing problem, I noticed that the (Unix and > PostScript) printer spoolers in Java do not check what the result is of > trying to launch the OS print spooler command (often 'lpr' or 'lp'). > > As a result, if that exec'd command fails for any reason, that result > (and that reason) is lost, and the user left without any clue that > something is amiss. > > To address this, I've created a suggested fix [1], which checks the exit > code for the exec'd command and, if it's bad, throws an exception which > captures any text from the command's error stream. > > It does this in both sun.print.PSPrinterJob and sun.print.UnixPrinterJob > (they are very similar in composition and function). > > Please review this suggested change. > > Thanks, Neil > There isn't printer installed here. You'll need to spool is to the 2d-dev queue :-) From philip.race at oracle.com Thu Oct 20 18:40:34 2011 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Oct 2011 11:40:34 -0700 Subject: Request for review: [NEW BUG] Printer spoolers ignore result from spool process In-Reply-To: <1319134545.5671.97.camel@chalkhill> References: <1319134545.5671.97.camel@chalkhill> Message-ID: <4EA06B22.8050904@oracle.com> Neil, Can you please redirect this over to 2d-dev. Printing has nothing to do with core-libs. Its Java2D. -phil. On 10/20/2011 11:15 AM, Neil Richards wrote: > Hi all, > Whilst trying to debug a printing problem, I noticed that the (Unix and > PostScript) printer spoolers in Java do not check what the result is of > trying to launch the OS print spooler command (often 'lpr' or 'lp'). > > As a result, if that exec'd command fails for any reason, that result > (and that reason) is lost, and the user left without any clue that > something is amiss. > > To address this, I've created a suggested fix [1], which checks the exit > code for the exec'd command and, if it's bad, throws an exception which > captures any text from the command's error stream. > > It does this in both sun.print.PSPrinterJob and sun.print.UnixPrinterJob > (they are very similar in composition and function). > > Please review this suggested change. > > Thanks, Neil > > [1] http://cr.openjdk.java.net/~ngmr/ojdk-201/webrev.00/index.html > From neil.richards at ngmr.net Thu Oct 20 18:45:04 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 20 Oct 2011 19:45:04 +0100 Subject: Request for review: [NEW BUG] Printer spoolers ignore result from spool process In-Reply-To: <4EA06B22.8050904@oracle.com> References: <1319134545.5671.97.camel@chalkhill> <4EA06B22.8050904@oracle.com> Message-ID: <1319136304.5671.114.camel@chalkhill> On Thu, 2011-10-20 at 11:40 -0700, Phil Race wrote: > Neil, > > Can you please redirect this over to 2d-dev. > Printing has nothing to do with core-libs. Its Java2D. > Oops, sorry folks. I'll move my suggestion onto a 2d base and go hassle them with it. Thanks for the pointer. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mike.skells at talk21.com Thu Oct 20 22:04:48 2011 From: mike.skells at talk21.com (Mike Skells) Date: Thu, 20 Oct 2011 23:04:48 +0100 (BST) Subject: performance updates to jar and zip Message-ID: <1319148288.66688.YahooMailNeo@web86608.mail.ird.yahoo.com> Hi All, I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util)? This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in Currently it is a testbed for comparing different techniques, but largely based on the Jar utility The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths This comparative figures do not include the effect of the nio changes that I proposed in earlier emails Command line changes 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression, so the command allows 0-9 to be specified D This allows the files to all be written with the date of now, lather than the file date ?(the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) Z0-9 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier The test environment is a 4 core Intel core2 pc running windows ?vista 64, the test case is jaring up the content of rt.jar to a jar file.? Each test is repeated 6 times and the last 5 are averaged to produce the answers The performance figures are below From mike.skells at talk21.com Thu Oct 20 22:55:35 2011 From: mike.skells at talk21.com (Mike Skells) Date: Thu, 20 Oct 2011 23:55:35 +0100 (BST) Subject: performance updates to jar and zip Message-ID: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> Hi All, I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util)? This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in Currently it is a testbed for comparing different techniques, but largely based on the Jar utility The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths This comparative figures do not include the effect of the nio changes that I proposed in earlier emails Command line changes 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression D This allows the files to all be written with the date of now, lather than the file date ?(the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) Z0-5 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier The test environment is a 4 core Intel core2 pc running windows ?vista 64, the test case is jaring up the content of rt.jar to a jar file.? Each test is repeated 6 times and the last 5 are averaged to produce the answers. Each test is run in a fresh VM The performance figures are below as a CSV. The last column is the duration of the task in ms. In summary the existing jar utility takes (for uncompressed, compressed) 8.4 , 9.4 seconds to complete and this can be reduced to 1.6, 2.3 seconds ? The different parallel algorithms are? 0 - none all in one thread as before 1 - file scanning in one core, 10 threads loading and buffering files, zip writing in a single thread using the existing ZipOuputStream 2. - file scanning in one core, 10 threads loading and buffering files, zip writing mostly mutithreaded (e.g. parallel compression, single write to the output stream) 3 - as 2 but writes to a file rather than a stream 4. as 2 but uses channels to be to write with direct buffers 5 as 4 but using heap buffers 3-5 have the zip capability in the code to seek and update headers that are incomplete, but this is not much tested ? C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, project 1.7 rt -cf0, 3133 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, project 1.7 rt -cf0D, 2824 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, project 1.7 rt -cf0 parallel 0, 3026 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, project 1.7 rt -cf0D parallel 0, 2961 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, project 1.7 rt -cf0D parallel 1, 2022 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, project 1.7 rt -cf0D parallel 2, 1757 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, project 1.7 rt -cf0D parallel 3, 1632 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, project 1.7 rt -cf0D parallel 4, 1994 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, project 1.7 rt -cf0D parallel 5, 1978 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, project 1.7 rt -cf1, 5237 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, project 1.7 rt -cf1D, 5073 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, project 1.7 rt -cf1 parallel 0, 5367 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, project 1.7 rt -cf1D parallel 0, 5002 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, project 1.7 rt -cf1D parallel 1, 5125 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, project 1.7 rt -cf1D parallel 2, 2257 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, project 1.7 rt -cf1D parallel 3, 2145 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, project 1.7 rt -cf1D parallel 4, 2505 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, project 1.7 rt -cf1D parallel 5, 2549 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, project 1.7 rt -cf2, 5371 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, project 1.7 rt -cf3, 5409 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, project 1.7 rt -cf4, 5778 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, project 1.7 rt -cf5, 5906 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, project 1.7 rt -cf6, 6082 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, project 1.7 rt -cf7, 6070 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, project 1.7 rt -cf8, 6251 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, project 1.7 rt -cf9, 6191 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, project 1.7 rt -cf6D, 5843 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, project 1.7 rt -cf6 parallel 0, 6095 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, project 1.7 rt -cf6D parallel 0, 5907 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, project 1.7 rt -cf6D parallel 1, 5957 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, project 1.7 rt -cf6D parallel 2, 2388 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, project 1.7 rt -cf6D parallel 3, 2351 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, project 1.7 rt -cf6D parallel 4, 2694 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, project 1.7 rt -cf6D parallel 5, 2830 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, project 1.7 rt -cf9D, 6134 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, project 1.7 rt -cf9 parallel 0, 6258 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, project 1.7 rt -cf9D parallel 0, 6066 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, project 1.7 rt -cf9D parallel 1, 6203 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, project 1.7 rt -cf9D parallel 2, 2490 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, project 1.7 rt -cf9D parallel 3, 2361 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, project 1.7 rt -cf9D parallel 4, 2788 C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, project 1.7 rt -cf9D parallel 5, 2847 regards Mike -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk_3854_patch.txt URL: From xueming.shen at oracle.com Thu Oct 20 23:50:49 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 20 Oct 2011 16:50:49 -0700 Subject: performance updates to jar and zip In-Reply-To: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> Message-ID: <4EA0B3D9.9030306@oracle.com> Hi Mike, It appears the patch failed to patch the ZipCoder for my JDK8 workspace (I did not look into details, guess the patch is against and "old" version, if you can just send me the updated ZipCoder file, I can add it into the workspace directly) I pull the rest change into a webrev at http://cr.openjdk.java.net/~sherman/mtjar/webrev/ I have not looked into the change detail yet. And probably also need find a real 4+ cores machine to try on:-) -Sherman On 10/20/2011 03:55 PM, Mike Skells wrote: > Hi All, > I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util) > > This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in > Currently it is a testbed for comparing different techniques, but largely based on the Jar utility > > The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths > > This comparative figures do not include the effect of the nio changes that I proposed in earlier emails > > Command line changes > 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression > D This allows the files to all be written with the date of now, lather than the file date (the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) > Z0-5 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier > > The test environment is a 4 core Intel core2 pc running windows vista 64, the test case is jaring up the content of rt.jar to a jar file. > Each test is repeated 6 times and the last 5 are averaged to produce the answers. Each test is run in a fresh VM > > The performance figures are below as a CSV. The last column is the duration of the task in ms. > > In summary the existing jar utility takes (for uncompressed, compressed) 8.4 , 9.4 seconds to complete and this can be reduced to 1.6, 2.3 seconds > > The different parallel algorithms are > 0 - none all in one thread as before > 1 - file scanning in one core, 10 threads loading and buffering files, zip writing in a single thread using the existing ZipOuputStream > 2. - file scanning in one core, 10 threads loading and buffering files, zip writing mostly mutithreaded (e.g. parallel compression, single write to the output stream) > 3 - as 2 but writes to a file rather than a stream > 4. as 2 but uses channels to be to write with direct buffers > 5 as 4 but using heap buffers > > 3-5 have the zip capability in the code to seek and update headers that are incomplete, but this is not much tested > > > > > C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 > C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, project 1.7 rt -cf0, 3133 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, project 1.7 rt -cf0D, 2824 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, project 1.7 rt -cf0 parallel 0, 3026 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, project 1.7 rt -cf0D parallel 0, 2961 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, project 1.7 rt -cf0D parallel 1, 2022 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, project 1.7 rt -cf0D parallel 2, 1757 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, project 1.7 rt -cf0D parallel 3, 1632 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, project 1.7 rt -cf0D parallel 4, 1994 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, project 1.7 rt -cf0D parallel 5, 1978 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, project 1.7 rt -cf1, 5237 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, project 1.7 rt -cf1D, 5073 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, project 1.7 rt -cf1 parallel 0, 5367 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, project 1.7 rt -cf1D parallel 0, 5002 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, project 1.7 rt -cf1D parallel 1, 5125 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, project 1.7 rt -cf1D parallel 2, 2257 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, project 1.7 rt -cf1D parallel 3, 2145 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, project 1.7 rt -cf1D parallel 4, 2505 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, project 1.7 rt -cf1D parallel 5, 2549 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, project 1.7 rt -cf2, 5371 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, project 1.7 rt -cf3, 5409 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, project 1.7 rt -cf4, 5778 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, project 1.7 rt -cf5, 5906 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, project 1.7 rt -cf6, 6082 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, project 1.7 rt -cf7, 6070 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, project 1.7 rt -cf8, 6251 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, project 1.7 rt -cf9, 6191 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, project 1.7 rt -cf6D, 5843 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, project 1.7 rt -cf6 parallel 0, 6095 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, project 1.7 rt -cf6D parallel 0, 5907 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, project 1.7 rt -cf6D parallel 1, 5957 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, project 1.7 rt -cf6D parallel 2, 2388 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, project 1.7 rt -cf6D parallel 3, 2351 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, project 1.7 rt -cf6D parallel 4, 2694 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, project 1.7 rt -cf6D parallel 5, 2830 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, project 1.7 rt -cf9D, 6134 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, project 1.7 rt -cf9 parallel 0, 6258 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, project 1.7 rt -cf9D parallel 0, 6066 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, project 1.7 rt -cf9D parallel 1, 6203 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, project 1.7 rt -cf9D parallel 2, 2490 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, project 1.7 rt -cf9D parallel 3, 2361 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, project 1.7 rt -cf9D parallel 4, 2788 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, project 1.7 rt -cf9D parallel 5, 2847 > > regards > Mike From littlee at linux.vnet.ibm.com Fri Oct 21 03:01:19 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Fri, 21 Oct 2011 11:01:19 +0800 Subject: Request for review - change two include header files according to POSIX.1-2008 In-Reply-To: <1319119568.9882.42.camel@chalkhill> References: <4E953300.9000208@linux.vnet.ibm.com> <4E953DCC.5060600@oracle.com> <4E95A130.80903@oracle.com> <4E966F1B.5040107@linux.vnet.ibm.com> <4E9672EC.2010201@oracle.com> <1318508522.5288.82.camel@chalkhill> <4E96DD0D.1060002@oracle.com> <4E96E1B5.1040009@oracle.com> <1318514710.5288.99.camel@chalkhill> <4E972114.1010708@oracle.com> <1319119568.9882.42.camel@chalkhill> Message-ID: <4EA0E07F.8050801@linux.vnet.ibm.com> On 10/20/2011 10:06 PM, Neil Richards wrote: > On Thu, 2011-10-13 at 18:34 +0100, Chris Hegarty wrote: >> Neil, >> >> All builds complete with your patches (on top of the latest JDK8 TL >> repo) from : >> http://cr.openjdk.java.net/~ngmr/ojdk-243.1/webrev.01/ >> http://cr.openjdk.java.net/~ngmr/ojdk-243.2/webrev.00/ >> >> solaris_sparc_5.10-product >> solaris_sparcv9_5.10-product >> solaris_i586_5.10-product >> solaris_x64_5.10-product >> linux_i586_2.6-product >> >> -Chris. >> > Hi Chris, > Thanks for helping to verify that the suggested change is good. > > I've now pushed the change to the component repositories. > Thanks for all for their help in reviewing this. > > Regards, Neil > Thanks Neil. I saw the committed info :-) -- Yours Charles From yuka.kamiya at oracle.com Fri Oct 21 06:58:42 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Fri, 21 Oct 2011 06:58:42 +0000 Subject: hg: jdk8/tl/jdk: 7103108: (tz) Support tzdata2011l Message-ID: <20111021065900.1404D470BC@hg.openjdk.java.net> Changeset: d979afceb792 Author: peytoia Date: 2011-10-21 15:56 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d979afceb792 7103108: (tz) Support tzdata2011l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java From mike.skells at talk21.com Fri Oct 21 08:08:19 2011 From: mike.skells at talk21.com (Mike Skells) Date: Fri, 21 Oct 2011 09:08:19 +0100 (BST) Subject: performance updates to jar and zip In-Reply-To: <4EA0B3D9.9030306@oracle.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA0B3D9.9030306@oracle.com> Message-ID: <1319184499.89460.YahooMailNeo@web86603.mail.ird.yahoo.com> Hi Sherman, yes the patch is from a very old base in Java 7 I enclose the ZipCoder and a test driver that I used to obtain the results Regards Mike >________________________________ >From: Xueming Shen >To: core-libs-dev at openjdk.java.net >Sent: Friday, 21 October 2011, 0:50 >Subject: Re: performance updates to jar and zip > >Hi Mike, > >It appears the patch failed to patch the ZipCoder for my JDK8 workspace (I did not look into >details, guess the patch is against and "old" version, if you can just send me the updated >ZipCoder file, I can add it into the workspace directly)? I pull the rest change into a webrev >at > >http://cr.openjdk.java.net/~sherman/mtjar/webrev/ > >I have not looked into the change detail yet. And probably also need find a real 4+ cores >machine to try on:-) > >-Sherman > >On 10/20/2011 03:55 PM, Mike Skells wrote: >> Hi All, >> I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util) >> This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in >> Currently it is a testbed for comparing different techniques, but largely based on the Jar utility >> >> The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths >> >> This comparative figures do not include the effect of the nio changes that I proposed in earlier emails >> >> Command line changes >> 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression >> D This allows the files to all be written with the date of now, lather than the file date? (the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) >> Z0-5 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier >> >> The test environment is a 4 core Intel core2 pc running windows? vista 64, the test case is jaring up the content of rt.jar to a jar file. Each test is repeated 6 times and the last 5 are averaged to produce the answers. Each test is run in a fresh VM >> >> The performance figures are below as a CSV. The last column is the duration of the task in ms. >> >> In summary the existing jar utility takes (for uncompressed, compressed) 8.4 , 9.4 seconds to complete and this can be reduced to 1.6, 2.3 seconds? >> The different parallel algorithms are 0 - none all in one thread as before >> 1 - file scanning in one core, 10 threads loading and buffering files, zip writing in a single thread using the existing ZipOuputStream >> 2. - file scanning in one core, 10 threads loading and buffering files, zip writing mostly mutithreaded (e.g. parallel compression, single write to the output stream) >> 3 - as 2 but writes to a file rather than a stream >> 4. as 2 but uses channels to be to write with direct buffers >> 5 as 4 but using heap buffers >> >> 3-5 have the zip capability in the code to seek and update headers that are incomplete, but this is not much tested >>? >> >> >> C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 >> C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, project 1.7 rt -cf0, 3133 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, project 1.7 rt -cf0D, 2824 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, project 1.7 rt -cf0 parallel 0, 3026 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, project 1.7 rt -cf0D parallel 0, 2961 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, project 1.7 rt -cf0D parallel 1, 2022 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, project 1.7 rt -cf0D parallel 2, 1757 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, project 1.7 rt -cf0D parallel 3, 1632 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, project 1.7 rt -cf0D parallel 4, 1994 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, project 1.7 rt -cf0D parallel 5, 1978 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, project 1.7 rt -cf1, 5237 >> >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, project 1.7 rt -cf1D, 5073 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, project 1.7 rt -cf1 parallel 0, 5367 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, project 1.7 rt -cf1D parallel 0, 5002 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, project 1.7 rt -cf1D parallel 1, 5125 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, project 1.7 rt -cf1D parallel 2, 2257 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, project 1.7 rt -cf1D parallel 3, 2145 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, project 1.7 rt -cf1D parallel 4, 2505 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, project 1.7 rt -cf1D parallel 5, 2549 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, project 1.7 rt -cf2, 5371 >> >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, project 1.7 rt -cf3, 5409 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, project 1.7 rt -cf4, 5778 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, project 1.7 rt -cf5, 5906 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, project 1.7 rt -cf6, 6082 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, project 1.7 rt -cf7, 6070 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, project 1.7 rt -cf8, 6251 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, project 1.7 rt -cf9, 6191 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, project 1.7 rt -cf6D, 5843 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, project 1.7 rt -cf6 parallel 0, 6095 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, project 1.7 rt -cf6D parallel 0, 5907 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, project 1.7 rt -cf6D parallel 1, 5957 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, project 1.7 rt -cf6D parallel 2, 2388 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, project 1.7 rt -cf6D parallel 3, 2351 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, project 1.7 rt -cf6D parallel 4, 2694 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, project 1.7 rt -cf6D parallel 5, 2830 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, project 1.7 rt -cf9D, 6134 >> >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, project 1.7 rt -cf9 parallel 0, 6258 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, project 1.7 rt -cf9D parallel 0, 6066 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, project 1.7 rt -cf9D parallel 1, 6203 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, project 1.7 rt -cf9D parallel 2, 2490 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, project 1.7 rt -cf9D parallel 3, 2361 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, project 1.7 rt -cf9D parallel 4, 2788 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, project 1.7 rt -cf9D parallel 5, 2847 >> >> regards >> Mike > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ZipCoder.java.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TestJar.java.txt URL: From yuka.kamiya at oracle.com Fri Oct 21 09:03:07 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Fri, 21 Oct 2011 09:03:07 +0000 Subject: hg: jdk8/tl/jdk: 7103405: Correct display names for Pacific/Apia timezone Message-ID: <20111021090324.B86FD470BE@hg.openjdk.java.net> Changeset: db9e246c651e Author: peytoia Date: 2011-10-21 18:01 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db9e246c651e 7103405: Correct display names for Pacific/Apia timezone Reviewed-by: okutsu ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java From jim.holmlund at sun.com Fri Oct 21 21:17:46 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 21 Oct 2011 21:17:46 +0000 Subject: hg: jdk8/tl/langtools: 7098530: tools/javac/javazip/Test.sh can fail on Windows Message-ID: <20111021211751.BDCCB470CB@hg.openjdk.java.net> Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh From maurizio.cimadamore at oracle.com Mon Oct 24 12:01:45 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 24 Oct 2011 12:01:45 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111024120150.23AE5470F5@hg.openjdk.java.net> Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java From chris.hegarty at oracle.com Mon Oct 24 14:20:47 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Oct 2011 15:20:47 +0100 Subject: Code Review 7104209: Cleanup and remove librmi (native library) Message-ID: <4EA5743F.1030601@oracle.com> It appears that the only function of librmi is to export the VM function JVM_LatestUserDefinedLoader. It seems really silly to have a whole native library to perform such a trivial operation. JVM_LatestUserDefinedLoader is also used in java.io.ObjectInputStream. It would make more sense to put an entry point in sun.misc.VM, and have rmi, ois invoke it. This would completely eliminate the need for librmi. http://cr.openjdk.java.net/~chegar/7104209/webrev.00/webrev/ -Chris. From mike.duigou at oracle.com Mon Oct 24 14:41:19 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 24 Oct 2011 07:41:19 -0700 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <4EA5743F.1030601@oracle.com> References: <4EA5743F.1030601@oracle.com> Message-ID: <870541AC-F22F-48BC-B4BD-A4E5B645D5F1@oracle.com> Looks good. Nice catch. Mike On Oct 24 2011, at 07:20 , Chris Hegarty wrote: > It appears that the only function of librmi is to export the VM function JVM_LatestUserDefinedLoader. It seems really silly to have a whole native library to perform such a trivial operation. JVM_LatestUserDefinedLoader is also used in java.io.ObjectInputStream. > > It would make more sense to put an entry point in sun.misc.VM, and have rmi, ois invoke it. This would completely eliminate the need for librmi. > > http://cr.openjdk.java.net/~chegar/7104209/webrev.00/webrev/ > > -Chris. From chris.hegarty at oracle.com Mon Oct 24 14:47:02 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Oct 2011 15:47:02 +0100 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <870541AC-F22F-48BC-B4BD-A4E5B645D5F1@oracle.com> References: <4EA5743F.1030601@oracle.com> <870541AC-F22F-48BC-B4BD-A4E5B645D5F1@oracle.com> Message-ID: <4EA57A66.1030204@oracle.com> Thanks Mike, It was actually Alan that caught this. Crazy that someone ( at some time ) even thought this was a good idea! -Chris. On 24/10/2011 15:41, Mike Duigou wrote: > Looks good. Nice catch. > > Mike > > On Oct 24 2011, at 07:20 , Chris Hegarty wrote: > >> It appears that the only function of librmi is to export the VM function JVM_LatestUserDefinedLoader. It seems really silly to have a whole native library to perform such a trivial operation. JVM_LatestUserDefinedLoader is also used in java.io.ObjectInputStream. >> >> It would make more sense to put an entry point in sun.misc.VM, and have rmi, ois invoke it. This would completely eliminate the need for librmi. >> >> http://cr.openjdk.java.net/~chegar/7104209/webrev.00/webrev/ >> >> -Chris. > From sean.coffey at oracle.com Mon Oct 24 17:27:11 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 24 Oct 2011 18:27:11 +0100 Subject: code review request : 7099658 : Properties.loadFromXML fails with ClassCastException Message-ID: <4EA59FEF.1040103@oracle.com> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7099658 Simple fix where loadFromXML method should call into the standard API and use the getDocumentElement() call to obtain the properties Element. http://cr.openjdk.java.net/~coffeys/webrev.7099658/ regards, Sean. From Alan.Bateman at oracle.com Mon Oct 24 17:48:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Oct 2011 18:48:01 +0100 Subject: code review request : 7099658 : Properties.loadFromXML fails with ClassCastException In-Reply-To: <4EA59FEF.1040103@oracle.com> References: <4EA59FEF.1040103@oracle.com> Message-ID: <4EA5A4D1.1000609@oracle.com> On 24/10/2011 18:27, Se?n Coffey wrote: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7099658 > > Simple fix where loadFromXML method should call into the standard API > and use the getDocumentElement() call to obtain the properties Element. > > http://cr.openjdk.java.net/~coffeys/webrev.7099658/ > > regards, > Sean. Looks fine to me. -Alan. From Alan.Bateman at oracle.com Mon Oct 24 17:51:22 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Oct 2011 18:51:22 +0100 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <4EA5743F.1030601@oracle.com> References: <4EA5743F.1030601@oracle.com> Message-ID: <4EA5A59A.4010906@oracle.com> On 24/10/2011 15:20, Chris Hegarty wrote: > It appears that the only function of librmi is to export the VM > function JVM_LatestUserDefinedLoader. It seems really silly to have a > whole native library to perform such a trivial operation. > JVM_LatestUserDefinedLoader is also used in java.io.ObjectInputStream. > > It would make more sense to put an entry point in sun.misc.VM, and > have rmi, ois invoke it. This would completely eliminate the need for > librmi. > > http://cr.openjdk.java.net/~chegar/7104209/webrev.00/webrev/ > > -Chris. Looks good to me - thanks for taking this one. -Alan. From mandy.chung at oracle.com Mon Oct 24 19:06:23 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 24 Oct 2011 12:06:23 -0700 Subject: code review request : 7099658 : Properties.loadFromXML fails with ClassCastException In-Reply-To: <4EA59FEF.1040103@oracle.com> References: <4EA59FEF.1040103@oracle.com> Message-ID: <4EA5B72F.5040607@oracle.com> On 10/24/11 10:27 AM, Se?n Coffey wrote: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7099658 > > Simple fix where loadFromXML method should call into the standard API > and use the getDocumentElement() call to obtain the properties Element. > > http://cr.openjdk.java.net/~coffeys/webrev.7099658/ Looks good to me. Mandy From roger.riggs at oracle.com Mon Oct 24 19:08:11 2011 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 24 Oct 2011 12:08:11 -0700 (PDT) Subject: Auto Reply: core-libs-dev Digest, Vol 54, Issue 33 Message-ID: <2631edaf-4337-465c-b37a-d597afbaf0a8@default> Roger will be back in the office October 31st. From chris.hegarty at oracle.com Mon Oct 24 19:56:24 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 24 Oct 2011 19:56:24 +0000 Subject: hg: jdk8/tl/jdk: 7104209: Cleanup and remove librmi (native library) Message-ID: <20111024195647.20EB547103@hg.openjdk.java.net> Changeset: 3f391e649ccb Author: chegar Date: 2011-10-24 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f391e649ccb 7104209: Cleanup and remove librmi (native library) Reviewed-by: mduigou, alanb ! make/java/java/mapfile-vers ! make/sun/rmi/rmi/Makefile - make/sun/rmi/rmi/mapfile-vers ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/sun/misc/VM.c - src/share/native/sun/rmi/server/MarshalInputStream.c From chris.hegarty at oracle.com Mon Oct 24 20:05:15 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 24 Oct 2011 20:05:15 +0000 Subject: hg: jdk8/tl/jdk: 7103549: Remove dependencies on libjava and libjvm from security libraries Message-ID: <20111024200525.F3B6B47104@hg.openjdk.java.net> Changeset: b375523d6037 Author: chegar Date: 2011-10-24 21:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b375523d6037 7103549: Remove dependencies on libjava and libjvm from security libraries Reviewed-by: vinnie, ohair, alanb, dholmes ! make/com/sun/security/auth/module/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c From david.holmes at oracle.com Mon Oct 24 22:18:46 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Oct 2011 08:18:46 +1000 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <4EA57A66.1030204@oracle.com> References: <4EA5743F.1030601@oracle.com> <870541AC-F22F-48BC-B4BD-A4E5B645D5F1@oracle.com> <4EA57A66.1030204@oracle.com> Message-ID: <4EA5E446.8090803@oracle.com> On 25/10/2011 12:47 AM, Chris Hegarty wrote: > Thanks Mike, > > It was actually Alan that caught this. Crazy that someone ( at some time > ) even thought this was a good idea! Not only did someone think it a good idea but nobody else disagreed. Sometimes these things are lost in ancient history but it is always a concern when we make changes where we don't understand the reasons for the original code. Just a comment/observation - changes look fine to me. David > -Chris. > > On 24/10/2011 15:41, Mike Duigou wrote: >> Looks good. Nice catch. >> >> Mike >> >> On Oct 24 2011, at 07:20 , Chris Hegarty wrote: >> >>> It appears that the only function of librmi is to export the VM >>> function JVM_LatestUserDefinedLoader. It seems really silly to have a >>> whole native library to perform such a trivial operation. >>> JVM_LatestUserDefinedLoader is also used in java.io.ObjectInputStream. >>> >>> It would make more sense to put an entry point in sun.misc.VM, and >>> have rmi, ois invoke it. This would completely eliminate the need for >>> librmi. >>> >>> http://cr.openjdk.java.net/~chegar/7104209/webrev.00/webrev/ >>> >>> -Chris. >> From Alan.Bateman at oracle.com Tue Oct 25 08:08:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Oct 2011 09:08:33 +0100 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <4EA5743F.1030601@oracle.com> References: <4EA5743F.1030601@oracle.com> Message-ID: <4EA66E81.8090700@oracle.com> It turns out there's a problem with these changes as it didn't remove the code to load the rmi library (we missed it in the code review too). The result is that most of the RMI tests are now failing. I've just created 7104577 for this. The diffs are trivial - can I get a reviewer and we'll sweep this under the rug quickly - thanks, Alan. diff --git a/src/share/classes/sun/rmi/server/MarshalInputStream.java b/src/share/classes/sun/rmi/server/MarshalInputStream.java --- a/src/share/classes/sun/rmi/server/MarshalInputStream.java +++ b/src/share/classes/sun/rmi/server/MarshalInputStream.java @@ -107,14 +107,6 @@ public class MarshalInputStream extends throw new NoClassDefFoundError("Missing system class: " + e.getMessage()); } - } - - /** - * Load the "rmi" native library. - */ - static { - java.security.AccessController.doPrivileged( - new sun.security.action.LoadLibraryAction("rmi")); } /** From chris.hegarty at oracle.com Tue Oct 25 08:19:38 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 09:19:38 +0100 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <4EA66E81.8090700@oracle.com> References: <4EA5743F.1030601@oracle.com> <4EA66E81.8090700@oracle.com> Message-ID: <4EA6711A.7060700@oracle.com> D'oh! Sorry my fault. The changes look good, and thanks for taking care of this. -Chris. On 10/25/11 09:08 AM, Alan Bateman wrote: > > It turns out there's a problem with these changes as it didn't remove > the code to load the rmi library (we missed it in the code review too). > The result is that most of the RMI tests are now failing. I've just > created 7104577 for this. The diffs are trivial - can I get a reviewer > and we'll sweep this under the rug quickly - thanks, Alan. > > diff --git a/src/share/classes/sun/rmi/server/MarshalInputStream.java > b/src/share/classes/sun/rmi/server/MarshalInputStream.java > --- a/src/share/classes/sun/rmi/server/MarshalInputStream.java > +++ b/src/share/classes/sun/rmi/server/MarshalInputStream.java > @@ -107,14 +107,6 @@ public class MarshalInputStream extends > throw new NoClassDefFoundError("Missing system class: " + > e.getMessage()); > } > - } > - > - /** > - * Load the "rmi" native library. > - */ > - static { > - java.security.AccessController.doPrivileged( > - new sun.security.action.LoadLibraryAction("rmi")); > } > > /** > From alan.bateman at oracle.com Tue Oct 25 08:28:38 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 25 Oct 2011 08:28:38 +0000 Subject: hg: jdk8/tl/jdk: 7104577: Changes for 7104209 cause many RMI tests to fail Message-ID: <20111025082859.73ED547109@hg.openjdk.java.net> Changeset: 72666cd49ac3 Author: alanb Date: 2011-10-25 09:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72666cd49ac3 7104577: Changes for 7104209 cause many RMI tests to fail Reviewed-by: chegar ! src/share/classes/sun/rmi/server/MarshalInputStream.java From david.holmes at oracle.com Tue Oct 25 10:23:32 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Oct 2011 20:23:32 +1000 Subject: build error: sun/nio/ch/Util.java ? Message-ID: <4EA68E24.7010507@oracle.com> I'm getting a build error due to -Werror and the fact that Util.java uses a raw type: "new Class[] { ...}" and so generates a raw type warning David From Alan.Bateman at oracle.com Tue Oct 25 10:34:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Oct 2011 11:34:39 +0100 Subject: jcheck conflict in jdk8/tl/jdk and awt repos: same CR # 7100054 used in two different changesets (one in tl, the other in awt forest) In-Reply-To: <4EA60104.1090008@oracle.com> References: <4EA60104.1090008@oracle.com> Message-ID: <4EA690BF.4000605@oracle.com> On 25/10/2011 01:21, Lana Steuck wrote: > To: TL and Awt teams > What: we have a jcheck conflict in jdk8/tl/jdk and jdk8/awt/jdk repos: > same Bugid # 7100054 used in two different changesets (one in > tl/jdk, the other in awt/jdk repo) > > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f218e6bdf1e8 > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3da0672a882 > > neil.richards at ngmr.net > 7100054: (porting) Native code should include fcntl.h and unistd.h > rather than sys/fcntl.h and sys/unistd.h > Summary: Use POSIX defined includes for unistd.h and fcntl.h I think I may be partly to blame here. Neil did ask whether he needed a separate CR for the AWT change and I told him ([1]) that one was sufficient. I didn't realize he was thinking of splitting the changes though as there wasn't any real need to do this for this. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007926.html From chris.hegarty at oracle.com Tue Oct 25 10:48:22 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 11:48:22 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA68E24.7010507@oracle.com> References: <4EA68E24.7010507@oracle.com> Message-ID: <4EA693F6.4020704@oracle.com> Hmmm... there was an issue in javac where it was not reporting raw type warnings for anonymous inner classes. Maurizio fixed this recently (javac will now report these warnings), but I did a clean build with Maurizio's patch and all went well. I can also still do a clean build ( but I build just jdk not langtools, and use a b09 import ). Nightly builds went fine too! You can clearly see the raw type in the source, I just don't understand why we didn't see if before. I'll file a CR and have it fixed. -Chris On 10/25/11 11:23 AM, David Holmes wrote: > I'm getting a build error due to -Werror and the fact that Util.java > uses a raw type: "new Class[] { ...}" and so generates a raw type warning > > David From forax at univ-mlv.fr Tue Oct 25 11:22:43 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 25 Oct 2011 13:22:43 +0200 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA68E24.7010507@oracle.com> References: <4EA68E24.7010507@oracle.com> Message-ID: <4EA69C03.5030006@univ-mlv.fr> On 10/25/2011 12:23 PM, David Holmes wrote: > I'm getting a build error due to -Werror and the fact that Util.java > uses a raw type: "new Class[] { ...}" and so generates a raw type warning Until recently, javac has forgotten to warn about that kind of rawtype (array of rawtype). new Class[] { ... } should solve the problem. > > David R?mi From david.holmes at oracle.com Tue Oct 25 11:26:18 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Oct 2011 21:26:18 +1000 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA693F6.4020704@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> Message-ID: <4EA69CDA.70308@oracle.com> On 25/10/2011 8:48 PM, Chris Hegarty wrote: > Hmmm... there was an issue in javac where it was not reporting raw type > warnings for anonymous inner classes. Maurizio fixed this recently > (javac will now report these warnings), but I did a clean build with > Maurizio's patch and all went well. I can also still do a clean build ( > but I build just jdk not langtools, and use a b09 import ). Nightly > builds went fine too! > > You can clearly see the raw type in the source, I just don't understand > why we didn't see if before. I'll file a CR and have it fixed. I suspect this is another case of a partial build causing files to be compiled with different settings. I'll try another clean build. Thanks, David > -Chris > > On 10/25/11 11:23 AM, David Holmes wrote: >> I'm getting a build error due to -Werror and the fact that Util.java >> uses a raw type: "new Class[] { ...}" and so generates a raw type warning >> >> David From david.holmes at oracle.com Tue Oct 25 11:27:54 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Oct 2011 21:27:54 +1000 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA69C03.5030006@univ-mlv.fr> References: <4EA68E24.7010507@oracle.com> <4EA69C03.5030006@univ-mlv.fr> Message-ID: <4EA69D3A.2060205@oracle.com> On 25/10/2011 9:22 PM, R?mi Forax wrote: > On 10/25/2011 12:23 PM, David Holmes wrote: >> I'm getting a build error due to -Werror and the fact that Util.java >> uses a raw type: "new Class[] { ...}" and so generates a raw type warning > > Until recently, javac has forgotten to warn about that kind of rawtype > (array of rawtype). > new Class[] { ... } > should solve the problem. Yes that fixes it. It's more an issue of why I saw it and other builds do not. As per my reply to Chris this may be an issue with not doing a clean build. David >> >> David > > R?mi > From maurizio.cimadamore at oracle.com Tue Oct 25 11:31:39 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 25 Oct 2011 12:31:39 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA69C03.5030006@univ-mlv.fr> References: <4EA68E24.7010507@oracle.com> <4EA69C03.5030006@univ-mlv.fr> Message-ID: <4EA69E1B.4010006@oracle.com> On 25/10/11 12:22, R?mi Forax wrote: > On 10/25/2011 12:23 PM, David Holmes wrote: >> I'm getting a build error due to -Werror and the fact that Util.java >> uses a raw type: "new Class[] { ...}" and so generates a raw type >> warning > > Until recently, javac has forgotten to warn about that kind of rawtype > (array of rawtype). > new Class[] { ... } > should solve the problem. Uhmmm, what do you mean by 'until recently' ? With JDK 7 b147 I get the same warning with the following code: import java.util.*; class Test { Object o = new ArrayList[] {}; } output: Test.java:4: warning: [rawtypes] found raw type: ArrayList Object o = new ArrayList[] {}; ^ missing type arguments for generic class ArrayList where E is a type-variable: E extends Object declared in class ArrayList 1 warning > >> >> David > > R?mi > From chris.hegarty at oracle.com Tue Oct 25 11:39:06 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 12:39:06 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA69CDA.70308@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> <4EA69CDA.70308@oracle.com> Message-ID: <4EA69FDA.1030109@oracle.com> On 10/25/11 12:26 PM, David Holmes wrote: > On 25/10/2011 8:48 PM, Chris Hegarty wrote: >> Hmmm... there was an issue in javac where it was not reporting raw type >> warnings for anonymous inner classes. Maurizio fixed this recently >> (javac will now report these warnings), but I did a clean build with >> Maurizio's patch and all went well. I can also still do a clean build ( >> but I build just jdk not langtools, and use a b09 import ). Nightly >> builds went fine too! >> >> You can clearly see the raw type in the source, I just don't understand >> why we didn't see if before. I'll file a CR and have it fixed. > > I suspect this is another case of a partial build causing files to be > compiled with different settings. I'll try another clean build. Yeap, kinda but officially the other way around ;-) A full build for me is ok, but when I clobber nio ('cd make/java/nio' 'make clobber') and rebuild just nio ('cd make/java/nio' 'make') I can see the problem. It looks like this class is being implicitly compiled earlier in the build process, and by a makefile without -Werror. In fact, I see a few other warnings: ./../../src/share/classes/java/nio/charset/Charset.java:438: warning: [rawtypes] found raw type: Class Class epc ^ missing type arguments for generic class Class where T is a type-variable: T extends Object declared in class Class error: warnings found and -Werror specified ../../../src/share/classes/sun/nio/ch/Util.java:366: warning: [rawtypes] found raw type: Class new Class[] { int.class, ^ missing type arguments for generic class Class where T is a type-variable: T extends Object declared in class Class ../../../src/share/classes/sun/nio/ch/Util.java:411: warning: [rawtypes] found raw type: Class new Class[] { int.class, ^ missing type arguments for generic class Class where T is a type-variable: T extends Object declared in class Class 1 error 3 warnings make381: *** [.compile.classlist] Error 1 I'll file a CR and have this fixed. -Chris. > > Thanks, > David > >> -Chris >> >> On 10/25/11 11:23 AM, David Holmes wrote: >>> I'm getting a build error due to -Werror and the fact that Util.java >>> uses a raw type: "new Class[] { ...}" and so generates a raw type >>> warning >>> >>> David From chris.hegarty at oracle.com Tue Oct 25 11:48:26 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 12:48:26 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA69CDA.70308@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> <4EA69CDA.70308@oracle.com> Message-ID: <4EA6A20A.3070608@oracle.com> On 10/25/11 12:26 PM, David Holmes wrote: > On 25/10/2011 8:48 PM, Chris Hegarty wrote: >> Hmmm... there was an issue in javac where it was not reporting raw type >> warnings for anonymous inner classes. Maurizio fixed this recently >> (javac will now report these warnings), but I did a clean build with >> Maurizio's patch and all went well. I can also still do a clean build ( >> but I build just jdk not langtools, and use a b09 import ). Nightly >> builds went fine too! >> >> You can clearly see the raw type in the source, I just don't understand >> why we didn't see if before. I'll file a CR and have it fixed. > > I suspect this is another case of a partial build causing files to be > compiled with different settings. I'll try another clean build. Yeap, kinda but officially the other way around ;-) A full build for me is ok, but when I clobber nio ('cd make/java/nio' 'make clobber') and rebuild just nio ('cd make/java/nio' 'make') I can see the problem. It looks like this class is being implicitly compiled earlier in the build process, and by a makefile without -Werror. In fact, I see a few other warnings: ./../../src/share/classes/java/nio/charset/Charset.java:438: warning: [rawtypes] found raw type: Class Class epc ^ missing type arguments for generic class Class where T is a type-variable: T extends Object declared in class Class error: warnings found and -Werror specified ../../../src/share/classes/sun/nio/ch/Util.java:366: warning: [rawtypes] found raw type: Class new Class[] { int.class, ^ missing type arguments for generic class Class where T is a type-variable: T extends Object declared in class Class ../../../src/share/classes/sun/nio/ch/Util.java:411: warning: [rawtypes] found raw type: Class new Class[] { int.class, ^ missing type arguments for generic class Class where T is a type-variable: T extends Object declared in class Class 1 error 3 warnings make381: *** [.compile.classlist] Error 1 I'll file a CR and have this fixed. -Chris. > > Thanks, > David > >> -Chris >> >> On 10/25/11 11:23 AM, David Holmes wrote: >>> I'm getting a build error due to -Werror and the fact that Util.java >>> uses a raw type: "new Class[] { ...}" and so generates a raw type >>> warning >>> >>> David From david.holmes at oracle.com Tue Oct 25 11:51:18 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Oct 2011 21:51:18 +1000 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA69FDA.1030109@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> <4EA69CDA.70308@oracle.com> <4EA69FDA.1030109@oracle.com> Message-ID: <4EA6A2B6.1060406@oracle.com> On 25/10/2011 9:39 PM, Chris Hegarty wrote: > On 10/25/11 12:26 PM, David Holmes wrote: >> >> I suspect this is another case of a partial build causing files to be >> compiled with different settings. I'll try another clean build. > > Yeap, kinda but officially the other way around ;-) A full build for me > is ok, but when I clobber nio ('cd make/java/nio' 'make clobber') and > rebuild just nio ('cd make/java/nio' 'make') I can see the problem. It > looks like this class is being implicitly compiled earlier in the build > process, and by a makefile without -Werror. Yep that's the scenario. I've actually seen lots of warnings doing partial builds. I guess if we turn -Werror on everywhere they will all be exposed. Thanks, David > > In fact, I see a few other warnings: > > ./../../src/share/classes/java/nio/charset/Charset.java:438: warning: > [rawtypes] found raw type: Class > Class epc > ^ > missing type arguments for generic class Class > where T is a type-variable: > T extends Object declared in class Class > error: warnings found and -Werror specified > ../../../src/share/classes/sun/nio/ch/Util.java:366: warning: [rawtypes] > found raw type: Class > new Class[] { int.class, > ^ > missing type arguments for generic class Class > where T is a type-variable: > T extends Object declared in class Class > ../../../src/share/classes/sun/nio/ch/Util.java:411: warning: [rawtypes] > found raw type: Class > new Class[] { int.class, > ^ > missing type arguments for generic class Class > where T is a type-variable: > T extends Object declared in class Class > 1 error > 3 warnings > make381: *** [.compile.classlist] Error 1 > > I'll file a CR and have this fixed. > > -Chris. > >> >> Thanks, >> David >> >>> -Chris >>> >>> On 10/25/11 11:23 AM, David Holmes wrote: >>>> I'm getting a build error due to -Werror and the fact that Util.java >>>> uses a raw type: "new Class[] { ...}" and so generates a raw type >>>> warning >>>> >>>> David From chris.hegarty at oracle.com Tue Oct 25 11:56:20 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 12:56:20 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA6A2B6.1060406@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> <4EA69CDA.70308@oracle.com> <4EA69FDA.1030109@oracle.com> <4EA6A2B6.1060406@oracle.com> Message-ID: <4EA6A3E4.2080900@oracle.com> On 10/25/11 12:51 PM, David Holmes wrote: > On 25/10/2011 9:39 PM, Chris Hegarty wrote: >> On 10/25/11 12:26 PM, David Holmes wrote: >>> >>> I suspect this is another case of a partial build causing files to be >>> compiled with different settings. I'll try another clean build. >> >> Yeap, kinda but officially the other way around ;-) A full build for me >> is ok, but when I clobber nio ('cd make/java/nio' 'make clobber') and >> rebuild just nio ('cd make/java/nio' 'make') I can see the problem. It >> looks like this class is being implicitly compiled earlier in the build >> process, and by a makefile without -Werror. > > Yep that's the scenario. I've actually seen lots of warnings doing > partial builds. I guess if we turn -Werror on everywhere they will all > be exposed. Sasha, Kurchi, and others, are making their way through the core libraries area fixing all the javac warnings. They are enabling -Werror once they complete a specific area to ensure warnings don't creep back in. I guess because some of these classes were not being recompiled by the java/nio makefile this just slipped through. Eventually, the goal will be to compile everything with -Werror :-) Happy days! -Chris. > > Thanks, > David > >> >> In fact, I see a few other warnings: >> >> ./../../src/share/classes/java/nio/charset/Charset.java:438: warning: >> [rawtypes] found raw type: Class >> Class epc >> ^ >> missing type arguments for generic class Class >> where T is a type-variable: >> T extends Object declared in class Class >> error: warnings found and -Werror specified >> ../../../src/share/classes/sun/nio/ch/Util.java:366: warning: [rawtypes] >> found raw type: Class >> new Class[] { int.class, >> ^ >> missing type arguments for generic class Class >> where T is a type-variable: >> T extends Object declared in class Class >> ../../../src/share/classes/sun/nio/ch/Util.java:411: warning: [rawtypes] >> found raw type: Class >> new Class[] { int.class, >> ^ >> missing type arguments for generic class Class >> where T is a type-variable: >> T extends Object declared in class Class >> 1 error >> 3 warnings >> make381: *** [.compile.classlist] Error 1 >> >> I'll file a CR and have this fixed. >> >> -Chris. >> >>> >>> Thanks, >>> David >>> >>>> -Chris >>>> >>>> On 10/25/11 11:23 AM, David Holmes wrote: >>>>> I'm getting a build error due to -Werror and the fact that Util.java >>>>> uses a raw type: "new Class[] { ...}" and so generates a raw type >>>>> warning >>>>> >>>>> David From chris.hegarty at oracle.com Tue Oct 25 12:36:59 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 13:36:59 +0100 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util Message-ID: <4EA6AD6B.3040808@oracle.com> The changes to remove warnings from the NIO code (7068616) missed java/nio/charset/Charset.java and sun/nio/ch/Util.java. This was not spotted at the time as the compiler was not generating raw type warnings for anonymous inner classes. It does now, see CR 7090499. This is not an issue when doing a full build because the classes are compiled implicitly, but when re-building then JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL are set by make/java/nio/Makefile and so the warning is fatal. diff -r 72666cd49ac3 src/share/classes/java/nio/charset/Charset.java --- a/src/share/classes/java/nio/charset/Charset.java Tue Oct 25 09:27:20 2011 +0100 +++ b/src/share/classes/java/nio/charset/Charset.java Tue Oct 25 13:38:06 2011 +0100 @@ -435,7 +435,7 @@ public abstract class Charset AccessController.doPrivileged(new PrivilegedAction() { public Object run() { try { - Class epc + Class epc = Class.forName("sun.nio.cs.ext.ExtendedCharsets"); extendedProvider = (CharsetProvider)epc.newInstance(); } catch (ClassNotFoundException x) { diff -r 72666cd49ac3 src/share/classes/sun/nio/ch/Util.java --- a/src/share/classes/sun/nio/ch/Util.java Tue Oct 25 09:27:20 2011 +0100 +++ b/src/share/classes/sun/nio/ch/Util.java Tue Oct 25 13:38:06 2011 +0100 @@ -363,10 +363,10 @@ class Util { try { Class cl = Class.forName("java.nio.DirectByteBuffer"); Constructor ctor = cl.getDeclaredConstructor( - new Class[] { int.class, - long.class, - FileDescriptor.class, - Runnable.class }); + new Class[] { int.class, + long.class, + FileDescriptor.class, + Runnable.class }); ctor.setAccessible(true); directByteBufferConstructor = ctor; } catch (ClassNotFoundException | @@ -408,10 +408,10 @@ class Util { try { Class cl = Class.forName("java.nio.DirectByteBufferR"); Constructor ctor = cl.getDeclaredConstructor( - new Class[] { int.class, - long.class, - FileDescriptor.class, - Runnable.class }); + new Class[] { int.class, + long.class, + FileDescriptor.class, + Runnable.class }); ctor.setAccessible(true); directByteBufferRConstructor = ctor; } catch (ClassNotFoundException | -Chris. From chris.hegarty at oracle.com Tue Oct 25 12:40:28 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 13:40:28 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA6A3E4.2080900@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> <4EA69CDA.70308@oracle.com> <4EA69FDA.1030109@oracle.com> <4EA6A2B6.1060406@oracle.com> <4EA6A3E4.2080900@oracle.com> Message-ID: <4EA6AE3C.8010202@oracle.com> To close the loop on this one. I filed CR 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util And posted a request for review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007995.html -Chris. On 10/25/11 12:56 PM, Chris Hegarty wrote: > On 10/25/11 12:51 PM, David Holmes wrote: >> On 25/10/2011 9:39 PM, Chris Hegarty wrote: >>> On 10/25/11 12:26 PM, David Holmes wrote: >>>> >>>> I suspect this is another case of a partial build causing files to be >>>> compiled with different settings. I'll try another clean build. >>> >>> Yeap, kinda but officially the other way around ;-) A full build for me >>> is ok, but when I clobber nio ('cd make/java/nio' 'make clobber') and >>> rebuild just nio ('cd make/java/nio' 'make') I can see the problem. It >>> looks like this class is being implicitly compiled earlier in the build >>> process, and by a makefile without -Werror. >> >> Yep that's the scenario. I've actually seen lots of warnings doing >> partial builds. I guess if we turn -Werror on everywhere they will all >> be exposed. > > Sasha, Kurchi, and others, are making their way through the core > libraries area fixing all the javac warnings. They are enabling -Werror > once they complete a specific area to ensure warnings don't creep back > in. I guess because some of these classes were not being recompiled by > the java/nio makefile this just slipped through. Eventually, the goal > will be to compile everything with -Werror :-) Happy days! > > -Chris. > >> >> Thanks, >> David >> >>> >>> In fact, I see a few other warnings: >>> >>> ./../../src/share/classes/java/nio/charset/Charset.java:438: warning: >>> [rawtypes] found raw type: Class >>> Class epc >>> ^ >>> missing type arguments for generic class Class >>> where T is a type-variable: >>> T extends Object declared in class Class >>> error: warnings found and -Werror specified >>> ../../../src/share/classes/sun/nio/ch/Util.java:366: warning: [rawtypes] >>> found raw type: Class >>> new Class[] { int.class, >>> ^ >>> missing type arguments for generic class Class >>> where T is a type-variable: >>> T extends Object declared in class Class >>> ../../../src/share/classes/sun/nio/ch/Util.java:411: warning: [rawtypes] >>> found raw type: Class >>> new Class[] { int.class, >>> ^ >>> missing type arguments for generic class Class >>> where T is a type-variable: >>> T extends Object declared in class Class >>> 1 error >>> 3 warnings >>> make381: *** [.compile.classlist] Error 1 >>> >>> I'll file a CR and have this fixed. >>> >>> -Chris. >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> -Chris >>>>> >>>>> On 10/25/11 11:23 AM, David Holmes wrote: >>>>>> I'm getting a build error due to -Werror and the fact that Util.java >>>>>> uses a raw type: "new Class[] { ...}" and so generates a raw type >>>>>> warning >>>>>> >>>>>> David From Alan.Bateman at oracle.com Tue Oct 25 12:46:03 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Oct 2011 13:46:03 +0100 Subject: build error: sun/nio/ch/Util.java ? In-Reply-To: <4EA6A3E4.2080900@oracle.com> References: <4EA68E24.7010507@oracle.com> <4EA693F6.4020704@oracle.com> <4EA69CDA.70308@oracle.com> <4EA69FDA.1030109@oracle.com> <4EA6A2B6.1060406@oracle.com> <4EA6A3E4.2080900@oracle.com> Message-ID: <4EA6AF8B.3040008@oracle.com> On 25/10/2011 12:56, Chris Hegarty wrote: > > Sasha, Kurchi, and others, are making their way through the core > libraries area fixing all the javac warnings. They are enabling > -Werror once they complete a specific area to ensure warnings don't > creep back in. I guess because some of these classes were not being > recompiled by the java/nio makefile this just slipped through. There's been a couple of cases like this since -Werror has been turned on in selected areas. I think Sasha was mostly doing full builds so he wouldn't have seen the issues we see when clobber and rebuilding a specific area. Anyway, these warnings are trivial to fix. -Alan. From maurizio.cimadamore at oracle.com Tue Oct 25 12:55:58 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 25 Oct 2011 13:55:58 +0100 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util In-Reply-To: <4EA6AD6B.3040808@oracle.com> References: <4EA6AD6B.3040808@oracle.com> Message-ID: <4EA6B1DE.5010707@oracle.com> Approved Maurizio On 25/10/11 13:36, Chris Hegarty wrote: > The changes to remove warnings from the NIO code (7068616) missed > java/nio/charset/Charset.java and sun/nio/ch/Util.java. This was not > spotted at the time as the compiler was not generating raw type > warnings for anonymous inner classes. It does now, see CR 7090499. > > This is not an issue when doing a full build because the classes are > compiled implicitly, but when re-building then JAVAC_MAX_WARNINGS and > JAVAC_WARNINGS_FATAL are set by make/java/nio/Makefile and so the > warning is fatal. > > diff -r 72666cd49ac3 src/share/classes/java/nio/charset/Charset.java > --- a/src/share/classes/java/nio/charset/Charset.java Tue Oct 25 > 09:27:20 2011 +0100 > +++ b/src/share/classes/java/nio/charset/Charset.java Tue Oct 25 > 13:38:06 2011 +0100 > @@ -435,7 +435,7 @@ public abstract class Charset > AccessController.doPrivileged(new PrivilegedAction() { > public Object run() { > try { > - Class epc > + Class epc > = > Class.forName("sun.nio.cs.ext.ExtendedCharsets"); > extendedProvider = > (CharsetProvider)epc.newInstance(); > } catch (ClassNotFoundException x) { > diff -r 72666cd49ac3 src/share/classes/sun/nio/ch/Util.java > --- a/src/share/classes/sun/nio/ch/Util.java Tue Oct 25 09:27:20 > 2011 +0100 > +++ b/src/share/classes/sun/nio/ch/Util.java Tue Oct 25 13:38:06 > 2011 +0100 > @@ -363,10 +363,10 @@ class Util { > try { > Class cl = > Class.forName("java.nio.DirectByteBuffer"); > Constructor ctor = cl.getDeclaredConstructor( > - new Class[] { int.class, > - long.class, > - FileDescriptor.class, > - Runnable.class }); > + new Class[] { int.class, > + long.class, > + FileDescriptor.class, > + Runnable.class }); > ctor.setAccessible(true); > directByteBufferConstructor = ctor; > } catch (ClassNotFoundException | > @@ -408,10 +408,10 @@ class Util { > try { > Class cl = > Class.forName("java.nio.DirectByteBufferR"); > Constructor ctor = cl.getDeclaredConstructor( > - new Class[] { int.class, > - long.class, > - FileDescriptor.class, > - Runnable.class }); > + new Class[] { int.class, > + long.class, > + FileDescriptor.class, > + Runnable.class }); > ctor.setAccessible(true); > directByteBufferRConstructor = ctor; > } catch (ClassNotFoundException | > > -Chris. From Alan.Bateman at oracle.com Tue Oct 25 12:57:45 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Oct 2011 13:57:45 +0100 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util In-Reply-To: <4EA6AD6B.3040808@oracle.com> References: <4EA6AD6B.3040808@oracle.com> Message-ID: <4EA6B249.4060308@oracle.com> On 25/10/2011 13:36, Chris Hegarty wrote: > The changes to remove warnings from the NIO code (7068616) missed > java/nio/charset/Charset.java and sun/nio/ch/Util.java. This was not > spotted at the time as the compiler was not generating raw type > warnings for anonymous inner classes. It does now, see CR 7090499. Looks fine to me. -Alan From chris.hegarty at oracle.com Tue Oct 25 14:32:43 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2011 15:32:43 +0100 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util In-Reply-To: <4EA6B249.4060308@oracle.com> References: <4EA6AD6B.3040808@oracle.com> <4EA6B249.4060308@oracle.com> Message-ID: <4EA6C88B.9030904@oracle.com> Alan, I found the same problem in the net and security makefiles, incremental build fails because of raw type warnings. I can file another CR or amend the category and description of this one, to be more generic. The changes are similarity trivial: hg diff src/share/classes/java/net/InetAddress.java src/share/classes/java/net/ServerSocket.java src/share/classes/java/security/Security.java make/sun/net/Makefile diff -r 72666cd49ac3 make/sun/net/Makefile --- a/make/sun/net/Makefile Tue Oct 25 09:27:20 2011 +0100 +++ b/make/sun/net/Makefile Tue Oct 25 15:31:19 2011 +0100 @@ -28,6 +28,7 @@ PRODUCT = sun PRODUCT = sun SUBDIRS_MAKEFLAGS += JAVAC_MAX_WARNINGS=true SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true +SUBDIRS_MAKEFLAGS += JAVAC_LINT_OPTIONS=-Xlint:all,-deprecation,-path include $(BUILDDIR)/common/Defs.gmk SUBDIRS = others spi diff -r 72666cd49ac3 src/share/classes/java/net/InetAddress.java --- a/src/share/classes/java/net/InetAddress.java Tue Oct 25 09:27:20 2011 +0100 +++ b/src/share/classes/java/net/InetAddress.java Tue Oct 25 15:31:19 2011 +0100 @@ -876,10 +876,12 @@ class InetAddress implements java.io.Ser nameService = java.security.AccessController.doPrivileged( new java.security.PrivilegedExceptionAction() { public NameService run() { - Iterator itr = Service.providers(NameServiceDescriptor.class); + // sun.misc.Service.providers returns a raw Iterator + @SuppressWarnings("unchecked") + Iterator itr = + Service.providers(NameServiceDescriptor.class); while (itr.hasNext()) { - NameServiceDescriptor nsd - = (NameServiceDescriptor)itr.next(); + NameServiceDescriptor nsd = itr.next(); if (providerName. equalsIgnoreCase(nsd.getType()+"," +nsd.getProviderName())) { diff -r 72666cd49ac3 src/share/classes/java/net/ServerSocket.java --- a/src/share/classes/java/net/ServerSocket.java Tue Oct 25 09:27:20 2011 +0100 +++ b/src/share/classes/java/net/ServerSocket.java Tue Oct 25 15:31:19 2011 +0100 @@ -267,10 +267,9 @@ class ServerSocket implements java.io.Cl AccessController.doPrivileged( new PrivilegedExceptionAction() { public Void run() throws NoSuchMethodException { - Class[] cl = new Class[2]; - cl[0] = SocketAddress.class; - cl[1] = Integer.TYPE; - impl.getClass().getDeclaredMethod("connect", cl); + impl.getClass().getDeclaredMethod("connect", + SocketAddress.class, + int.class); return null; } }); diff -r 72666cd49ac3 src/share/classes/java/security/Security.java --- a/src/share/classes/java/security/Security.java Tue Oct 25 09:27:20 2011 +0100 +++ b/src/share/classes/java/security/Security.java Tue Oct 25 15:31:19 2011 +0100 @@ -814,7 +814,7 @@ public final class Security { public Void run() { try { /* Get the class via the bootstrap class loader. */ - Class cl = Class.forName( + Class cl = Class.forName( "java.lang.SecurityManager", false, null); Field f = null; boolean accessible = -Chris. On 10/25/11 01:57 PM, Alan Bateman wrote: > On 25/10/2011 13:36, Chris Hegarty wrote: >> The changes to remove warnings from the NIO code (7068616) missed >> java/nio/charset/Charset.java and sun/nio/ch/Util.java. This was not >> spotted at the time as the compiler was not generating raw type >> warnings for anonymous inner classes. It does now, see CR 7090499. > Looks fine to me. > > -Alan From maurizio.cimadamore at oracle.com Tue Oct 25 14:41:55 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 25 Oct 2011 14:41:55 +0000 Subject: hg: jdk8/tl/langtools: 7104618: MessageInfo.java is failing after lexer changes Message-ID: <20111025144200.CE2C647112@hg.openjdk.java.net> Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java From Alan.Bateman at oracle.com Tue Oct 25 14:55:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Oct 2011 15:55:59 +0100 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util In-Reply-To: <4EA6C88B.9030904@oracle.com> References: <4EA6AD6B.3040808@oracle.com> <4EA6B249.4060308@oracle.com> <4EA6C88B.9030904@oracle.com> Message-ID: <4EA6CDFF.9010009@oracle.com> On 25/10/2011 15:32, Chris Hegarty wrote: > Alan, > > I found the same problem in the net and security makefiles, > incremental build fails because of raw type warnings. > > I can file another CR or amend the category and description of this > one, to be more generic. Might as well fix these with the same change-set. The changes look fine, just surprised that InetAddress is still using sun.misc.Service. -Alan. From Ulf.Zibis at gmx.de Tue Oct 25 14:55:59 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 25 Oct 2011 16:55:59 +0200 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util In-Reply-To: <4EA6C88B.9030904@oracle.com> References: <4EA6AD6B.3040808@oracle.com> <4EA6B249.4060308@oracle.com> <4EA6C88B.9030904@oracle.com> Message-ID: <4EA6CDFF.3030308@gmx.de> All looks fine to me. -Ulf Am 25.10.2011 16:32, schrieb Chris Hegarty: > Alan, > > I found the same problem in the net and security makefiles, incremental build fails because of raw > type warnings. > > I can file another CR or amend the category and description of this one, to be more generic. > > The changes are similarity trivial: > > .... > > > On 10/25/11 01:57 PM, Alan Bateman wrote: >> On 25/10/2011 13:36, Chris Hegarty wrote: >>> The changes to remove warnings from the NIO code (7068616) missed >>> java/nio/charset/Charset.java and sun/nio/ch/Util.java. This was not >>> spotted at the time as the compiler was not generating raw type >>> warnings for anonymous inner classes. It does now, see CR 7090499. >> Looks fine to me. >> >> -Alan > From Ulf.Zibis at gmx.de Tue Oct 25 15:02:15 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 25 Oct 2011 17:02:15 +0200 Subject: Bug 6963115 - String.split() returns wrong result on short sequence Message-ID: <4EA6CF77.4060301@gmx.de> Hi, I do not agree to the evaluation on http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6963115 because: > Same as the "x".split("x") case, this is a "match found" situation, > the resulting empty string is now a "trailing empty string", Yes, but don't forget the leading empty string. In my understanding, the main purpose of the split() method is to parse CSV data. So IMHO user would expect following results for .split(";"): "abc;def;" --> { "abc", "def" } "abc;def" --> { "abc", "def" } "abc;;def;" --> { "abc", "", "def" } "abc;def;;" --> { "abc", "def", "" } ";def;" --> { "", "def" } ";;def" --> { "", "", "def" } ";;" --> { "", "" } ";" --> { "" } "" --> { "" } or even { } The most strange in current implementation is, that if strB = strA+something, so that strB.length() > strA.length(), but strB.split(x).length < strA.split(x).length. I can accept for the 1st example: "".split("x").length = 1 ... but then for the 2nd we should have "x".split("x").length >= 1 -Ulf From mike.duigou at oracle.com Tue Oct 25 16:28:23 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 25 Oct 2011 09:28:23 -0700 Subject: Code Review 7104209: Cleanup and remove librmi (native library) In-Reply-To: <4EA66E81.8090700@oracle.com> References: <4EA5743F.1030601@oracle.com> <4EA66E81.8090700@oracle.com> Message-ID: <0A8906BD-0F1B-4051-812A-FCB37F4A9F6A@oracle.com> Looks good from me as well. Seems like a strange location to have the load library! Mike On Oct 25 2011, at 01:08 , Alan Bateman wrote: > > It turns out there's a problem with these changes as it didn't remove the code to load the rmi library (we missed it in the code review too). The result is that most of the RMI tests are now failing. I've just created 7104577 for this. The diffs are trivial - can I get a reviewer and we'll sweep this under the rug quickly - thanks, Alan. > > diff --git a/src/share/classes/sun/rmi/server/MarshalInputStream.java b/src/share/classes/sun/rmi/server/MarshalInputStream.java > --- a/src/share/classes/sun/rmi/server/MarshalInputStream.java > +++ b/src/share/classes/sun/rmi/server/MarshalInputStream.java > @@ -107,14 +107,6 @@ public class MarshalInputStream extends > throw new NoClassDefFoundError("Missing system class: " + > e.getMessage()); > } > - } > - > - /** > - * Load the "rmi" native library. > - */ > - static { > - java.security.AccessController.doPrivileged( > - new sun.security.action.LoadLibraryAction("rmi")); > } > > /** > From jonathan.gibbons at oracle.com Tue Oct 25 17:48:46 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 25 Oct 2011 17:48:46 +0000 Subject: hg: jdk8/tl/langtools: 7104039: refactor/cleanup javac Paths class Message-ID: <20111025174848.C198547115@hg.openjdk.java.net> Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java From david.holmes at oracle.com Wed Oct 26 00:37:45 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Oct 2011 10:37:45 +1000 Subject: Code Review 7104650: rawtype warnings in java.nio.charset.Charset and sun.nio.ch.Util In-Reply-To: <4EA6CDFF.3030308@gmx.de> References: <4EA6AD6B.3040808@oracle.com> <4EA6B249.4060308@oracle.com> <4EA6C88B.9030904@oracle.com> <4EA6CDFF.3030308@gmx.de> Message-ID: <4EA75659.6080907@oracle.com> I'll belatedly add my thumbs up. Thanks Chris! David On 26/10/2011 12:55 AM, Ulf Zibis wrote: > All looks fine to me. > > -Ulf > > > Am 25.10.2011 16:32, schrieb Chris Hegarty: >> Alan, >> >> I found the same problem in the net and security makefiles, >> incremental build fails because of raw type warnings. >> >> I can file another CR or amend the category and description of this >> one, to be more generic. >> >> The changes are similarity trivial: >> >> .... >> >> >> On 10/25/11 01:57 PM, Alan Bateman wrote: >>> On 25/10/2011 13:36, Chris Hegarty wrote: >>>> The changes to remove warnings from the NIO code (7068616) missed >>>> java/nio/charset/Charset.java and sun/nio/ch/Util.java. This was not >>>> spotted at the time as the compiler was not generating raw type >>>> warnings for anonymous inner classes. It does now, see CR 7090499. >>> Looks fine to me. >>> >>> -Alan >> From jim.holmlund at sun.com Wed Oct 26 02:19:45 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 26 Oct 2011 02:19:45 +0000 Subject: hg: jdk8/tl/langtools: 7104905: Java SE build fails on call to CreateSymbols Message-ID: <20111026021948.C5E5447123@hg.openjdk.java.net> Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java From chris.hegarty at oracle.com Wed Oct 26 12:59:30 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 26 Oct 2011 12:59:30 +0000 Subject: hg: jdk8/tl/jdk: 7104650: rawtype warnings in several net, nio and security source files Message-ID: <20111026125941.92FCD47129@hg.openjdk.java.net> Changeset: 88a260444e4d Author: chegar Date: 2011-10-26 13:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88a260444e4d 7104650: rawtype warnings in several net, nio and security source files Summary: Also reviewed by Ulf.Zibis at gmx.de Reviewed-by: mcimadamore, alanb, dholmes ! make/sun/net/Makefile ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/security/Security.java ! src/share/classes/sun/nio/ch/Util.java From yuka.kamiya at oracle.com Wed Oct 26 13:18:19 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Wed, 26 Oct 2011 13:18:19 +0000 Subject: hg: jdk8/tl/jdk: 7090046: Lots of invalid link in java.text.BreakIterator comments Message-ID: <20111026131829.155024712C@hg.openjdk.java.net> Changeset: 0d371f2911a1 Author: peytoia Date: 2011-10-26 22:16 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d371f2911a1 7090046: Lots of invalid link in java.text.BreakIterator comments Reviewed-by: okutsu ! src/share/classes/java/text/BreakIterator.java From lana.steuck at oracle.com Wed Oct 26 19:52:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:52:54 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20111026195254.8B64547139@hg.openjdk.java.net> Changeset: 0db7ae9f2b10 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0db7ae9f2b10 Added tag jdk8-b06 for changeset 28cf2aec4dd7 ! .hgtags Changeset: cf76aa4189e4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cf76aa4189e4 Added tag jdk8-b07 for changeset 0db7ae9f2b10 ! .hgtags Changeset: 2f1af0e3e8f7 Author: lana Date: 2011-09-26 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2f1af0e3e8f7 Merge Changeset: fb1bc13260d7 Author: lana Date: 2011-10-03 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fb1bc13260d7 Merge Changeset: 8adb70647b5a Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8adb70647b5a Added tag jdk8-b08 for changeset fb1bc13260d7 ! .hgtags Changeset: a6c4c248e8fa Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a6c4c248e8fa Added tag jdk8-b09 for changeset 8adb70647b5a ! .hgtags Changeset: 1defbc57940a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1defbc57940a Added tag jdk8-b10 for changeset a6c4c248e8fa ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:52:57 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:52:57 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20111026195257.9C6754713A@hg.openjdk.java.net> Changeset: c114306576dc Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c114306576dc Added tag jdk8-b06 for changeset d7b8192e7277 ! .hgtags Changeset: de4794dd69c4 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/de4794dd69c4 Added tag jdk8-b07 for changeset c114306576dc ! .hgtags Changeset: 93554324c014 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/93554324c014 Added tag jdk8-b08 for changeset de4794dd69c4 ! .hgtags Changeset: d21a4d5141c0 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d21a4d5141c0 Added tag jdk8-b09 for changeset 93554324c014 ! .hgtags Changeset: d1b7a4f6dd20 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d1b7a4f6dd20 Added tag jdk8-b10 for changeset d21a4d5141c0 ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:53:03 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:53:03 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20111026195303.DD0074713B@hg.openjdk.java.net> Changeset: 134b0debf7b0 Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/134b0debf7b0 Added tag jdk8-b06 for changeset acffff22a946 ! .hgtags Changeset: 1c9d4f59acf8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1c9d4f59acf8 Added tag jdk8-b07 for changeset 134b0debf7b0 ! .hgtags Changeset: 70172e57cf29 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/70172e57cf29 Added tag jdk8-b08 for changeset 1c9d4f59acf8 ! .hgtags Changeset: 8e7fdc8e3c75 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8e7fdc8e3c75 Added tag jdk8-b09 for changeset 70172e57cf29 ! .hgtags Changeset: a12ab897a249 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a12ab897a249 Added tag jdk8-b10 for changeset 8e7fdc8e3c75 ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:52:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:52:54 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20111026195304.B18FC4713C@hg.openjdk.java.net> Changeset: 3d61f0856f34 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3d61f0856f34 Added tag jdk8-b06 for changeset 45c43dde7ba7 ! .hgtags Changeset: 0d52b1c87aa8 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0d52b1c87aa8 Added tag jdk8-b07 for changeset 3d61f0856f34 ! .hgtags Changeset: a891732c1a83 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a891732c1a83 Added tag jdk8-b08 for changeset 0d52b1c87aa8 ! .hgtags Changeset: cda87f7fefce Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cda87f7fefce Added tag jdk8-b09 for changeset a891732c1a83 ! .hgtags Changeset: 0199e4fef5cc Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0199e4fef5cc Added tag jdk8-b10 for changeset cda87f7fefce ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:53:19 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:53:19 +0000 Subject: hg: jdk8/tl/langtools: 11 new changesets Message-ID: <20111026195345.28F894713D@hg.openjdk.java.net> Changeset: 116980ecec5c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/116980ecec5c Added tag jdk8-b06 for changeset d2422276f9da ! .hgtags Changeset: 9268bd271c6f Author: katleman Date: 2011-09-29 18:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9268bd271c6f Added tag jdk8-b07 for changeset 116980ecec5c ! .hgtags Changeset: 28573d605b01 Author: lana Date: 2011-09-26 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/28573d605b01 Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: e8acc2d6c32f Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e8acc2d6c32f Merge - src/share/classes/com/sun/tools/javac/Launcher.java Changeset: b7a7e47c8d3d Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7a7e47c8d3d Added tag jdk8-b08 for changeset e8acc2d6c32f ! .hgtags Changeset: 510d09ddc861 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/510d09ddc861 Added tag jdk8-b09 for changeset b7a7e47c8d3d ! .hgtags Changeset: 5010ffc61eda Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5010ffc61eda Merge Changeset: f6c783e18bdf Author: lana Date: 2011-10-17 19:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6c783e18bdf Merge Changeset: 4bf01f1c4e34 Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4bf01f1c4e34 Added tag jdk8-b10 for changeset f6c783e18bdf ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java From lana.steuck at oracle.com Wed Oct 26 19:53:43 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:53:43 +0000 Subject: hg: jdk8/tl/hotspot: 114 new changesets Message-ID: <20111026195720.E89684713E@hg.openjdk.java.net> Changeset: 3f0cf875af83 Author: katleman Date: 2011-09-22 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f0cf875af83 Added tag jdk8-b06 for changeset 0db80d8e77fc ! .hgtags Changeset: 0663e7617095 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0663e7617095 Added tag jdk8-b07 for changeset 3f0cf875af83 ! .hgtags Changeset: 5755e84e970f Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5755e84e970f Added tag hs22-b01 for changeset 0cc8a70952c3 ! .hgtags Changeset: 40c5e268d399 Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40c5e268d399 Added tag hs22-b02 for changeset 7c29742c41b4 ! .hgtags Changeset: 52220701f19f Author: jcoomes Date: 2011-09-02 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52220701f19f Added tag hs22-b03 for changeset 3a2fb61165df ! .hgtags Changeset: ce9bde819dcb Author: jcoomes Date: 2011-09-02 03:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce9bde819dcb 7086589: bump the hs22 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5c123cbeebbe Author: jcoomes Date: 2011-09-02 15:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c123cbeebbe Added tag hs22-b04 for changeset ce9bde819dcb ! .hgtags Changeset: 3cd0157e1d4d Author: iveresov Date: 2011-08-25 02:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3cd0157e1d4d 7082969: NUMA interleaving Summary: Support interleaving on NUMA systems for collectors that don't have NUMA-awareness. Reviewed-by: iveresov, ysr Contributed-by: Tom Deneau ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: eeae91c9baba Author: johnc Date: 2011-08-29 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eeae91c9baba 7080389: G1: refactor marking code in evacuation pause copy closures Summary: Refactor code marking code in the evacuation pause copy closures so that an evacuated object is only marked by the thread that successfully copies it. Reviewed-by: stefank, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp Changeset: 9447b2fb6fcf Author: iveresov Date: 2011-08-29 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9447b2fb6fcf 7082645: Hotspot doesn't compile on old linuxes after 7060836 Summary: Move syscall ids definitions into os_linux.cpp Reviewed-by: johnc ! src/os/linux/vm/os_linux.cpp Changeset: 4fe626cbf0bf Author: johnc Date: 2011-08-31 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fe626cbf0bf 7066841: remove MacroAssembler::br_on_reg_cond() on sparc Summary: Remove the macro assembler routine br_on_reg_cond() and replace the remaining calls to that routine with an equivalent. Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae1b1788f63f Author: ysr Date: 2011-08-31 23:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae1b1788f63f Merge Changeset: 4668545121b8 Author: jcoomes Date: 2011-09-02 21:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4668545121b8 Merge Changeset: ac8738449b6f Author: never Date: 2011-08-25 20:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac8738449b6f 7082949: JSR 292: missing ResourceMark in methodOopDesc::make_invoke_method Reviewed-by: kvn, twisti ! src/share/vm/oops/methodOop.cpp + test/compiler/7082949/Test7082949.java Changeset: baf763f388e6 Author: kvn Date: 2011-08-26 08:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/baf763f388e6 7059037: Use BIS for zeroing on T4 Summary: Use BIS for zeroing new allocated big (2Kb and more) objects and arrays. Reviewed-by: never, twisti, ysr ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: 8805f8c1e23e Author: iveresov Date: 2011-08-27 00:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8805f8c1e23e 6591247: C2 cleans up the merge point too early during SplitIf Summary: Remove region self reference last Reviewed-by: kvn, never ! src/share/vm/opto/split_if.cpp Changeset: b27c72d69fd1 Author: twisti Date: 2011-08-29 05:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b27c72d69fd1 7083184: JSR 292: don't store context class argument with call site dependencies Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 19241ae0d839 Author: never Date: 2011-08-30 00:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19241ae0d839 7082263: Reflection::resolve_field/field_get/field_set are broken Reviewed-by: kvn, dholmes, stefank, coleenp ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/jvmg.make - make/solaris/makefiles/mapfile-vers-nonproduct ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp - src/share/vm/runtime/reflectionCompat.hpp Changeset: b346f13112d8 Author: iveresov Date: 2011-08-30 19:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b346f13112d8 7085279: C1 overflows code buffer with VerifyOops and CompressedOops Summary: Increase the limit of code emitted per LIR instruction, increase the max size of the nmethod generated by C1 Reviewed-by: never, kvn, johnc ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: de847cac9235 Author: twisti Date: 2011-08-31 01:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de847cac9235 7078382: JSR 292: don't count method handle adapters against inlining budgets Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/bytecodeInfo.cpp Changeset: a64d352d1118 Author: kvn Date: 2011-08-31 09:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a64d352d1118 7085137: -XX:+VerifyOops is broken Summary: Replace set() with patchable_set() to generate 8 instructions always. Reviewed-by: iveresov, never, roland ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad Changeset: c124e2e7463e Author: never Date: 2011-08-31 16:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c124e2e7463e 7083786: dead various dead chunks of code Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a32de5085326 Author: twisti Date: 2011-09-01 01:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a32de5085326 7079673: JSR 292: C1 should inline bytecoded method handle adapters Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/parse.hpp Changeset: aa67216400d3 Author: twisti Date: 2011-09-02 00:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa67216400d3 7085404: JSR 292: VolatileCallSites should have push notification too Reviewed-by: never, kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 11a4af030e4b Author: twisti Date: 2011-09-02 04:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11a4af030e4b 7071709: JSR 292: switchpoint invalidation should be pushed not pulled Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse3.cpp Changeset: 2f9b79ddb05c Author: kvn Date: 2011-09-02 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f9b79ddb05c 7039731: arraycopy could use prefetch on SPARC Summary: Use BIS and prefetch in arraycopy stubs for Sparc (BIS for T4 only). Reviewed-by: never, iveresov ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2090c623107e Author: never Date: 2011-09-02 22:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2090c623107e 7016881: JSR 292: JDI: sun.jvm.hotspot.utilities.AssertionFailure: index out of bounds Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java Changeset: c26de9aef2ed Author: never Date: 2011-09-02 20:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c26de9aef2ed 7071307: MethodHandle bimorphic inlining should consider the frequency Reviewed-by: twisti, roland, kvn, iveresov ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 7ffacbb338d4 Author: never Date: 2011-09-03 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ffacbb338d4 Merge Changeset: 7b5c767f229c Author: kvn Date: 2011-09-03 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b5c767f229c 7086560: 7085404 changes broke VM with -XX:-EnableInvokeDynamic Summary: Add check that ciEnv::_CallSite_klass is initialized. Reviewed-by: jrose ! src/share/vm/ci/ciField.hpp Changeset: 7588156f5cf9 Author: never Date: 2011-09-05 17:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7588156f5cf9 7051798: SA-JDI: NPE in Frame.addressOfStackSlot(Frame.java:244) Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java + agent/src/share/classes/sun/jvm/hotspot/code/MethodHandlesAdapterBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/RuntimeStub.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapSet.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/StackFrameImpl.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/solaris_amd64/SolarisAMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c2d3caa64b3e Author: roland Date: 2011-09-07 09:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2d3caa64b3e 7086394: c2/arm: enable UseFPUForSpilling Summary: ARM has instructions to move data directly between the fpu and integer registers. Reviewed-by: kvn, never ! src/share/vm/opto/matcher.cpp Changeset: d968f546734e Author: iveresov Date: 2011-09-07 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d968f546734e Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/reflectionCompat.hpp Changeset: 2fecca53a2c6 Author: roland Date: 2011-09-07 14:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2fecca53a2c6 7085012: ARM: com/sun/jdi/PopSynchronousTest.java still fails Summary: InterpreterRuntime::popframe_move_outgoing_args() is required for the ARM interpreter. Reviewed-by: kvn, twisti ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: 5596e125fe4f Author: rottenha Date: 2011-09-08 06:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5596e125fe4f Merge ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 27702f012017 Author: iveresov Date: 2011-09-06 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/27702f012017 7087583: Hotspot fails to allocate heap with mmap(MAP_HUGETLB) Summary: Try using small pages when transparent huge pages allocation fails Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 20213c8a3c40 Author: tonyp Date: 2011-09-07 12:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20213c8a3c40 7050392: G1: Introduce flag to generate a log of the G1 ergonomic decisions Summary: It introduces ergonomic decision logging in G1 for the following heuristics: heap sizing, collection set construction, concurrent cycle initiation, and partially-young GC start/end. The code has a bit of refactoring in a few places to make the decision logging possible. It also replaces alternative ad-hoc logging that we have under different parameters and switches (G1_DEBUG, G1PolicyVerbose). Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! 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/g1ErgoVerbose.cpp + src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c2bf0120ee5d Author: stefank Date: 2011-09-01 16:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c2bf0120ee5d 7085906: Replace the permgen allocated sentinelRef with a self-looped end Summary: Remove the sentinelRef and let the last Reference in a discovered chain point back to itself. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: 05550041d664 Author: ysr Date: 2011-09-07 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05550041d664 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: eca1193ca245 Author: ysr Date: 2011-09-07 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eca1193ca245 4965777: GC changes to support use of discovered field for pending references Summary: If and when the reference handler thread is able to use the discovered field to link reference objects in its pending list, so will GC. In that case, GC will scan through this field once a reference object has been placed on the pending list, but not scan that field before that stage, as the field is used by the concurrent GC thread to link discovered objects. When ReferenceHandleR thread does not use the discovered field for the purpose of linking the elements in the pending list, as would be the case in older JDKs, the JVM will fall back to the old behaviour of using the next field for that purpose. Reviewed-by: jcoomes, mchung, stefank ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp Changeset: a6128a8ed624 Author: iveresov Date: 2011-09-07 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6128a8ed624 7086226: UseNUMA fails on old versions of windows Summary: Return correct answers from os::numa_*() for UMA machines or if NUMA API is not supported Reviewed-by: johnc ! src/os/windows/vm/os_windows.cpp Changeset: 4f41766176cf Author: tonyp Date: 2011-09-08 05:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f41766176cf 7084509: G1: fix inconsistencies and mistakes in the young list target length calculations Summary: Fixed inconsistencies and mistakes in the young list target length calculations so that a) the calculated target length is optimal (before, it was not), b) other parameters like max survivor size and max gc locker eden expansion are always consistent with the calculated target length (before, they were not always), and c) the resulting target length was always bound by desired min and max values (before, it was not). Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! 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/g1_globals.hpp Changeset: af2ab04e0038 Author: brutisso Date: 2011-09-08 16:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af2ab04e0038 6929868: G1: introduce min / max young gen size bounds Summary: Make G1 handle young gen size command line flags more consistently Reviewed-by: tonyp, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 3bddbf0f57d6 Author: tonyp Date: 2011-09-09 05:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3bddbf0f57d6 7087717: G1: make the G1PrintRegionLivenessInfo parameter diagnostic Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: e984655be425 Author: stefank Date: 2011-09-09 14:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e984655be425 Merge ! src/share/vm/prims/jvm.h Changeset: 79f9a3ed607a Author: jcoomes Date: 2011-09-09 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79f9a3ed607a Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 513a84dd0f8b Author: jcoomes Date: 2011-09-09 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513a84dd0f8b 7088991: Bump ths hs22 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 140317da459a Author: jcoomes Date: 2011-09-09 16:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/140317da459a Added tag hs22-b05 for changeset 513a84dd0f8b ! .hgtags Changeset: f1b4e0e0bdad Author: tonyp Date: 2011-09-13 12:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1b4e0e0bdad 7089625: G1: policy for how many old regions to add to the CSet (when young gen is fixed) is broken Summary: When refactoring the code for a previous fix, a condition was not correctly negated which prevents the G1 policy from adding the correct number of old regions to the CSet when the young gen size is fixed. The changeset also fixes a small syntactical issue in g1ErgoVerbose.hpp which is causing compiler warnings. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp Changeset: 0a63380c8ac8 Author: iveresov Date: 2011-09-13 16:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a63380c8ac8 7090069: Java launcher hangs in infinite loop on windows when UseNUMA[Interleaving] is specified Summary: Fix _numa_used_node_list array size specification Reviewed-by: kvn, johnc, jmasa, ysr ! src/os/windows/vm/os_windows.cpp Changeset: f94227b6117b Author: kvn Date: 2011-09-13 20:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f94227b6117b 7090259: Fix hotspot sources to build with old compilers Summary: Fixed warnings which prevent building VM with old compilers. Reviewed-by: never ! make/solaris/makefiles/sparcWorks.make ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/block.cpp Changeset: da6a29fb0da5 Author: kvn Date: 2011-09-07 12:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da6a29fb0da5 7054211: No loop unrolling done in jdk7b144 for a test update() while loop Summary: restore unrolling code for CaffeineMark. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 5432047c7db7 Author: bdelsart Date: 2011-09-08 10:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5432047c7db7 7087445: Improve platform independence of JSR292 shared code Summary: changes necessary for some JSR292 ports Reviewed-by: jrose, dholmes ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/frame.hpp Changeset: b0efc7ee3b31 Author: twisti Date: 2011-09-08 05:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0efc7ee3b31 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: fdcb1e828d53 Author: kvn Date: 2011-09-08 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fdcb1e828d53 7087947: Add regression test for 7068051 Summary: Add regression test. Reviewed-by: never + test/compiler/7068051/Test7068051.java + test/compiler/7068051/Test7068051.sh Changeset: 8f47d8870d9a Author: roland Date: 2011-09-08 09:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f47d8870d9a 7087453: PhaseChaitin::yank_if_dead() should handle MachTemp inputs Summary: PhaseChaitin::yank_if_dead() should be able to handle MachTemp inputs as a special case and yank them. Reviewed-by: never, kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 5257f8e66b40 Author: iveresov Date: 2011-09-09 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5257f8e66b40 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 2c24ef16533d Author: kvn Date: 2011-09-09 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c24ef16533d 7035946: Up to 15% regression on JDK 7 b136 vs b135 on specjvm2008.crypto.rsa on x64 Summary: Revert changes which caused regression. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp Changeset: c565834fb592 Author: never Date: 2011-09-10 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c565834fb592 7088020: SEGV in JNIHandleBlock::release_block Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7088020/Test7088020.java Changeset: e6b1331a51d2 Author: never Date: 2011-09-10 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e6b1331a51d2 7086585: make Java field injection more flexible Reviewed-by: jrose, twisti, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/test/jdi/sasanity.sh ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCacheOop.cpp + src/share/vm/oops/fieldInfo.hpp + src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: f6f3bb0ee072 Author: never Date: 2011-09-11 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6f3bb0ee072 7088955: add C2 IR support to the SA Reviewed-by: kvn ! agent/make/Makefile ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/Makefile - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp ! agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/DebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java + agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java + agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/AddressException.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/SADebugServer.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java + agent/src/share/classes/sun/jvm/hotspot/oops/ArrayData.java + agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java + agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CIntField.java + agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java + agent/src/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/FieldType.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java + agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java + agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java + agent/src/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java + agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java + agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java + agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java + agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java + agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java + agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java + agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java + agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java + agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java + agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java + agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompilerThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java + agent/src/share/classes/sun/jvm/hotspot/runtime/StaticBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java + agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualBaseConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VirtualConstructor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/types/TypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/CommandProcessorPanel.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java + agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! make/sa.files ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: ab577c97a5f3 Author: never Date: 2011-09-12 13:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab577c97a5f3 7089709: type "jushort" not found Reviewed-by: kvn, twisti ! src/share/vm/runtime/vmStructs.cpp Changeset: 2209834ccb59 Author: kvn Date: 2011-09-13 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2209834ccb59 7089632: assert(machtmp->outcnt() == 1) failed: expected for a MachTemp Summary: Replace assert with check to delete MachTemp nodes only when they are really dead. Reviewed-by: never ! src/share/vm/opto/postaloc.cpp Changeset: 10ee2b297ccd Author: bdelsart Date: 2011-09-14 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10ee2b297ccd 7057978: improve robustness of c1 ARM back-end wrt non encodable constants Summary: ARM only, avoid assertion failures for huge constants generated by C1 shared code Reviewed-by: never, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: 393f4b789fd0 Author: bdelsart Date: 2011-09-14 16:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/393f4b789fd0 7077806: ARM: java.lang.InternalError: bound subword value does not fit into the subword type Summary: shared fix necessary for ARM/PPC Reviewed-by: twisti, roland ! src/share/vm/prims/methodHandles.hpp Changeset: 35c656d0b685 Author: never Date: 2011-09-14 13:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35c656d0b685 7090654: nightly failures after 7086585 Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 8ed53447f690 Author: iveresov Date: 2011-09-15 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ed53447f690 Merge - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java ! src/share/vm/classfile/javaClasses.cpp Changeset: 558f525a6ebe Author: jcoomes Date: 2011-09-15 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/558f525a6ebe Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 8ab2f4108d20 Author: jcoomes Date: 2011-09-15 20:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ab2f4108d20 7091294: disable quicksort tests Reviewed-by: jmasa, ysr, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 650d15d8f372 Author: jcoomes Date: 2011-09-15 20:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/650d15d8f372 7091255: Bump the hs22 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5a3c2bc614ca Author: jcoomes Date: 2011-09-15 20:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a3c2bc614ca Added tag hs22-b06 for changeset 650d15d8f372 ! .hgtags Changeset: 77e1a9153757 Author: jcoomes Date: 2011-09-16 21:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77e1a9153757 7091545: hs23 - set hotspot version & build number Reviewed-by: tonyp, never, phh, jmasa ! make/hotspot_version Changeset: da0999c4b733 Author: dcubed Date: 2011-09-16 16:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da0999c4b733 7071904: 4/4 HotSpot: Full Debug Symbols Summary: Add support for .debuginfo files for HSX libraries. Reviewed-by: poonam, dholmes, never ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile + make/solaris/makefiles/build_vm_def.sh ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/mapfile-vers ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make Changeset: 86cbe939f0c7 Author: dcubed Date: 2011-09-19 12:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86cbe939f0c7 Merge Changeset: 3607aac85aa9 Author: kevinw Date: 2011-09-22 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3607aac85aa9 7051189: Need to suppress info message if -xcheck:jni used with libjsig.so Reviewed-by: coleenp, minqi ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp + test/runtime/7051189/Xchecksig.sh Changeset: 5cceda753a4a Author: iveresov Date: 2011-09-19 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cceda753a4a 7091764: Tiered: enable aastore profiling Summary: Turn on aastore profiling Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp Changeset: 075ea0ed9e7c Author: kvn Date: 2011-09-20 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/075ea0ed9e7c 7081842: assert(Compile::current()->unique() < (uint)MaxNodeLimit) failed: Node limit exceeded Summary: Add missing node limit check in IGVN optimizer Reviewed-by: iveresov, never ! make/linux/build.sh ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/phaseX.cpp Changeset: eda6988c0d81 Author: never Date: 2011-09-20 23:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eda6988c0d81 7092236: java/util/EnumSet/EnumSetBash.java fails Reviewed-by: kvn, twisti, jrose ! src/share/vm/ci/ciEnv.cpp Changeset: f08d439fab8c Author: never Date: 2011-09-25 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f08d439fab8c 7089790: integrate bsd-port changes Reviewed-by: kvn, twisti, jrose Contributed-by: Kurt Miller , Greg Lewis , Jung-uk Kim , Christos Zoulas , Landon Fuller , The FreeBSD Foundation , Michael Franz , Roger Hoover , Alexander Strange ! agent/make/Makefile + agent/src/os/bsd/BsdDebuggerLocal.c + agent/src/os/bsd/Makefile + agent/src/os/bsd/StubDebuggerLocal.c + agent/src/os/bsd/elfmacros.h + agent/src/os/bsd/libproc.h + agent/src/os/bsd/libproc_impl.c + agent/src/os/bsd/libproc_impl.h + agent/src/os/bsd/mapfile + agent/src/os/bsd/ps_core.c + agent/src/os/bsd/ps_proc.c + agent/src/os/bsd/salibelf.c + agent/src/os/bsd/salibelf.h + agent/src/os/bsd/symtab.c + agent/src/os/bsd/symtab.h + agent/src/os/bsd/test.c + agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdOopHandle.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/SharedObject.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64ThreadContext.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdSignals.java + agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_x86/BsdX86JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile + make/bsd/Makefile + make/bsd/README + make/bsd/adlc_updater + make/bsd/build.sh + make/bsd/makefiles/adjust-mflags.sh + make/bsd/makefiles/adlc.make + make/bsd/makefiles/amd64.make + make/bsd/makefiles/arm.make + make/bsd/makefiles/build_vm_def.sh + make/bsd/makefiles/buildtree.make + make/bsd/makefiles/compiler1.make + make/bsd/makefiles/compiler2.make + make/bsd/makefiles/core.make + make/bsd/makefiles/cscope.make + make/bsd/makefiles/debug.make + make/bsd/makefiles/defs.make + make/bsd/makefiles/dtrace.make + make/bsd/makefiles/fastdebug.make + make/bsd/makefiles/gcc.make + make/bsd/makefiles/hp.make + make/bsd/makefiles/hp1.make + make/bsd/makefiles/i486.make + make/bsd/makefiles/ia64.make + make/bsd/makefiles/jsig.make + make/bsd/makefiles/jvmg.make + make/bsd/makefiles/jvmti.make + make/bsd/makefiles/launcher.make + make/bsd/makefiles/mapfile-vers-debug + make/bsd/makefiles/mapfile-vers-jsig + make/bsd/makefiles/mapfile-vers-product + make/bsd/makefiles/optimized.make + make/bsd/makefiles/ppc.make + make/bsd/makefiles/product.make + make/bsd/makefiles/profiled.make + make/bsd/makefiles/rules.make + make/bsd/makefiles/sa.make + make/bsd/makefiles/saproc.make + make/bsd/makefiles/shark.make + make/bsd/makefiles/sparc.make + make/bsd/makefiles/sparcWorks.make + make/bsd/makefiles/sparcv9.make + make/bsd/makefiles/tiered.make + make/bsd/makefiles/top.make + make/bsd/makefiles/vm.make + make/bsd/makefiles/zero.make + make/bsd/makefiles/zeroshark.make + make/bsd/platform_amd64 + make/bsd/platform_amd64.suncc + make/bsd/platform_i486 + make/bsd/platform_i486.suncc + make/bsd/platform_ia64 + make/bsd/platform_sparc + make/bsd/platform_sparcv9 + make/bsd/platform_zero.in ! make/cscope.make ! make/defs.make ! make/linux/makefiles/arm.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/ppc.make ! make/sa.files ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/copy_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/vm_version_zero.cpp + src/os/bsd/vm/attachListener_bsd.cpp + src/os/bsd/vm/c1_globals_bsd.hpp + src/os/bsd/vm/c2_globals_bsd.hpp + src/os/bsd/vm/chaitin_bsd.cpp + src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/dtraceJSDT_bsd.cpp + src/os/bsd/vm/globals_bsd.hpp + src/os/bsd/vm/interfaceSupport_bsd.hpp + src/os/bsd/vm/jsig.c + src/os/bsd/vm/jvm_bsd.cpp + src/os/bsd/vm/jvm_bsd.h + src/os/bsd/vm/mutex_bsd.cpp + src/os/bsd/vm/mutex_bsd.inline.hpp + src/os/bsd/vm/osThread_bsd.cpp + src/os/bsd/vm/osThread_bsd.hpp + src/os/bsd/vm/os_bsd.cpp + src/os/bsd/vm/os_bsd.hpp + src/os/bsd/vm/os_bsd.inline.hpp + src/os/bsd/vm/os_share_bsd.hpp + src/os/bsd/vm/perfMemory_bsd.cpp + src/os/bsd/vm/stubRoutines_bsd.cpp + src/os/bsd/vm/threadCritical_bsd.cpp + src/os/bsd/vm/thread_bsd.inline.hpp + src/os/bsd/vm/vmError_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script + src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/bsd_x86_32.ad + src/os_cpu/bsd_x86/vm/bsd_x86_32.s + src/os_cpu/bsd_x86/vm/bsd_x86_64.ad + src/os_cpu/bsd_x86/vm/bsd_x86_64.s + src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/copy_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/prefetch_bsd_x86.inline.hpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp + src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/vm_version_bsd_x86.cpp + src/os_cpu/bsd_zero/vm/assembler_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/os_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/prefetch_bsd_zero.inline.hpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp + src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp + src/os_cpu/bsd_zero/vm/vm_version_bsd_zero.cpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/share/vm/adlc/adlc.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/jprt.config ! test/runtime/6929067/Test6929067.sh Changeset: a92cdbac8b9e Author: kvn Date: 2011-09-26 10:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a92cdbac8b9e 7081933: Use zeroing elimination optimization for large array Summary: Don't zero new typeArray during runtime call if the allocation is followed by arraycopy into it. Reviewed-by: twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: cb315dc80374 Author: never Date: 2011-09-29 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb315dc80374 7092278: "jmap -finalizerinfo" throws "sun.jvm.hotspot.utilities.AssertionFailure: invalid cp index 0 137" Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 098acdf97f09 Author: never Date: 2011-09-29 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/098acdf97f09 7096016: SA build still produces "arg list too long" errors Reviewed-by: kvn, never Contributed-by: volker.simonis at gmail.com ! make/linux/makefiles/sa.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make Changeset: dc45ae774613 Author: iveresov Date: 2011-09-29 23:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc45ae774613 7096639: Tiered: Incorrect counter overflow handling for inlined methods Summary: Enable invocation events for inlinees Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: ae839d1e7d4c Author: roland Date: 2011-09-30 13:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae839d1e7d4c 7096010: c2: running with +PrintOptoAssembly crashes the VM when $constanttablebase is used Summary: ADLC generates code to prepare the register string to be printed in a char array but then calls print without the char array as an argument. Reviewed-by: never ! src/share/vm/adlc/formssel.cpp Changeset: 5d871c1ff17c Author: iveresov Date: 2011-09-30 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d871c1ff17c Merge ! make/Makefile ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! src/os/linux/vm/os_linux.cpp Changeset: da883b9e6d37 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da883b9e6d37 Merge ! .hgtags - agent/src/os/solaris/dbx/Makefile - agent/src/os/solaris/dbx/README - agent/src/os/solaris/dbx/README-commands.txt - agent/src/os/solaris/dbx/helloWorld.cpp - agent/src/os/solaris/dbx/proc_service_2.h - agent/src/os/solaris/dbx/shell_imp.h - agent/src/os/solaris/dbx/svc_agent_dbx.cpp - agent/src/os/solaris/dbx/svc_agent_dbx.hpp - agent/src/os/win32/BasicList.hpp - agent/src/os/win32/Buffer.cpp - agent/src/os/win32/Buffer.hpp - agent/src/os/win32/Dispatcher.cpp - agent/src/os/win32/Dispatcher.hpp - agent/src/os/win32/Handler.hpp - agent/src/os/win32/IOBuf.cpp - agent/src/os/win32/IOBuf.hpp - agent/src/os/win32/LockableList.hpp - agent/src/os/win32/Makefile - agent/src/os/win32/Message.hpp - agent/src/os/win32/Monitor.cpp - agent/src/os/win32/Monitor.hpp - agent/src/os/win32/README-commands.txt - agent/src/os/win32/README.txt - agent/src/os/win32/Reaper.cpp - agent/src/os/win32/Reaper.hpp - agent/src/os/win32/SwDbgSrv.cpp - agent/src/os/win32/SwDbgSrv.dsp - agent/src/os/win32/SwDbgSrv.dsw - agent/src/os/win32/SwDbgSub.cpp - agent/src/os/win32/SwDbgSub.dsp - agent/src/os/win32/initWinsock.cpp - agent/src/os/win32/initWinsock.hpp - agent/src/os/win32/ioUtils.cpp - agent/src/os/win32/ioUtils.hpp - agent/src/os/win32/isNT4.cpp - agent/src/os/win32/isNT4.hpp - agent/src/os/win32/libInfo.cpp - agent/src/os/win32/libInfo.hpp - agent/src/os/win32/nt4internals.cpp - agent/src/os/win32/nt4internals.hpp - agent/src/os/win32/ports.h - agent/src/os/win32/procList.cpp - agent/src/os/win32/procList.hpp - agent/src/os/win32/serverLists.cpp - agent/src/os/win32/serverLists.hpp - agent/src/os/win32/toolHelp.cpp - agent/src/os/win32/toolHelp.hpp - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxOopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/sparc/DbxSPARCThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/x86/DbxX86ThreadFactory.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/AddressDataSource.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/DLL.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/TestHelloWorld.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugInfoBuilder.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32CDebugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntry.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32LDTEntryConstants.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32OopHandle.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Thread.java - agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32ThreadContext.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java - make/solaris/makefiles/mapfile-vers-nonproduct - src/share/vm/runtime/reflectionCompat.hpp Changeset: 49ed7eacfd16 Author: jcoomes Date: 2011-09-30 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/49ed7eacfd16 Added tag hs23-b01 for changeset da883b9e6d37 ! .hgtags Changeset: 7c20d272643f Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c20d272643f Added tag jdk8-b08 for changeset 49ed7eacfd16 ! .hgtags Changeset: edd5f85e2de7 Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/edd5f85e2de7 Added tag jdk8-b09 for changeset 7c20d272643f ! .hgtags Changeset: 95607b70acb5 Author: jcoomes Date: 2011-09-30 22:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95607b70acb5 7096124: Bump the hs23 build number to 02 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 4f93f0d00802 Author: tonyp Date: 2011-09-20 09:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f93f0d00802 7059019: G1: add G1 support to the SA Summary: Extend the SA to recognize the G1CollectedHeap and implement any code that's needed by our serviceability tools (jmap, jinfo, jstack, etc.) that depend on the SA. Reviewed-by: never, poonam, johnc ! agent/make/Makefile + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegion.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java ! agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! make/sa.files ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 663cb89032b1 Author: johnc Date: 2011-09-20 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/663cb89032b1 7092412: G1: Some roots not marked during an initial mark that gets an evacuation failure Summary: As a result of the changes for 7080389, an evacuation failure during an initial mark pause may result in some root objects not being marked. Pass whether the caller is a root scanning closure into the evacuation failure handling code so that the thread that successfully forwards an object to itself also marks the object. Reviewed-by: ysr, brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp Changeset: 114e52976463 Author: tonyp Date: 2011-09-21 01:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/114e52976463 7045232: G1: pool names are inconsistent with other collectors (don't have 'Space') Summary: Make sure the eden and survivor pools have "Space" in their name. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp Changeset: 1847b501ae74 Author: johnc Date: 2011-09-21 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1847b501ae74 7068215: G1: Print reference processing time during remark Summary: Displays the elapsed time taken to perform reference processing during remark as part of the PrintGCDetails output. Reviewed-by: ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d912b598c6c3 Author: tonyp Date: 2011-09-21 13:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d912b598c6c3 7091032: G1: assert failure when NewRatio is used Summary: The desired min / max heap sizes are miscalculated at initialization when NewRatio is used. The changeset also includes an additional small change to turn a print statement into a warning. Reviewed-by: johnc, jmasa, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 5cc33133bc6d Author: johnc Date: 2011-09-21 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cc33133bc6d 7092245: G1: Wrong format specifier in G1PrintRegionLivenessInfo header output Summary: Cast HeapRegion::GrainBytes to size_t in output statement. Reviewed-by: ysr, brutisso, pbk, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: f0ecbe78fc7b Author: tonyp Date: 2011-09-22 07:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0ecbe78fc7b 7092238: G1: Uninitialized field gc_efficiency in G1PrintRegionLivenessInfo output Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 4dfb2df418f2 Author: johnc Date: 2011-09-22 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4dfb2df418f2 6484982: G1: process references during evacuation pauses Summary: G1 now uses two reference processors - one is used by concurrent marking and the other is used by STW GCs (both full and incremental evacuation pauses). In an evacuation pause, the reference processor is embedded into the closures used to scan objects. Doing so causes causes reference objects to be 'discovered' by the reference processor. At the end of the evacuation pause, these discovered reference objects are processed - preserving (and copying) referent objects (and their reachable graphs) as appropriate. Reviewed-by: ysr, jwilhelm, brutisso, stefank, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/thread.cpp Changeset: 8229bd737950 Author: tonyp Date: 2011-09-23 16:07 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8229bd737950 7075646: G1: fix inconsistencies in the monitoring data Summary: Fixed a few inconsistencies in the monitoring data, in particular when reported from jstat. Reviewed-by: jmasa, brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: e807478bf9ca Author: brutisso Date: 2011-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e807478bf9ca 7091366: re-enable quicksort tests Summary: Added extern "C" to make it build with JDK6 compilers Reviewed-by: jwilhelm, kvn ! src/share/vm/utilities/quickSort.cpp Changeset: 273b46400613 Author: johnc Date: 2011-09-28 10:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/273b46400613 7086533: G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835 Summary: Some objects may not be marked in the event of an evacuation failure in a partially young GC, during a marking cycle. Avoid this situation by not allowing partially young GCs during a marking cycle. Reviewed-by: tonyp, ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 811ec3d0833b Author: johnc Date: 2011-10-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/811ec3d0833b 7097053: G1: assert(da ? referent->is_oop() : referent->is_oop_or_null()) failed: referenceProcessor.cpp:1054 Summary: During remembered set scanning, the reference processor could discover a reference object whose referent was in the process of being copied and so may not be completely initialized. Do not perform reference discovery during remembered set scanning. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 81aa07130d30 Author: tonyp Date: 2011-10-03 19:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81aa07130d30 7097048: G1: extend the G1 SA changes to print per-heap space information Reviewed-by: brutisso, johnc ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1CollectedHeap.java + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1MonitoringSupport.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: c63b928b212b Author: stefank Date: 2011-09-12 16:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c63b928b212b 7021322: assert(object_end <= top()) failed: Object crosses promotion LAB boundary Summary: Pass the same object size value to both allocate and unallocate_object Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp Changeset: 65a8ff39a6da Author: johnc Date: 2011-10-05 08:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65a8ff39a6da 7095194: G1: HeapRegion::GrainBytes, GrainWords, and CardsPerRegion should be size_t Summary: Declare GrainBytes, GrainWords, and CardsPerRegion as size_t. Reviewed-by: jcoomes, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp Changeset: fd65bc7c09b6 Author: tonyp Date: 2011-10-06 13:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd65bc7c09b6 Merge ! agent/make/Makefile ! make/sa.files ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 246daf2c601d Author: brutisso Date: 2011-09-28 08:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/246daf2c601d 7005808: G1: re-enable ReduceInitialCardMarks for G1 Summary: Remove the extra guard to allow G1 to use ReduceInitialCardMarks Reviewed-by: jmasa, tonyp, johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: b9390528617c Author: ysr Date: 2011-10-06 18:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9390528617c 7095236: G1: _markedRegions never contains NULL regions Summary: Removed the code for skipping over NULL regions in _markedRegions, replacing it with an assertion that a NULL region is never encountered; removed dead methods, remove() and remove_region(), and inlined a simplified addRegion() directly into fillCache(). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp Changeset: f32dae5d5677 Author: ysr Date: 2011-10-10 08:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f32dae5d5677 Merge Changeset: 3f24f946bc2d Author: brutisso Date: 2011-10-11 10:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f24f946bc2d 7099454: /bin/sh does not support syntax used in the src/os/posix/launcher/launcher.script shell script Summary: Also reviewed by mikael.gerdin at oracle.com; Changed to the `` syntax instead. Also changed "source" to ".". Reviewed-by: never, stefank, dsamersoff, rottenha ! src/os/posix/launcher/launcher.script Changeset: d1bdeef3e3e2 Author: johnc Date: 2011-10-12 10:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1bdeef3e3e2 7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76 Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing. Reviewed-by: tonyp, brutisso, ysr ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: e4f412d2b75d Author: jcoomes Date: 2011-10-14 18:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4f412d2b75d Merge ! .hgtags Changeset: d815de2e85e5 Author: jcoomes Date: 2011-10-14 18:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d815de2e85e5 Added tag hs23-b02 for changeset e4f412d2b75d ! .hgtags Changeset: 3170e4044f2d Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3170e4044f2d Added tag jdk8-b10 for changeset d815de2e85e5 ! .hgtags From lana.steuck at oracle.com Wed Oct 26 19:54:40 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2011 19:54:40 +0000 Subject: hg: jdk8/tl/jdk: 29 new changesets Message-ID: <20111026195933.C1B544713F@hg.openjdk.java.net> Changeset: 19f0a3db863c Author: katleman Date: 2011-09-22 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19f0a3db863c Added tag jdk8-b06 for changeset bdb870cc269e ! .hgtags Changeset: ac9349be6821 Author: katleman Date: 2011-09-29 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac9349be6821 Added tag jdk8-b07 for changeset 19f0a3db863c ! .hgtags Changeset: b92341e9ae56 Author: bae Date: 2011-09-19 05:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b92341e9ae56 7088287: libpng need to be updated. Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h + src/share/native/sun/awt/libpng/pngdebug.h ! src/share/native/sun/awt/libpng/pngerror.c - src/share/native/sun/awt/libpng/pnggccrd.c ! src/share/native/sun/awt/libpng/pngget.c + src/share/native/sun/awt/libpng/pnginfo.h + src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngmem.c ! src/share/native/sun/awt/libpng/pngpread.c + src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c + src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtest.c ! src/share/native/sun/awt/libpng/pngtrans.c - src/share/native/sun/awt/libpng/pngvcrd.c ! src/share/native/sun/awt/libpng/pngwio.c ! src/share/native/sun/awt/libpng/pngwrite.c ! src/share/native/sun/awt/libpng/pngwtran.c ! src/share/native/sun/awt/libpng/pngwutil.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: bbf4e1faf859 Author: lana Date: 2011-09-23 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbf4e1faf859 Merge Changeset: c662c8cf25d6 Author: lana Date: 2011-09-26 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c662c8cf25d6 Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3487d0d48662 Author: rupashka Date: 2011-09-15 16:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3487d0d48662 7090007: Missing style.css in nimbus/doc-files/properties.html Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html Changeset: 16c3dcad4252 Author: rupashka Date: 2011-09-21 17:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16c3dcad4252 7032018: The file list in JFileChooser does not have an accessible name Reviewed-by: rupashka Contributed-by: Charles Lee ! 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/sun/swing/FilePane.java Changeset: 44040ece133c Author: lana Date: 2011-09-23 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44040ece133c Merge Changeset: 44f50834b79c Author: rupashka Date: 2011-09-26 17:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44f50834b79c 7088744: SwingUtilities.isMiddleMouseButton does not work with ALT/Meta keys Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7088744/bug7088744.java Changeset: d72ac458b2b7 Author: anthony Date: 2011-09-26 17:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72ac458b2b7 7081670: Disposing an AppContext can lead to a spinning EventDispatchThread Reviewed-by: art, anthony, dholmes Contributed-by: Clemens Eisserer ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 7fd192952459 Author: denis Date: 2011-09-26 18:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fd192952459 7080289: AWTKeystroke class registers a subclass factory during deserialization Reviewed-by: serb ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: aac4041609bb Author: lana Date: 2011-09-26 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aac4041609bb Merge Changeset: 1c825eac6c04 Author: lana Date: 2011-09-26 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c825eac6c04 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: f38b39ed9ed0 Author: lana Date: 2011-10-03 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f38b39ed9ed0 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 3b59f4bc8046 Author: never Date: 2011-09-07 21:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b59f4bc8046 7082631: JSR 292: need profiling support in GWTs Summary: add CountingMethodHandle Reviewed-by: twisti, jrose ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java + src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 7b9a0c75f5d9 Author: jcoomes Date: 2011-09-30 17:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b9a0c75f5d9 Merge Changeset: 1c023bcd0c5a Author: jcoomes Date: 2011-10-04 12:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c023bcd0c5a Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: f1ec21b81421 Author: katleman Date: 2011-10-06 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1ec21b81421 Added tag jdk8-b08 for changeset 1c023bcd0c5a ! .hgtags Changeset: 7539cc99befe Author: katleman Date: 2011-10-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7539cc99befe Added tag jdk8-b09 for changeset f1ec21b81421 ! .hgtags Changeset: 1be72d104f9b Author: dbuck Date: 2011-09-26 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1be72d104f9b 7029903: Splash screen is not shown in 64-bit Linux with 16-bit color depth Summary: Added Xflush() call after splash screen is updated to ensure update is no stuck in client side buffer until JVM starts up. See JET review request 4154 for details. Reviewed-by: kevinw, anthony ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: cfe25bac6951 Author: bagiras Date: 2011-09-27 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfe25bac6951 7073337: Crash after playing Java game on Pogo Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: fcdb588d77ef Author: rupashka Date: 2011-10-05 18:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fcdb588d77ef 7072167: The "root" field in BufferStrategyPaintManager leaks memory Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 98901d41e1e2 Author: rupashka Date: 2011-10-11 15:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98901d41e1e2 7076791: closed/javax/swing/JColorChooser/Test6827032.java failed on windows Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JColorChooser/Test6827032.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 58190ab77d2e Author: lana Date: 2011-10-12 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58190ab77d2e Merge Changeset: eac5d48a6c8e Author: lana Date: 2011-10-12 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eac5d48a6c8e Merge Changeset: 4788745572ef Author: lana Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4788745572ef Merge Changeset: 7ab0d613cd1a Author: katleman Date: 2011-10-20 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ab0d613cd1a Added tag jdk8-b10 for changeset 4788745572ef ! .hgtags Changeset: 291b55aa9b1e Author: lana Date: 2011-10-25 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/291b55aa9b1e Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c Changeset: 64faf533b99d Author: lana Date: 2011-10-26 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64faf533b99d Merge From xueming.shen at oracle.com Wed Oct 26 23:19:57 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 26 Oct 2011 16:19:57 -0700 Subject: performance updates to jar and zip In-Reply-To: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> Message-ID: <4EA8959D.7030202@oracle.com> Hi Mark It appears the patch you provided throws unexpected exception (attached at the end of my email) when I tried it out on the latest JDK8 repository. Since I only did a quick scan of your patch, I'm not sure what went wrong here. This patch includes lots of stuff that obviously you are trying/testing on, as you "warned" us in your email, I can see at least it tries to (1) to support different compression level 0-9 (2) parallel Zip file writing (3) with various m-thread strategy -Z (4) Files.walkFileTree instead of File.list (5) the -D :-) which I would really not recommend to do (6) small optimization in various places. which makes the code a little hard to read and the resulting data hard to compare with. I would suggest to divide this proposal to separate pieces and work on them one by one, for example maybe we can try to solve the main puzzle (2) + (3) first, and then the other optimization opportunities. To collect some data, I followed your lead to write a simple MT support implementation in Jar Main class as showed at http://cr.openjdk.java.net/~sherman/mtjar2/webrev2/ which I guess is similar to what your are doing. It uses a "simple" strategy (1) A dedicated thread (from the ExecutorService thread pool) to iterate the file system tree to "collect" the target files, submit a "compression job" for each of these files to the ExecutorService and keep the returned "Future" (from the submission) in a queue "elist". (2) Threads from ExecutorService to use temporary buffer memory to read and compress the the file in memory . (3) The main thread is polling the queue "elist", waiting for the "compression job" to cmplete and write the result into the target ZipOutputStream. The resulting data looks promising, I'm seeing the jar-ing speed doubled when jar-ing the rt.jar and a jdk7 binary tree, on a "slow" but 4-core linux vm machine (I have the similar result on a 2-hcore linux as well) java Jar cf jdk.jar jdk1.7.0 Jar TotalTime:17278 java Jar cfT1 jdk.jar jdk1.7.0 Jar TotalTime:12345 java Jar cfT2 jdk.jar jdk1.7.0 Jar TotalTime:7559 java Jar cfT3 jdk.jar jdk1.7.0 Jar TotalTime:7572 java Jar cfT4 jdk.jar jdk1.7.0 Jar TotalTime:7801 java Jar cfT5 jdk.jar jdk1.7.0 Jar TotalTime:8112 The new "T" option for "n-thread", the digit number followed is to specify the fixed thread number for the executor service's thread pool. It appears that we can achieve the "best" result with only 3 threads in this configuration. One thread for scanning the file system, one thread for the compression and the main thread for the writing out. My guess is that the fact we have to "write out" to a single file (the resulting jar) limits the potential benefit of having more "compressing" threads. I also tried to measure the "file scanning" speed in my mini-benchmark FIter http://cr.openjdk.java.net/~sherman/mtjar2/FIter.java Here are the "surprising" results. "nio" is the walkFileTree, "io" is the File.list() "io2" is the File.listFiles(). The nio's File.walkFileTree is 15 times faster than the "traditional" recursion+File.list(). wow! Linux-------------------------------------------------------------------------- sherman at sherman-linux:~/Workspace/test$ java FIter ../jdk8_mtJar/src java.io.File iteration ------------------ nio.totalSize:137149279 fileNum:12222 checkSum:16122691809689000 Time:85 ------------------ io.totalSize:137149279 fileNum:12222 checkSum:16122691809689000 Time:269 ------------------ io2.totalSize:137149279 fileNum:12222 checkSum:16122691809689000 Time:450 Windows7--------------------------------------------------------------------------------- $ /cygdrive/c/Program\ Files\ \(x86\)/Java/jdk1.7.0/bin/java FIter ../sqa/jdk8/src java.io.File iteration ------------------ nio.totalSize:136695871 fileNum:12199 checkSum:15997350823839479 Time:323 ------------------ io.totalSize:136695871 fileNum:12199 checkSum:15997350823839479 Time:2633 ------------------ io2.totalSize:136695871 fileNum:12199 checkSum:15997350823839479 Time:4592 ---------------------------------------------------------------------- sherman at sherman-linux:~/Workspace/test$ ../jdk8_mtJar/build/linux-i586/bin/jar cf6DZ3 rt0.jar rtjar duplicate path java.util.zip.ZipException: duplicate entry: ../ at java.util.zip.AbstractZipWriter.writeHeader(AbstractZipWriter.java:647) at java.util.zip.AbstractZipWriter.startWritingStored(AbstractZipWriter.java:384) at java.util.zip.AbstractZipWriter.writeWithResource(AbstractZipWriter.java:350) at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:273) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) java.util.concurrent.ExecutionException: java.util.zip.ZipException: duplicate entry: ../ at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at sun.tools.jar.Main.waitFor(Main.java:810) at sun.tools.jar.Main.run(Main.java:679) at sun.tools.jar.Main.main(Main.java:1842) Caused by: java.util.zip.ZipException: duplicate entry: ../ -Sherman On 10/20/2011 3:55 PM, Mike Skells wrote: > Hi All, > I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util) > > This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in > Currently it is a testbed for comparing different techniques, but largely based on the Jar utility > > The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths > > This comparative figures do not include the effect of the nio changes that I proposed in earlier emails > > Command line changes > 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression > D This allows the files to all be written with the date of now, lather than the file date (the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) > Z0-5 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier > > The test environment is a 4 core Intel core2 pc running windows vista 64, the test case is jaring up the content of rt.jar to a jar file. > Each test is repeated 6 times and the last 5 are averaged to produce the answers. Each test is run in a fresh VM > > The performance figures are below as a CSV. The last column is the duration of the task in ms. > > In summary the existing jar utility takes (for uncompressed, compressed) 8.4 , 9.4 seconds to complete and this can be reduced to 1.6, 2.3 seconds > > The different parallel algorithms are > 0 - none all in one thread as before > 1 - file scanning in one core, 10 threads loading and buffering files, zip writing in a single thread using the existing ZipOuputStream > 2. - file scanning in one core, 10 threads loading and buffering files, zip writing mostly mutithreaded (e.g. parallel compression, single write to the output stream) > 3 - as 2 but writes to a file rather than a stream > 4. as 2 but uses channels to be to write with direct buffers > 5 as 4 but using heap buffers > > 3-5 have the zip capability in the code to seek and update headers that are incomplete, but this is not much tested > > > > > C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 > C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, project 1.7 rt -cf0, 3133 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, project 1.7 rt -cf0D, 2824 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, project 1.7 rt -cf0 parallel 0, 3026 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, project 1.7 rt -cf0D parallel 0, 2961 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, project 1.7 rt -cf0D parallel 1, 2022 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, project 1.7 rt -cf0D parallel 2, 1757 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, project 1.7 rt -cf0D parallel 3, 1632 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, project 1.7 rt -cf0D parallel 4, 1994 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, project 1.7 rt -cf0D parallel 5, 1978 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, project 1.7 rt -cf1, 5237 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, project 1.7 rt -cf1D, 5073 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, project 1.7 rt -cf1 parallel 0, 5367 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, project 1.7 rt -cf1D parallel 0, 5002 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, project 1.7 rt -cf1D parallel 1, 5125 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, project 1.7 rt -cf1D parallel 2, 2257 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, project 1.7 rt -cf1D parallel 3, 2145 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, project 1.7 rt -cf1D parallel 4, 2505 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, project 1.7 rt -cf1D parallel 5, 2549 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, project 1.7 rt -cf2, 5371 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, project 1.7 rt -cf3, 5409 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, project 1.7 rt -cf4, 5778 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, project 1.7 rt -cf5, 5906 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, project 1.7 rt -cf6, 6082 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, project 1.7 rt -cf7, 6070 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, project 1.7 rt -cf8, 6251 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, project 1.7 rt -cf9, 6191 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, project 1.7 rt -cf6D, 5843 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, project 1.7 rt -cf6 parallel 0, 6095 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, project 1.7 rt -cf6D parallel 0, 5907 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, project 1.7 rt -cf6D parallel 1, 5957 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, project 1.7 rt -cf6D parallel 2, 2388 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, project 1.7 rt -cf6D parallel 3, 2351 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, project 1.7 rt -cf6D parallel 4, 2694 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, project 1.7 rt -cf6D parallel 5, 2830 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, project 1.7 rt -cf9D, 6134 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, project 1.7 rt -cf9 parallel 0, 6258 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, project 1.7 rt -cf9D parallel 0, 6066 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, project 1.7 rt -cf9D parallel 1, 6203 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, project 1.7 rt -cf9D parallel 2, 2490 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, project 1.7 rt -cf9D parallel 3, 2361 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, project 1.7 rt -cf9D parallel 4, 2788 > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, project 1.7 rt -cf9D parallel 5, 2847 > > regards > Mike From weijun.wang at oracle.com Thu Oct 27 09:24:28 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 27 Oct 2011 09:24:28 +0000 Subject: hg: jdk8/tl/jdk: 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Message-ID: <20111027092454.1A76D47164@hg.openjdk.java.net> Changeset: 449113aea001 Author: weijun Date: 2011-10-27 17:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/449113aea001 7104161: test/sun/tools/jinfo/Basic.sh fails on Ubuntu Reviewed-by: alanb ! test/sun/tools/jinfo/Basic.sh From sean.coffey at oracle.com Thu Oct 27 09:31:50 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 27 Oct 2011 09:31:50 +0000 Subject: hg: jdk8/tl/jdk: 7099658: Properties.loadFromXML fails with ClassCastException Message-ID: <20111027093201.0187E47165@hg.openjdk.java.net> Changeset: 64ccf18bbad5 Author: coffeys Date: 2011-10-27 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64ccf18bbad5 7099658: Properties.loadFromXML fails with ClassCastException Reviewed-by: alanb, mchung ! src/share/classes/sun/util/xml/XMLUtils.java From neil.richards at ngmr.net Thu Oct 27 10:57:20 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 27 Oct 2011 11:57:20 +0100 Subject: jcheck conflict in jdk8/tl/jdk and awt repos: same CR # 7100054 used in two different changesets (one in tl, the other in awt forest) In-Reply-To: <4EA690BF.4000605@oracle.com> References: <4EA60104.1090008@oracle.com> <4EA690BF.4000605@oracle.com> Message-ID: <1319713040.14435.7.camel@chalkhill> On Tue, 2011-10-25 at 11:34 +0100, Alan Bateman wrote: > On 25/10/2011 01:21, Lana Steuck wrote: > > To: TL and Awt teams > > What: we have a jcheck conflict in jdk8/tl/jdk and jdk8/awt/jdk > > repos: > > same Bugid # 7100054 used in two different changesets (one in > > tl/jdk, the other in awt/jdk repo) > > > > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f218e6bdf1e8 > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3da0672a882 > > > > neil.richards at ngmr.net > > 7100054: (porting) Native code should include fcntl.h and unistd.h > > rather than sys/fcntl.h and sys/unistd.h > > Summary: Use POSIX defined includes for unistd.h and fcntl.h > I think I may be partly to blame here. Neil did ask whether he needed > a separate CR for the AWT change and I told him ([1]) that one was > sufficient. I didn't realize he was thinking of splitting the changes > though as there wasn't any real need to do this for this. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007926.html > I'm sorry for the confusion here. The review of the AWT part of the change went down a different path (onto a different mailing list) to the core-libs part, and as AWT has its own component repository, it seemed to make most sense to me to commit the core-libs bit to the core-libs component repo, and the AWT bit to the AWT repo. Hence why I asked about whether I needed one bug id or two. I obviously didn't make the correct inference from Alan's reply (that I should commit all the change into one repo). I'm sorry this caused a problem. Please let me know what I can do in helping to rectify things. Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Thu Oct 27 13:07:00 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Oct 2011 14:07:00 +0100 Subject: performance updates to jar and zip In-Reply-To: <4EA8959D.7030202@oracle.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> Message-ID: <4EA95774.9010203@oracle.com> On 27/10/2011 00:19, Xueming Shen wrote: > : > > Here are the "surprising" results. > > "nio" is the walkFileTree, > "io" is the File.list() > "io2" is the File.listFiles(). > > The nio's File.walkFileTree is 15 times faster than the "traditional" > recursion+File.list(). > wow! > At least for your testing on Linux then if you run with strace then it should become clear. The ioIter and ioIter2 methods in the test result in each file being stat'ed 3 times whereas with walkFileTree it is using Files.readAttributes to attributes in bulk (so one stat per file). In any case, this is all good work. One suggestion is to consider not introducing a -T or whatever option but instead default to using a pipeline that has the right number of threads to work very fast in most cases. I'm just thinking of jar tasks in ANT or shell scripts where you wouldn't want to hard code a thread count. -Alan. From sebastian.sickelmann at gmx.de Thu Oct 27 14:50:28 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 27 Oct 2011 16:50:28 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E88C03A.90904@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> <4E88C03A.90904@gmx.de> Message-ID: <4EA96FB4.7000502@gmx.de> Some time ago (see below) i ask what would be the right solution to refactor exception initialization to? Solution 1: Disallow calls to initCause after creation, if there was an exception-cause-functionality in this class before it was introduced to Throwable. Solution 2: Disallow calls to initCause after creation with in ctor which has a cause parameter. Solution 3: Disallow calls to initCause after creation, if and only if there are ctors that allows us to specify the cause at creation time. If i investigated it right:: * Solution 1 is used by in the Exceptions in core-libs. * Exceptions that had no cause-chain prior to Throwable's-cause-chain uses Solution 2. * Personally i found Solution 3 is the most intuitive for the users javax/xml/security- Exceptions had cause-chaining prio to Throwable introduces them. jx/x/s-Exceptions are actually not refactored to solution 2 like the other exceptions in core-libs that had cause-chaining prior to Throwable. Before my change-request for jx/x/s-Exceptions i changed some in core-libs (InternalError and VirtualMachineError) to provide exception-chaining. These use Solution 2 like all other exceptions that provided exception-chaining after it where introduced by Throwable. My personal view of this is that i think it may be valueable to change all to Solution 3 or at least merge all Solutions to one Solution(maybe Solution 2) and get rid of Solution 1. I created a webrev[0] for jx/x/s-Exceptions that implements Solution 2 (this can be used for all those Exceptions that used Solution 1 too). And I created a webrev[1] for jx/x/s-Exceptions that implement Solution 3 for comparision. [0] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html [1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.htm The problem with Solution 3 is that bahavoir compatibility is not given and some code may break. -- Sebastian Am 02.10.2011 21:49, schrieb Sebastian Sickelmann: > Am 01.10.2011 18:19, schrieb Sean Mullan: >> On 9/30/11 2:15 PM, Sebastian Sickelmann wrote: >>>>> I think I know the reason. If you allow initCause to be called when a >>>>> cause is >>>>> not initially provided, then getCause will still return null, which >>>>> seems wrong. >>>>> >>>> getCause() of Throwable and all classes that doesn't had a chaining >>>> before >>>> Throwable introduces it, doing this excact this way. Whats wrong on >>>> this? >>>> >>>> return (cause==this ? null : cause); // Where the initial >>>> value(uninitialied) of cause is this. >>> Does this make sense? I actually not sure i understand you right. >> The following code: >> >> KeySelectorException kse = new KeySelectorException("foo"); >> kse.initCause(new Exception("bar")); >> System.out.println(kse.getCause()); >> >> prints null as the cause, even though initCause was subsequently >> called. Do you >> see my concern? > This is one of the places in code which must be changes to match the > initCause behavoir of Throwable. > > I have done it here: > > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html > > > But is this the best way? Or should we just follow the other > Exceptions and start an seperate discussion on this with core-libs-dev? > >>> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html >>> >> Thanks! >> --Sean >> > From sean.mullan at oracle.com Thu Oct 27 15:17:37 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 27 Oct 2011 15:17:37 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111027151832.25C2A4716A@hg.openjdk.java.net> Changeset: 56cc907fc8dc Author: mullan Date: 2011-10-27 10:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56cc907fc8dc 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 8cd2e3b8127a Author: mullan Date: 2011-10-27 11:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cd2e3b8127a Merge - make/sun/rmi/rmi/mapfile-vers - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c From xueming.shen at oracle.com Thu Oct 27 16:37:45 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 27 Oct 2011 09:37:45 -0700 Subject: performance updates to jar and zip In-Reply-To: <4EA95774.9010203@oracle.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> <4EA95774.9010203@oracle.com> Message-ID: <4EA988D9.4000703@oracle.com> On 10/27/2011 06:07 AM, Alan Bateman wrote: > On 27/10/2011 00:19, Xueming Shen wrote: >> : >> >> Here are the "surprising" results. >> >> "nio" is the walkFileTree, >> "io" is the File.list() >> "io2" is the File.listFiles(). >> >> The nio's File.walkFileTree is 15 times faster than the "traditional" >> recursion+File.list(). >> wow! >> > At least for your testing on Linux then if you run with strace then it > should become clear. The ioIter and ioIter2 methods in the test result > in each file being stat'ed 3 times whereas with walkFileTree it is > using Files.readAttributes to attributes in bulk (so one stat per file). > > In any case, this is all good work. One suggestion is to consider not > introducing a -T or whatever option but instead default to using a > pipeline that has the right number of threads to work very fast in > most cases. I'm just thinking of jar tasks in ANT or shell scripts > where you wouldn't want to hard code a thread count. > -T is simply here to help measure the performance under different thread number. Agreed that this thing should work by default. -Sherman From mike.skells at talk21.com Thu Oct 27 23:07:50 2011 From: mike.skells at talk21.com (Mike Skells) Date: Fri, 28 Oct 2011 00:07:50 +0100 (BST) Subject: performance updates to jar and zip In-Reply-To: <4EA8959D.7030202@oracle.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> Message-ID: <1319756870.73164.YahooMailNeo@web86601.mail.ird.yahoo.com> Hi Sherman, I think that you will get significant benefit from generating the data structures in the background threads. I think that is you profile the usageyou will see that the generation of the header information is the dominant feature.? That is why I parallelised the writing process.? There are several bottlenecks such as the encoding of the name name and (although you dismiss it) the calculation of the dos time format is a CPU hog (the -D qualifier). I hink that it is about 10% of the overall CPU load This is by the way pretty much in line with the extraction feature below added in java 6, so I cant see that there is a great reason against it,? after all why spend time storing information that (in most use cases) is not read (either because the jar utility does not by default maintain it, and most jar files are? probably not expanded anyway /** ? ? ?* If true, maintain compatibility with JDK releases prior to 6.0 by ? ? ?* timestamping extracted files with the time at which they are extracted. ? ? ?* Default is to use the time given in the archive. ? ? ?*/ ? ? private static final boolean useExtractionTime = ? ? ? ? ? ? Boolean.getBoolean("sun.tools.jar.useExtractionTime");? Here are the times that I get running the code that you wrote on my setup C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf, cf, 10279 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT1, cfT1, 9652 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT2, cfT2, 6139 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT3, cfT3, 5683 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT4, cfT4, 6102 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT5, cfT5, 6172 I think that the reason that it tails off in performance is rather that you are overloading the system with the background threads. You have many threads (ie > cores) loading the files, and they are contending for the CPU and the writer thread is not getting its share of time, so with 3 threads + the initail file scanning and the writer thread there are more threads that can be services If you introduce an ArrayBlockingQueue for both of the scanning -> compression and the compression->writing? and also get run of the cpu bound ( until the scanner gets going) polling like ?while(true) { ? ? ? Object o = elist.poll(); ? ? ? if (o == null) ? ? ? ? ? ? continue; I dont think that you have the seperation of the loading and storing sorted out. The code adds the future to elist, and the worker thread reads it whether or not it has completed,? so some times the loading is done on the background thread before the main thread reads it, and sometimes it blocks, even when other jobs have completed, so I think that a completion queue? works better for this. It will complicate the END processing though If I am reading the code correctly I think that there are potential memory issues. There are an unlimitted number of jobs submitted to an executor, which while it only executes T jobs, the jobs may still queue up in elist, and each job can buffer 50Mb of data. If the writing of the output is too slow you could run out of memory Line 666 and 672 (both return statements ) I think should be continue; With T1 there is no effective pipelining as I see it. The scannign thread has to complete before the loading thread can start (as there is only 1 CPU). So withthe blocking thread model we have to start at 2 threads as otherwise it may deadlock itself with a blocking queue (and minor changes caused or implied by a blocking queue) C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf, cf, 10274 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT2, cfT2, 7201 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT3, cfT3, 5836 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT4, cfT4, 5884 C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT5, cfT5, 5890 I tried to repoduce the exception that you have, but I cant I donw have a java8 install on this machine, or unix. It does seem very strange that there is a file being written as "../" in the first place though ( let alone a duplicate) I didnt think that any of the API would return ../ Is it only on Z3 that this error occurs? I will install a Java8 with the patch, but it will be at the start of next week regards Mike >________________________________ >From: Xueming Shen >To: core-libs-dev at openjdk.java.net >Sent: Thursday, 27 October 2011, 0:19 >Subject: Re: performance updates to jar and zip > >Hi Mark > >It appears the patch you provided throws unexpected exception (attached at the end of my >email)? when I tried it out on the? latest JDK8 repository.? Since I only did a quick scan of your >patch, I'm not sure what went wrong here. > >This patch includes lots of stuff that obviously you are trying/testing on, as you "warned" us in >your email, I can see at least it tries to > >(1) to support different compression level 0-9 >(2) parallel Zip file writing >(3) with various m-thread strategy -Z >(4) Files.walkFileTree instead of File.list >(5) the -D :-) which I would really not recommend to do >(6) small optimization in various places. > >which makes the code a little hard to read and the resulting data hard to compare with. >I would suggest to divide this proposal to separate pieces and work on them one by one, >for example maybe we can try to solve the main puzzle (2) + (3) first, and then the other >optimization opportunities. > >To collect some data, I followed your lead to write a simple MT support implementation >in Jar Main class as showed at > >http://cr.openjdk.java.net/~sherman/mtjar2/webrev2/ > >which I guess is similar to what your are doing. It uses a "simple" strategy > >(1) A dedicated thread (from the ExecutorService thread pool) to iterate the file system >? ? tree to "collect" the target files,? submit a "compression? job" for? each of these files >? ? to the ExecutorService and keep the returned "Future" (from the submission) in a >? ? queue "elist". >(2) Threads from ExecutorService to use temporary buffer memory to read and compress >? ? ? the the file in memory . >(3) The main thread is polling the queue "elist", waiting for the "compression job" to >? ? cmplete and? write the result into the target ZipOutputStream. > >The resulting data looks promising, I'm seeing the jar-ing speed doubled when jar-ing >the rt.jar and a jdk7 binary tree, on a "slow" but 4-core linux vm machine (I have the >similar result on a 2-hcore linux as well) > >java Jar cf jdk.jar jdk1.7.0? ? ? ? Jar TotalTime:17278 >java Jar cfT1 jdk.jar jdk1.7.0? Jar TotalTime:12345 >java Jar cfT2 jdk.jar jdk1.7.0? Jar TotalTime:7559 >java Jar cfT3 jdk.jar jdk1.7.0? Jar TotalTime:7572 >java Jar cfT4 jdk.jar jdk1.7.0? Jar TotalTime:7801 >java Jar cfT5 jdk.jar jdk1.7.0? Jar TotalTime:8112 > >The new "T" option for "n-thread", the digit number followed is to specify the >fixed thread number for the executor service's thread pool.? It appears that we can >achieve the "best" result with only 3 threads in this configuration. One thread for >scanning the file system, one thread for the compression and the main thread for >the writing out. My guess is that the fact we have to "write out" to a single file >(the resulting jar) limits the potential benefit of having more "compressing" threads. > >I also tried to measure the "file scanning" speed in my mini-benchmark FIter > >http://cr.openjdk.java.net/~sherman/mtjar2/FIter.java > >Here are the "surprising" results. > >"nio" is the walkFileTree, >"io" is the File.list() >"io2" is the File.listFiles(). > >The nio's File.walkFileTree is 15 times faster than the "traditional" recursion+File.list(). >wow! > >Linux-------------------------------------------------------------------------- >sherman at sherman-linux:~/Workspace/test$ java FIter ../jdk8_mtJar/src >java.io.File iteration >------------------ >? nio.totalSize:137149279 >? ? ? ? fileNum:12222 >? ? ? checkSum:16122691809689000 >? ? ? ? ? Time:85 >------------------ >? io.totalSize:137149279 >? ? ? ? fileNum:12222 >? ? ? checkSum:16122691809689000 >? ? ? ? ? Time:269 >------------------ >io2.totalSize:137149279 >? ? ? ? fileNum:12222 >? ? ? checkSum:16122691809689000 >? ? ? ? ? Time:450 > >Windows7--------------------------------------------------------------------------------- > >$ /cygdrive/c/Program\ Files\ \(x86\)/Java/jdk1.7.0/bin/java FIter ../sqa/jdk8/src >java.io.File iteration >------------------ >? nio.totalSize:136695871 >? ? ? ? fileNum:12199 >? ? ? checkSum:15997350823839479 >? ? ? ? ? Time:323 >------------------ >? io.totalSize:136695871 >? ? ? ? fileNum:12199 >? ? ? checkSum:15997350823839479 >? ? ? ? ? Time:2633 >------------------ >io2.totalSize:136695871 >? ? ? ? fileNum:12199 >? ? ? checkSum:15997350823839479 >? ? ? ? ? Time:4592 > > >---------------------------------------------------------------------- > >sherman at sherman-linux:~/Workspace/test$ ../jdk8_mtJar/build/linux-i586/bin/jar cf6DZ3 rt0.jar rtjar >duplicate path >java.util.zip.ZipException: duplicate entry: ../ >? ? at java.util.zip.AbstractZipWriter.writeHeader(AbstractZipWriter.java:647) >? ? at java.util.zip.AbstractZipWriter.startWritingStored(AbstractZipWriter.java:384) >? ? at java.util.zip.AbstractZipWriter.writeWithResource(AbstractZipWriter.java:350) >? ? at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:273) >? ? at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) >? ? at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) >? ? at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >? ? at java.util.concurrent.FutureTask.run(FutureTask.java:166) >? ? at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >? ? at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >? ? at java.util.concurrent.FutureTask.run(FutureTask.java:166) >? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >? ? at java.lang.Thread.run(Thread.java:722) >java.util.concurrent.ExecutionException: java.util.zip.ZipException: duplicate entry: ../ >? ? at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) >? ? at java.util.concurrent.FutureTask.get(FutureTask.java:111) >? ? at sun.tools.jar.Main.waitFor(Main.java:810) >? ? at sun.tools.jar.Main.run(Main.java:679) >? ? at sun.tools.jar.Main.main(Main.java:1842) >Caused by: java.util.zip.ZipException: duplicate entry: ../ > >-Sherman > >On 10/20/2011 3:55 PM, Mike Skells wrote: >> Hi All, >> I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util) >> This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in >> Currently it is a testbed for comparing different techniques, but largely based on the Jar utility >> >> The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths >> >> This comparative figures do not include the effect of the nio changes that I proposed in earlier emails >> >> Command line changes >> 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression >> D This allows the files to all be written with the date of now, lather than the file date? (the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) >> Z0-5 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier >> >> The test environment is a 4 core Intel core2 pc running windows? vista 64, the test case is jaring up the content of rt.jar to a jar file. Each test is repeated 6 times and the last 5 are averaged to produce the answers. Each test is run in a fresh VM >> >> The performance figures are below as a CSV. The last column is the duration of the task in ms. >> >> In summary the existing jar utility takes (for uncompressed, compressed) 8.4 , 9.4 seconds to complete and this can be reduced to 1.6, 2.3 seconds? >> The different parallel algorithms are 0 - none all in one thread as before >> 1 - file scanning in one core, 10 threads loading and buffering files, zip writing in a single thread using the existing ZipOuputStream >> 2. - file scanning in one core, 10 threads loading and buffering files, zip writing mostly mutithreaded (e.g. parallel compression, single write to the output stream) >> 3 - as 2 but writes to a file rather than a stream >> 4. as 2 but uses channels to be to write with direct buffers >> 5 as 4 but using heap buffers >> >> 3-5 have the zip capability in the code to seek and update headers that are incomplete, but this is not much tested >>? >> >> >> C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 >> C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, project 1.7 rt -cf0, 3133 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, project 1.7 rt -cf0D, 2824 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, project 1.7 rt -cf0 parallel 0, 3026 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, project 1.7 rt -cf0D parallel 0, 2961 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, project 1.7 rt -cf0D parallel 1, 2022 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, project 1.7 rt -cf0D parallel 2, 1757 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, project 1.7 rt -cf0D parallel 3, 1632 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, project 1.7 rt -cf0D parallel 4, 1994 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, project 1.7 rt -cf0D parallel 5, 1978 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, project 1.7 rt -cf1, 5237 >> >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, project 1.7 rt -cf1D, 5073 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, project 1.7 rt -cf1 parallel 0, 5367 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, project 1.7 rt -cf1D parallel 0, 5002 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, project 1.7 rt -cf1D parallel 1, 5125 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, project 1.7 rt -cf1D parallel 2, 2257 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, project 1.7 rt -cf1D parallel 3, 2145 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, project 1.7 rt -cf1D parallel 4, 2505 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, project 1.7 rt -cf1D parallel 5, 2549 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, project 1.7 rt -cf2, 5371 >> >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, project 1.7 rt -cf3, 5409 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, project 1.7 rt -cf4, 5778 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, project 1.7 rt -cf5, 5906 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, project 1.7 rt -cf6, 6082 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, project 1.7 rt -cf7, 6070 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, project 1.7 rt -cf8, 6251 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, project 1.7 rt -cf9, 6191 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, project 1.7 rt -cf6D, 5843 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, project 1.7 rt -cf6 parallel 0, 6095 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, project 1.7 rt -cf6D parallel 0, 5907 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, project 1.7 rt -cf6D parallel 1, 5957 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, project 1.7 rt -cf6D parallel 2, 2388 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, project 1.7 rt -cf6D parallel 3, 2351 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, project 1.7 rt -cf6D parallel 4, 2694 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, project 1.7 rt -cf6D parallel 5, 2830 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, project 1.7 rt -cf9D, 6134 >> >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, project 1.7 rt -cf9 parallel 0, 6258 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, project 1.7 rt -cf9D parallel 0, 6066 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, project 1.7 rt -cf9D parallel 1, 6203 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, project 1.7 rt -cf9D parallel 2, 2490 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, project 1.7 rt -cf9D parallel 3, 2361 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, project 1.7 rt -cf9D parallel 4, 2788 >> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, project 1.7 rt -cf9D parallel 5, 2847 >> >> regards >> Mike > > > From xuelei.fan at oracle.com Fri Oct 28 14:20:32 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 28 Oct 2011 14:20:32 +0000 Subject: hg: jdk8/tl/jdk: 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Message-ID: <20111028142059.6EA9B471B2@hg.openjdk.java.net> Changeset: 6e59c482e9b8 Author: xuelei Date: 2011-10-28 07:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e59c482e9b8 7105940: Test regression: KeyStore must be from provider SunPKCS11-NSSKeyStore Reviewed-by: weijun ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java From Alan.Bateman at oracle.com Fri Oct 28 16:14:53 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Oct 2011 17:14:53 +0100 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E83730A.8060106@oracle.com> References: <4E83730A.8060106@oracle.com> Message-ID: <4EAAD4FD.3060302@oracle.com> On 28/09/2011 20:18, Xueming Shen wrote: > Hi, > > [I combined the proposed charge for #7082884, in which no one appears > to be > interested:-) into this one] > : > > http://cr.openjdk.java.net/~sherman/7096080/webrev/ > I don't know if you are still looking for a reviewer for this (seems like Ulf has gone through this in detail, thanks Ulf). Overall it looks fine to me. Minor comment is that in UTF_8.java then maybe isMalformed2 should be removed completely, maybe move some of the comment in the decode methods. Another minor nits is that the date on CESU_8.java is 2000-2010 where I assume it should be 2011. In Errors.java then it might be better to just remove L196 as it might confuse future maintainers. I would also suggest adding the bugID to the list of bugs in the tests too as someone these references are useful. -Alan. From sonali.goel at oracle.com Fri Oct 28 16:15:23 2011 From: sonali.goel at oracle.com (sonali.goel at oracle.com) Date: Fri, 28 Oct 2011 09:15:23 -0700 (PDT) Subject: Auto Reply: core-libs-dev Digest, Vol 54, Issue 42 Message-ID: <4887cfaf-c239-4215-bfba-3cf1a2f61623@default> This is an auto-reply. I am out of office and will reply to emails when I get back on 11/01. For urgent matters, please contact Vita.Santrucek at oracle.com From mark.reinhold at oracle.com Fri Oct 28 16:15:31 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 28 Oct 2011 09:15:31 -0700 Subject: JEP 111: Additional Unicode Constructs for Regular Expressions Message-ID: <20111028161531.3466D2D79@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/111 - Mark From mark.reinhold at oracle.com Fri Oct 28 16:46:31 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 28 Oct 2011 09:46:31 -0700 Subject: JEP 112: Charset Implementation Improvements Message-ID: <20111028164631.5D6422D79@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/112 - Mark From sean.coffey at oracle.com Fri Oct 28 18:13:24 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 28 Oct 2011 19:13:24 +0100 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Message-ID: <4EAAF0C4.5070806@oracle.com> This is a second stab at cleaning up the close() and finalize() methods for FileInputStream / FileOutputStream / RandomAccessFile classes so that all parents/referents sharing the same native FileDescriptor are closed out correctly. With Alan's assistance, we have a better implementation in place where we avoid the use of counters and instead cycle through a list of shared closeables when a FileDescriptor is being shared. Bug report (not visible yet) http://bugs.sun.com/view_bug.do?bug_id=7105952 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/ regards, Sean. From Ulf.Zibis at gmx.de Fri Oct 28 21:28:38 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 28 Oct 2011 23:28:38 +0200 Subject: JEP 112: Charset Implementation Improvements In-Reply-To: <20111028164631.5D6422D79@eggemoggin.niobe.net> References: <20111028164631.5D6422D79@eggemoggin.niobe.net> Message-ID: <4EAB1E86.6050501@gmx.de> Great! I like to be part of it. -Ulf Am 28.10.2011 18:46, schrieb mark.reinhold at oracle.com: > Posted: http://openjdk.java.net/jeps/112 > > - Mark > From darryl.mocek at oracle.com Fri Oct 28 22:44:25 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 28 Oct 2011 15:44:25 -0700 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) Message-ID: <4EAB3049.8040409@oracle.com> Hello. Please review this patch to add empty sorted set to the Collections class. Test case provided. Webrev: http://cr.openjdk.java.net/~mduigou/4533691/1/webrev/ Additional Notes to Reviewers: The sets resulting from tailSet() headSet() and subSet() normally include the range which was used to create them. Using these methods with emptySortedSet() does not currently set a range on the resulting sets. Thanks, Darryl From brucechapman at paradise.net.nz Sat Oct 29 08:26:59 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Sat, 29 Oct 2011 21:26:59 +1300 Subject: JEP 111: Additional Unicode Constructs for Regular Expressions In-Reply-To: <20111028161531.3466D2D79@eggemoggin.niobe.net> References: <20111028161531.3466D2D79@eggemoggin.niobe.net> Message-ID: <4EABB8D3.3050209@paradise.net.nz> Sherman, there are a couple of typos in that JEP. "from from" and "regression expression" Bruce On 29/10/2011 5:15 a.m., mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/111 > > - Mark > From sebastian.sickelmann at gmx.de Sat Oct 29 11:17:41 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 29 Oct 2011 13:17:41 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4EA96FB4.7000502@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> <4E88C03A.90904@gmx.de> <4EA96FB4.7000502@gmx.de> Message-ID: <4EABE0D5.5050802@gmx.de> Sorry i linked the wrong webrev for Solution 3. Am 27.10.2011 16:50, schrieb Sebastian Sickelmann: > Some time ago (see below) i ask what would be the right solution to > refactor > exception initialization to? > > Solution 1: Disallow calls to initCause after creation, if there was an > exception-cause-functionality in this class before it was introduced > to Throwable. > Solution 2: Disallow calls to initCause after creation with in ctor > which has a cause parameter. > Solution 3: Disallow calls to initCause after creation, if and only if > there are ctors > that allows us to specify the cause at creation time. > > > If i investigated it right:: > * Solution 1 is used by in the Exceptions in core-libs. > * Exceptions that had no cause-chain prior to > Throwable's-cause-chain uses Solution 2. > * Personally i found Solution 3 is the most intuitive for the users > > javax/xml/security- Exceptions had cause-chaining prio to Throwable > introduces them. jx/x/s-Exceptions are actually not refactored to > solution 2 like the other exceptions in core-libs that had > cause-chaining prior to Throwable. > > Before my change-request for jx/x/s-Exceptions i changed some in > core-libs (InternalError and VirtualMachineError) to provide > exception-chaining. These use Solution 2 like all other exceptions > that provided exception-chaining after it where introduced by Throwable. > > My personal view of this is that i think it may be valueable to change > all to Solution 3 or at least merge all Solutions to one > Solution(maybe Solution 2) and get rid of Solution 1. > I created a webrev[0] for jx/x/s-Exceptions that implements Solution 2 > (this can be used for all those Exceptions that used Solution 1 too). > And I created a webrev[1] for jx/x/s-Exceptions that implement > Solution 3 for comparision. > > [0] > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html > [1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html From jason_mehrens at hotmail.com Sat Oct 29 16:03:52 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sat, 29 Oct 2011 11:03:52 -0500 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EAB3049.8040409@oracle.com> References: <4EAB3049.8040409@oracle.com> Message-ID: Darryl, I would get rid of the public static field so this class can be lazy loaded like EmptyIterator and ReverseComparator (in 1.7). What about accepting a comparator as an argument? I bet the bug report is predates 1.6, so maybe you should target NavigableSet instead of sorted set. Regards, Jason > Date: Fri, 28 Oct 2011 15:44:25 -0700 > From: darryl.mocek at oracle.com > To: core-libs-dev at openjdk.java.net > Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) > > Hello. Please review this patch to add empty sorted set to the > Collections class. Test case provided. > > Webrev: http://cr.openjdk.java.net/~mduigou/4533691/1/webrev/ > > Additional Notes to Reviewers: > The sets resulting from tailSet() headSet() and subSet() normally > include the range which was used to create them. Using these methods > with emptySortedSet() does not currently set a range on the resulting sets. > > Thanks, > Darryl From Alan.Bateman at oracle.com Sun Oct 30 14:07:47 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 30 Oct 2011 14:07:47 +0000 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EAB3049.8040409@oracle.com> References: <4EAB3049.8040409@oracle.com> Message-ID: <4EAD5A33.1090305@oracle.com> On 28/10/2011 23:44, Darryl Mocek wrote: > Hello. Please review this patch to add empty sorted set to the > Collections class. Test case provided. > > Webrev: http://cr.openjdk.java.net/~mduigou/4533691/1/webrev/ > > Additional Notes to Reviewers: > The sets resulting from tailSet() headSet() and subSet() normally > include the range which was used to create them. Using these methods > with emptySortedSet() does not currently set a range on the resulting > sets. Just to add to Jason's comment, would it be better to just leave out EMPTY_SORTED_SET from this patch? It would be nice not to have to load yet another class when Collections is first used and I assume we would encourage folks to use Collections.emptySortedSet() anyway so that they get type safety. -Alan. From alan.bateman at oracle.com Sun Oct 30 15:04:17 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 30 Oct 2011 15:04:17 +0000 Subject: hg: jdk8/tl/jdk: 7103889: (fs) Reduce String concatenation when iterating over directory Message-ID: <20111030150450.0B091471D3@hg.openjdk.java.net> Changeset: bb2b9a8b6e77 Author: alanb Date: 2011-10-30 14:53 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2b9a8b6e77 7103889: (fs) Reduce String concatenation when iterating over directory Reviewed-by: alanb Contributed-by: mike.skells at talk21.com ! src/share/classes/java/nio/file/Files.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java From Alan.Bateman at oracle.com Sun Oct 30 16:33:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 30 Oct 2011 16:33:06 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EAAF0C4.5070806@oracle.com> References: <4EAAF0C4.5070806@oracle.com> Message-ID: <4EAD7C42.1000103@oracle.com> On 28/10/2011 19:13, Se?n Coffey wrote: > This is a second stab at cleaning up the close() and finalize() > methods for FileInputStream / FileOutputStream / RandomAccessFile > classes so that all parents/referents sharing the same native > FileDescriptor are closed out correctly. > > With Alan's assistance, we have a better implementation in place where > we avoid the use of counters and instead cycle through a list of > shared closeables when a FileDescriptor is being shared. > > Bug report (not visible yet) > http://bugs.sun.com/view_bug.do?bug_id=7105952 > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/ > > regards, > Sean. Thanks for persevering with this somewhat hairy issue. I think the proposed solution is probably the best approach and it's also very simple/easy to understand. Folks may ask why FileDescriptor isn't keeping weak references to the enclosing streams and that's to keep it simple and avoid the complications that FileInputStream and FileOutputStream finalizers bring (they are specified to close the stream which is what lead to the previously messy solution). For the probably <1% of usages where applications create a stream and then construct a new stream with its FileDescriptor then it just means that the otherwise unreferenced stream will remain reachable while the other stream is reachable. One thing that I think would be good is to clarify the javadoc on exactly how "sharing" of file descriptors is intended to work. I'm not suggesting you do this as part of this change, but just a reminder that the javadoc needs improvement. Another point is that I think this fix should bake for while before thinking about 7u (I realize your primary interest is 7u but this one clearly needs bake time). On the changes then it's a pity that the additions to FileDescriptor have to be duplicated to both implementations. I think we need to look at going back to one implementation, possibly injecting the field for the handle at build time. Is closeAll missing other.close? I'm also not sure that the suppressed exception handle is completely right - consider the case that releaser.close fails after the close of at least two other streams fails. In that case I think we want the IOException from releaser.close to be thrown with the IOExcepton from the two streams to be the suppressed exceptions. If I read the code correctly then one of them will be the suppressed exception and in turn this will have the other exceptions as suppressed exceptions. In practical terms I don't think this is a big deal as the stack trace will have everything. Minor nit but shouldn't "closed" be private. Also probably should put the standard comments on attach and closeaAll The webrev makes it hard to read the changes to the test (did you hg mv or hg rm/add?). I think moving it from etc to FileDescriptor is a good idea and you can probably rename it simply to Sharing.java. -Alan. From david.holmes at oracle.com Mon Oct 31 00:52:08 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Oct 2011 10:52:08 +1000 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EAB3049.8040409@oracle.com> References: <4EAB3049.8040409@oracle.com> Message-ID: <4EADF138.30604@oracle.com> Darryl, On 29/10/2011 8:44 AM, Darryl Mocek wrote: > Hello. Please review this patch to add empty sorted set to the > Collections class. Test case provided. > > Webrev: http://cr.openjdk.java.net/~mduigou/4533691/1/webrev/ This was an RFE from 2001 - pre-generics. I don't think it makes sense to add to the pre-generics pollution by defining EMPTY_SORTED_SET. > Additional Notes to Reviewers: > The sets resulting from tailSet() headSet() and subSet() normally > include the range which was used to create them. Using these methods > with emptySortedSet() does not currently set a range on the resulting sets. What is the range on an empty set? David ----- > Thanks, > Darryl From xuelei.fan at oracle.com Mon Oct 31 03:09:13 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 31 Oct 2011 03:09:13 +0000 Subject: hg: jdk8/tl/jdk: 7106277: Brokenness in the seqNumberOverflow of MAC Message-ID: <20111031030931.47B4A471D4@hg.openjdk.java.net> Changeset: 30900a1a9cfc Author: xuelei Date: 2011-10-30 20:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30900a1a9cfc 7106277: Brokenness in the seqNumberOverflow of MAC Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/MAC.java From jason_mehrens at hotmail.com Mon Oct 31 18:08:18 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 31 Oct 2011 13:08:18 -0500 Subject: Collections.checkedQueue() offer method should not call add. Message-ID: Darryl, CheckedQueue.offer should call 'this.queue.offer' instead of 'this.add'. If you pass a Queue with bounded capacity (ArrayBlockingQueue) the CQ.offer method should return false when the queue is full but will instead throw an IllegalStateException. The current version also is performing the type check twice. Jason Changeset: c5c91589b126 Author: mduigou Date: 2011-10-19 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5c91589b126 5029031: Add Collections.checkedQueue() Reviewed-by: mduigou Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/CheckedQueue.java From bradford.wetmore at oracle.com Mon Oct 31 18:55:37 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Mon, 31 Oct 2011 18:55:37 +0000 Subject: hg: jdk8/tl/jdk: 7105780: Add SSLSocket client/SSLEngine server to templates directory Message-ID: <20111031185547.7C43D471DB@hg.openjdk.java.net> Changeset: 8681362a2f04 Author: wetmore Date: 2011-10-31 11:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8681362a2f04 7105780: Add SSLSocket client/SSLEngine server to templates directory Reviewed-by: xuelei + test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java From xueming.shen at oracle.com Mon Oct 31 21:23:46 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 31 Oct 2011 14:23:46 -0700 Subject: performance updates to jar and zip In-Reply-To: <1319756870.73164.YahooMailNeo@web86601.mail.ird.yahoo.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> <1319756870.73164.YahooMailNeo@web86601.mail.ird.yahoo.com> Message-ID: <4EAF11E2.7000008@oracle.com> Hi Mike, (1) While it's not a "significant benefit" :-) obviously it helps the through put to move the "loc writing" to the background work (together with the compression). I notice 10%+ improvement on one of my 4-core machine (vm OS installation, so the IO is supposed to be slow), when increasing the threads from 3-4. @flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cf rt.jar rtjar Warmup:rtjar...done Jar TotalTime:7211 [@flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cfT3 rt.jar rtjar Warmup:rtjar...done mtCreate: threadNum=3... Jar TotalTime:3266 [@flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cfT4 rt.jar rtjar Warmup:rtjar...done mtCreate: threadNum=4... Jar TotalTime:2754 (2) It's definitely fine with me to have a separate discussion regarding whether or not jar should have a -D like option for those know that they will never need the lastModified info in the jar/zip file they create. But I don't think we should count/include the time saved from using -D into the "performance improvement/gain" here, you trade off the functionality for speed here, especially this info is something specified by default in loc/cen tables. I also tried that javaToDosTime calculation in FIter2.java http://cr.openjdk.java.net/~sherman/mtjar2/FIter2.java I did not see any significant performance impact by doing javaToDosTime calculation, if I did not mis-understand what you meant. (3) I actually tried ArrayBlockingQueue, but it does not appear to help the performance in my setup, actually it slowdown the process a little, so I took it off the table. I might give it a try later. (4) Not separating the file loading and compression is by purpose, this way it helps to preserve the "order" of the files/dir scanned. The cost is as you suggested the main thread might get blocked on the queue, if the first in line has not finished the load/compression yet. But I did not see an easy way to preserve the sequential order by using a separate "completed" queue (doable, but makes thing complicated). While preserving the "order" is not a hard request, zip spec never specifies the order /structure of entries included, I don't any reason to break the existing behavior if the change does not bring in something significant. (5) There is potential memory issue with the current code, in worse case if the writing thread can not catch up with all compressing threads and you have an "unlimited" files to zip in. It can be addressed by either monitoring the memory usage or simply wrap the allocation with the try block, if we exhaust the memory, just pass the file directly without submit it into the job queue. But this is something we can consider later, the purpose of my code is to have some measure to see how far we can go, mostly because we don't have your code work on jdk8 yet. (6) I would not expect that we are going to add bunch of new public classes/apis just for this particular performance tuning, if those classes/apis don't bring in too much value for general jar/zip operation, for example, in my experimental code, I've added ZOS.writeNextEntry for the convenience of the experimenting/testing, but if we finally go this direction, I would assume we will end up having a "customized" ZipOutputStream in sun.tool.jar for this purpose instead of exposing that "writeNextEntry" API, as it probably serves nobody. Yes, that means those "public" classes/APIs in your proposal will have to have a very good story to back them to be "public". I'm looking for a workable JDK8 patch to test/work on:-) we need some data first, and then decide what will be in and what will be left behind. -Sherman http://cr.openjdk.java.net/~sherman/mtjar2/webrev/ On 10/27/2011 4:07 PM, Mike Skells wrote: > Hi Sherman, > I think that you will get significant benefit from generating the data > structures in the background threads. > I think that is you profile the usageyou will see that the generation > of the header information is the dominant feature. > That is why I parallelised the writing process. > > There are several bottlenecks such as the encoding of the name name > and (although you dismiss it) the calculation of the dos time format > is a CPU hog (the -D qualifier). I hink that it is about 10% of the > overall CPU load > > This is by the way pretty much in line with the extraction feature > below added in java 6, so I cant see that there is a great reason > against it, > after all why spend time storing information that (in most use cases) > is not read (either because the jar utility does not by default > maintain it, and most jar files are > probably not expanded anyway > /** > * If true, maintain compatibility with JDK releases prior to 6.0 by > * timestamping extracted files with the time at which they are > extracted. > * Default is to use the time given in the archive. > */ > private static final boolean useExtractionTime = > Boolean.getBoolean("sun.tools.jar.useExtractionTime"); > > > Here are the times that I get running the code that you wrote on my setup > > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf, cf, 10279 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT1, cfT1, 9652 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT2, cfT2, 6139 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT3, cfT3, 5683 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT4, cfT4, 6102 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT5, cfT5, 6172 > > I think that the reason that it tails off in performance is rather > that you are overloading the system with the background threads. You > have many threads (ie > cores) loading the files, and they are > contending for the CPU > and the writer thread is not getting its share of time, so with 3 > threads + the initail file scanning and the writer thread there are > more threads that can be services > > If you introduce an ArrayBlockingQueue for both of the scanning -> > compression and the compression->writing > and also get run of the cpu bound ( until the scanner gets going) > polling like > while(true) { > Object o = elist.poll(); > if (o == null) > continue; > > I dont think that you have the seperation of the loading and storing > sorted out. The code adds the future to elist, and the worker thread > reads it whether or not it has completed, > so some times the loading is done on the background thread before the > main thread reads it, and sometimes it blocks, even when other jobs > have completed, so I think that a completion queue > works better for this. It will complicate the END processing though > > If I am reading the code correctly I think that there are potential > memory issues. > There are an unlimitted number of jobs submitted to an executor, which > while it only executes T jobs, the jobs may still queue up in elist, > and each job can buffer 50Mb of data. If the writing of the output is > too slow you could run out of memory > > Line 666 and 672 (both return statements ) I think should be continue; > > With T1 there is no effective pipelining as I see it. The scannign > thread has to complete before the loading thread can start (as there > is only 1 CPU). So withthe blocking thread model we have to start at 2 > threads as otherwise it may deadlock itself > > with a blocking queue (and minor changes caused or implied by a > blocking queue) > > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf, cf, 10274 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT2, cfT2, 7201 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT3, cfT3, 5836 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT4, cfT4, 5884 > C:\Program Files\Java\jdk1.7.0\bin\java.exe -Xbootclasspath/p:, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT5, cfT5, 5890 > > I tried to repoduce the exception that you have, but I cant > I donw have a java8 install on this machine, or unix. > It does seem very strange that there is a file being written as "../" > in the first place though ( let alone a duplicate) > I didnt think that any of the API would return ../ > Is it only on Z3 that this error occurs? > > I will install a Java8 with the patch, but it will be at the start of > next week > > regards > > Mike > > > ------------------------------------------------------------------------ > *From:* Xueming Shen > *To:* core-libs-dev at openjdk.java.net > *Sent:* Thursday, 27 October 2011, 0:19 > *Subject:* Re: performance updates to jar and zip > > Hi Mark > > It appears the patch you provided throws unexpected exception > (attached at the end of my > email) when I tried it out on the latest JDK8 repository. Since > I only did a quick scan of your > patch, I'm not sure what went wrong here. > > This patch includes lots of stuff that obviously you are > trying/testing on, as you "warned" us in > your email, I can see at least it tries to > > (1) to support different compression level 0-9 > (2) parallel Zip file writing > (3) with various m-thread strategy -Z > (4) Files.walkFileTree instead of File.list > (5) the -D :-) which I would really not recommend to do > (6) small optimization in various places. > > which makes the code a little hard to read and the resulting data > hard to compare with. > I would suggest to divide this proposal to separate pieces and > work on them one by one, > for example maybe we can try to solve the main puzzle (2) + (3) > first, and then the other > optimization opportunities. > > To collect some data, I followed your lead to write a simple MT > support implementation > in Jar Main class as showed at > > http://cr.openjdk.java.net/~sherman/mtjar2/webrev2/ > > > which I guess is similar to what your are doing. It uses a > "simple" strategy > > (1) A dedicated thread (from the ExecutorService thread pool) to > iterate the file system > tree to "collect" the target files, submit a "compression > job" for each of these files > to the ExecutorService and keep the returned "Future" (from > the submission) in a > queue "elist". > (2) Threads from ExecutorService to use temporary buffer memory to > read and compress > the the file in memory . > (3) The main thread is polling the queue "elist", waiting for the > "compression job" to > cmplete and write the result into the target ZipOutputStream. > > The resulting data looks promising, I'm seeing the jar-ing speed > doubled when jar-ing > the rt.jar and a jdk7 binary tree, on a "slow" but 4-core linux vm > machine (I have the > similar result on a 2-hcore linux as well) > > java Jar cf jdk.jar jdk1.7.0 Jar TotalTime:17278 > java Jar cfT1 jdk.jar jdk1.7.0 Jar TotalTime:12345 > java Jar cfT2 jdk.jar jdk1.7.0 Jar TotalTime:7559 > java Jar cfT3 jdk.jar jdk1.7.0 Jar TotalTime:7572 > java Jar cfT4 jdk.jar jdk1.7.0 Jar TotalTime:7801 > java Jar cfT5 jdk.jar jdk1.7.0 Jar TotalTime:8112 > > The new "T" option for "n-thread", the digit number followed is to > specify the > fixed thread number for the executor service's thread pool. It > appears that we can > achieve the "best" result with only 3 threads in this > configuration. One thread for > scanning the file system, one thread for the compression and the > main thread for > the writing out. My guess is that the fact we have to "write out" > to a single file > (the resulting jar) limits the potential benefit of having more > "compressing" threads. > > I also tried to measure the "file scanning" speed in my > mini-benchmark FIter > > http://cr.openjdk.java.net/~sherman/mtjar2/FIter.java > > > Here are the "surprising" results. > > "nio" is the walkFileTree, > "io" is the File.list() > "io2" is the File.listFiles(). > > The nio's File.walkFileTree is 15 times faster than the > "traditional" recursion+File.list(). > wow! > > Linux-------------------------------------------------------------------------- > sherman at sherman-linux:~/Workspace/test$ java FIter ../jdk8_mtJar/src > java.io.File iteration > ------------------ > nio.totalSize:137149279 > fileNum:12222 > checkSum:16122691809689000 > Time:85 > ------------------ > io.totalSize:137149279 > fileNum:12222 > checkSum:16122691809689000 > Time:269 > ------------------ > io2.totalSize:137149279 > fileNum:12222 > checkSum:16122691809689000 > Time:450 > > Windows7--------------------------------------------------------------------------------- > > $ /cygdrive/c/Program\ Files\ \(x86\)/Java/jdk1.7.0/bin/java FIter > ../sqa/jdk8/src > java.io.File iteration > ------------------ > nio.totalSize:136695871 > fileNum:12199 > checkSum:15997350823839479 > Time:323 > ------------------ > io.totalSize:136695871 > fileNum:12199 > checkSum:15997350823839479 > Time:2633 > ------------------ > io2.totalSize:136695871 > fileNum:12199 > checkSum:15997350823839479 > Time:4592 > > > ---------------------------------------------------------------------- > > sherman at sherman-linux:~/Workspace/test$ > ../jdk8_mtJar/build/linux-i586/bin/jar cf6DZ3 rt0.jar rtjar > duplicate path > java.util.zip.ZipException: duplicate entry: ../ > at > java.util.zip.AbstractZipWriter.writeHeader(AbstractZipWriter.java:647) > at > java.util.zip.AbstractZipWriter.startWritingStored(AbstractZipWriter.java:384) > at > java.util.zip.AbstractZipWriter.writeWithResource(AbstractZipWriter.java:350) > at > java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:273) > at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) > at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) > at > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > java.util.concurrent.ExecutionException: > java.util.zip.ZipException: duplicate entry: ../ > at > java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) > at java.util.concurrent.FutureTask.get(FutureTask.java:111) > at sun.tools.jar.Main.waitFor(Main.java:810) > at sun.tools.jar.Main.run(Main.java:679) > at sun.tools.jar.Main.main(Main.java:1842) > Caused by: java.util.zip.ZipException: duplicate entry: ../ > > -Sherman > > On 10/20/2011 3:55 PM, Mike Skells wrote: > > Hi All, > > I have some performance updates for the jar tool and for the > Zip/Jar writing components, including some code to allow parallel > writing of Jar and ZIP files (in java.util) > > This work is not finished as yet but I am looking to see if > anyone has any views as to the shape this should move in > > Currently it is a testbed for comparing different techniques, > but largely based on the Jar utility > > > > The changes allow the work to be spread across multiple CPUs and > optimise the some of the code and I/O paths > > > > This comparative figures do not include the effect of the nio > changes that I proposed in earlier emails > > > > Command line changes > > 0--9 - I have added support for specifying different compression > levels (the existing jar command just allows default compression > or '0' for no compression > > D This allows the files to all be written with the date of now, > lather than the file date (the conversion of the date to zip > format is a CPU hog, and not needed in some use-cases) > > Z0-5 - these are the different mechanisms to allow different > parallel execution models - I would not expect this to be a > production qualifier > > > > The test environment is a 4 core Intel core2 pc running windows > vista 64, the test case is jaring up the content of rt.jar to a > jar file. Each test is repeated 6 times and the last 5 are > averaged to produce the answers. Each test is run in a fresh VM > > > > The performance figures are below as a CSV. The last column is > the duration of the task in ms. > > > > In summary the existing jar utility takes (for uncompressed, > compressed) 8.4 , 9.4 seconds to complete and this can be reduced > to 1.6, 2.3 seconds > > The different parallel algorithms are 0 - none all in one thread > as before > > 1 - file scanning in one core, 10 threads loading and buffering > files, zip writing in a single thread using the existing > ZipOuputStream > > 2. - file scanning in one core, 10 threads loading and buffering > files, zip writing mostly mutithreaded (e.g. parallel compression, > single write to the output stream) > > 3 - as 2 but writes to a file rather than a stream > > 4. as 2 but uses channels to be to write with direct buffers > > 5 as 4 but using heap buffers > > > > 3-5 have the zip capability in the code to seek and update > headers that are incomplete, but this is not much tested > > > > > > > > C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program > Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 > > C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program > Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program > Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program > Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, > project 1.7 rt -cf0, 3133 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, > project 1.7 rt -cf0D, 2824 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, > project 1.7 rt -cf0 parallel 0, 3026 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, > project 1.7 rt -cf0D parallel 0, 2961 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, > project 1.7 rt -cf0D parallel 1, 2022 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, > project 1.7 rt -cf0D parallel 2, 1757 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, > project 1.7 rt -cf0D parallel 3, 1632 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, > project 1.7 rt -cf0D parallel 4, 1994 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, > project 1.7 rt -cf0D parallel 5, 1978 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, > project 1.7 rt -cf1, 5237 > > > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, > project 1.7 rt -cf1D, 5073 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, > project 1.7 rt -cf1 parallel 0, 5367 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, > project 1.7 rt -cf1D parallel 0, 5002 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, > project 1.7 rt -cf1D parallel 1, 5125 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, > project 1.7 rt -cf1D parallel 2, 2257 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, > project 1.7 rt -cf1D parallel 3, 2145 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, > project 1.7 rt -cf1D parallel 4, 2505 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, > project 1.7 rt -cf1D parallel 5, 2549 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, > project 1.7 rt -cf2, 5371 > > > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, > project 1.7 rt -cf3, 5409 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, > project 1.7 rt -cf4, 5778 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, > project 1.7 rt -cf5, 5906 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, > project 1.7 rt -cf6, 6082 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, > project 1.7 rt -cf7, 6070 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, > project 1.7 rt -cf8, 6251 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, > project 1.7 rt -cf9, 6191 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, > project 1.7 rt -cf6D, 5843 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, > project 1.7 rt -cf6 parallel 0, 6095 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, > project 1.7 rt -cf6D parallel 0, 5907 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, > project 1.7 rt -cf6D parallel 1, 5957 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, > project 1.7 rt -cf6D parallel 2, 2388 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, > project 1.7 rt -cf6D parallel 3, 2351 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, > project 1.7 rt -cf6D parallel 4, 2694 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, > project 1.7 rt -cf6D parallel 5, 2830 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, > project 1.7 rt -cf9D, 6134 > > > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, > project 1.7 rt -cf9 parallel 0, 6258 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, > project 1.7 rt -cf9D parallel 0, 6066 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, > project 1.7 rt -cf9D parallel 1, 6203 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, > project 1.7 rt -cf9D parallel 2, 2490 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, > project 1.7 rt -cf9D parallel 3, 2361 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, > project 1.7 rt -cf9D parallel 4, 2788 > > C:\Program Files\Java\jdk1.7.0\bin\java.exe, > C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, > project 1.7 rt -cf9D parallel 5, 2847 > > > > regards > > Mike > > From bradford.wetmore at oracle.com Mon Oct 31 23:24:50 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Mon, 31 Oct 2011 23:24:50 +0000 Subject: hg: jdk8/tl/jdk: 7053252: New regression test does not compile on windows-amd64 Message-ID: <20111031232500.1E7B1471E7@hg.openjdk.java.net> Changeset: b60e88ef5d8d Author: wetmore Date: 2011-10-31 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b60e88ef5d8d 7053252: New regression test does not compile on windows-amd64 Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/Provider/Absolute.java From lordpixel at mac.com Wed Oct 5 02:59:55 2011 From: lordpixel at mac.com (Andrew Thompson) Date: Wed, 05 Oct 2011 02:59:55 -0000 Subject: JEP 103: Parallel Array Sorting - proposal, reaction to Mr. Harned post In-Reply-To: <4E8B3393.6080503@oracle.com> References: <19862960.851317721686499.JavaMail.root@zs.crcpraha> <4E8B3393.6080503@oracle.com> Message-ID: Both JEP 103 and JEP 108 are interesting to me because they remind me of something I've discussed a couple of times with one of the engineers working on the JDK at Apple. (I'll not name him solely because his input was a casual 'that sounds interesting' and I don't want to imply he endorses this idea.). The topic was Apple's Grand Central Dispatch and its applicability or lack thereof to Java programs. When we originally discussed it we noted that obviously the old Java idiom of doing 'new Thread()' directly in code is not remotely abstract enough for a vendor like Apple to be able to 'plug in' Grand Central (aka libdispatch) to do the scheduling. Of course, Executor/ExecutorService/Executors is a different story - since an ExecutorService can be a simple thread pool, a ForkJoinPool, or indeed, as Apple later created, a Grand Central backed pool: http://developer.apple.com/library/mac/documentation/Java/Reference/JavaSE6_AppleExtensionsRef/api/com/apple/concurrent/Dispatch.html But, what we concluded was Java 6 didn't offer an API or an SPI in this area. The creation of 'thread pools' is a bit more abstract than 'new Thread()' but really still fairly concrete ExecutorService myPool = Executors.newFixedThreadPool(5); // pretty clear what this means, create a pool with 5 new dedicated threads What I imagined would look something more like: ExecutorServer myCoolPool = Executors.defaultPlatformExecutorService(); //which on OSX might mean Grand Central dispatch (com.apple.concurrent.Dispatch) and something else on other platforms. Accompanying this would be an SPI allowing the 'default' thread pool to be changed. Well, JEP 103 has a similar idea embedded in it: "In addition to the actual sorting API this proposal adds a default ForkJoinPool to the platform. Consequently both the sorting API and access to the default pool is proposed to be provided by the ForkJoinUtils class: public final class ForkJoinUtils { public static ForkJoinPool defaultFJPool() { ... } ..." So is there any convergence between these ideas? Should we be thinking about adding a default ForkJoinPool to the platform, or should we be thinking about adding a default ExecutorService to the platform, which may or may not be a ForkJoinPool based on some clever logic the platform vendor could run based on # of cpus, memory, etc? I think the idea of a platform ExecutorService is interesting and may warrant its own separate JEP, which I'd be happy to write (I was thinking of doing so anyway, but I also thought it might make sense to prototype something first). On Oct 4, 2011, at 12:25 PM, David Holmes wrote: > Hi Janda, > > Thanks for the comments. > > On 4/10/2011 7:48 PM, Janda Martin wrote: >> >> I hope that this is correct mailing list to comment JEP 103. > > It certainly is. > >> Proposal: provide static methods for creating sort tasks. This allows developers to have full control over ForkJoinPool. > > I'd personally prefer to pass in the FJP to the sort method, rather than expose a SortTask type. Though I do cringe at the thought of all the additional methods (I wonder if Coin2 would be open to suggesting we add default arguments to Java ...) > >> There can be problem with one shared defaultFJPool() in multi-module applications (like Netbeans platform) when two modules requests different FJPool settings. > > Although the JEP proposes properties to allow the configuration of the default FJPool, the expectation is that: > > a) the majority of the time you will use the default configuration (desired parallelism level = number of 'processors') > > b) any change to the default config is done as a "system" setting, not by "local logic". By which I mean that it is not expected that different "modules" will attempt to do this configuration. Perhaps we need a way to enforce this. > > Personally I think there is room to have multiple FJPools in a system, but that makes most sense if the pools use disjoint sets of processors - which isn't currently supported in Java. > > But this is precisely the kind of feedback we are looking for, so thanks again. > > David Holmes > ------------ > >> public final class ForkJoinUtils { >> >> // should this be replaced? >> public static ForkJoinPool defaultFJPool() { ... } >> >> public static byte[] parallelSort(byte[] a) { ... } >> public static byte[] parallelSort(byte[] a, int fromIndex, int toIndex) >> {...} >> >> // with this? >> public static SortTask createParallelSortTask(byte[] a) {...} >> public static SortTask createParallelSortTask(byte[] a, int fromIndex, int toIndex) {...} >> ... >> >> } >> >> Reaction to Mr. Harned post >> >> I work as a Java SE software developer for several years. I think that Mr. Harned opinion to freeze Java in software history ('30' years ago) is not good idea. >> JSR 166 Fork/Join is great contribution to make Java better (thank you very much Doug Lea). Today CPUs just adds new cores so there have to be better support for parallelism. >> >> j.u.c package isn't only about sorting long arrays (huge overhead). Programs do a lot more. >> >> Thread, ThreadPool, FJPool and j.u.c are just small pieces in real application. They are solid and can be extended/controlled to support specific needs. >> >> I think that Mr. Harned should improve his own libraries to comply with his objections. I looked at his source code, demos and I prefer j.u.c to his work. >> >> Thank you everybody who works on Java >> >> Sincerely >> Martin JANDA >> >> PS sorry for my english AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me)