From martinrb at google.com Thu Jul 1 00:59:06 2010 From: martinrb at google.com (martinrb at google.com) Date: Thu, 01 Jul 2010 00:59:06 +0000 Subject: hg: jdk7/tl/jdk: 10 new changesets Message-ID: <20100701010103.008A747678@hg.openjdk.java.net> Changeset: 4436a3e97a9b Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4436a3e97a9b 6934268: Better implementation of Character.isValidCodePoint Summary: Use the cleverest possible bit-twiddling micro-optimizations Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 1776791f4fb9 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1776791f4fb9 6934265: Add public method Character.isBmpCodePoint Summary: Move isBmpCodePoint from sun.nio.cs.Surrogate to Character Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! test/java/nio/charset/coders/BashStreams.java - test/java/nio/charset/coders/Surrogate.java ! test/java/nio/charset/coders/Surrogates.java Changeset: 5503dbb2e6cc Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5503dbb2e6cc 6937112: String.lastIndexOf confused by unpaired trailing surrogate Summary: Rewrite lastIndexOf for performance and correctness Reviewed-by: sherman Contributed-by: Reviewed by Ulf Zibis ! src/share/classes/java/lang/String.java ! test/java/lang/String/Supplementary.java ! test/java/lang/StringBuffer/Supplementary.java ! test/java/lang/StringBuilder/Supplementary.java Changeset: 5e9daa8fd04a Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e9daa8fd04a 6940381: Wording improvements for String.indexOf, String.lastIndexOf Summary: Make wording of javadoc clearer and more consistent Reviewed-by: sherman ! src/share/classes/java/lang/String.java Changeset: 0d2bff3b2ca6 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d2bff3b2ca6 6963749: Minor improvements to Character.UnicodeBlock Summary: Fix surrogate area docs; make source more readable Reviewed-by: okutsu, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 4f1b4e3c6d1b Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f1b4e3c6d1b 6934270: Remove javac warnings from Character.java Summary: Use generics and conform to coding style Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java Changeset: 98186c162c1e Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98186c162c1e 6933322: Add methods highSurrogate(), lowSurrogate() to class Character Summary: Add public variants of methods Surrogate.high, Surrogate.low Reviewed-by: okutsu, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! test/java/nio/charset/coders/BashStreams.java Changeset: 838a21b99591 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/838a21b99591 6934271: Better handling of longer utf-8 sequences Summary: Various cleanups, including clever bit-twiddling Reviewed-by: sherman ! src/share/classes/sun/nio/cs/UTF_8.java Changeset: 9c80da212eaf Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c80da212eaf 6935172: Optimize bit-twiddling in Bits.java Summary: Transformations to reduce size of bytecode Reviewed-by: sherman Contributed-by: Based on an idea by Ulf Zibis ! src/share/classes/java/io/Bits.java Changeset: ce0ba8da0bd1 Author: martin Date: 2010-06-30 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce0ba8da0bd1 6940258: (bf) Use intrinsified reverseBytes operation; elide no-op constructs Reviewed-by: alanb, sherman Contributed-by: Ulf Zibis ! src/share/classes/java/nio/Bits.java From jonathan.gibbons at oracle.com Thu Jul 1 01:06:58 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 01 Jul 2010 01:06:58 +0000 Subject: hg: jdk7/tl/langtools: 6964768: need test program to validate javac resource bundles Message-ID: <20100701010705.7CF1847679@hg.openjdk.java.net> Changeset: d2b7ecf33b35 Author: jjg Date: 2010-06-30 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d2b7ecf33b35 6964768: need test program to validate javac resource bundles Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/literals/BadUnderscoreLiterals.6.out From alan.bateman at oracle.com Thu Jul 1 15:36:53 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Jul 2010 15:36:53 +0000 Subject: hg: jdk7/tl/jdk: 6947216: Even more Dual-pivot quicksort improvements Message-ID: <20100701153723.EEB57476AD@hg.openjdk.java.net> Changeset: a5a34c696d62 Author: alanb Date: 2010-07-01 16:28 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5a34c696d62 6947216: Even more Dual-pivot quicksort improvements Reviewed-by: jjb Contributed-by: vladimir.yaroslavskiy at sun.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java From jon.vanalten at redhat.com Thu Jul 1 17:05:52 2010 From: jon.vanalten at redhat.com (jon.vanalten at redhat.com) Date: Thu, 1 Jul 2010 13:05:52 -0400 (EDT) Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <744984656.1753281278003876288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <762458204.1753351278003952199.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi Martin, Thanks for your input. ----- "Martin Buchholz" wrote: > It's not at all clear that one cannot solve the y2038 problem on > systems with a 32-bit time_t. > That's what Michael Schwern is trying to do here: > http://code.google.com/p/y2038/ > His code is available. > Unfortunately unless I am missing something this example is not solving the y2038 problem for when a 32-bit system clock reaches overflow. See: http://code.google.com/p/y2038/wiki/HowItWorks It is simply allowing for representations of future times beyond 2038. Java already has this. From sean.mullan at oracle.com Thu Jul 1 20:16:01 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 01 Jul 2010 20:16:01 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100701201636.0BA42476B9@hg.openjdk.java.net> Changeset: 9bffc32b645d Author: mullan Date: 2010-07-01 15:20 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9bffc32b645d 6782979: Add JNLPAppletLauncher (6618105) to blacklist Reviewed-by: ohair ! make/java/security/Makefile Changeset: c0d2a097eb99 Author: mullan Date: 2010-07-01 15:30 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c0d2a097eb99 Merge From mandy.chung at oracle.com Fri Jul 2 22:54:37 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 02 Jul 2010 15:54:37 -0700 Subject: Review request for 6926663: incremental modules build support Message-ID: <4C2E6E2D.7020905@oracle.com> Alan, Kelly, Webrev: http://cr.openjdk.java.net/~mchung/6926663 It in fact contains 2 fixes: 1. integrate the latest jdk modularity fixes from jigsaw repos - add modules target in the top forest makefile [1] - support SKIP_BOOT_CYCLE=false modules build [2] - fix a couple of bugs in the launcher [3] - add JDK_HOST_PATH to support cross-architectural modules build [4] - cleanup on the modules.config and module names in makefiles 2. incremental modules build support to ease jdk development - the changes are mainly in make/modules and make/tools/classanalyzer files. The modules build includes two main steps: a. run the class analyzer tool to assign classes and resources in the jdk modules and analyzes their dependencies b. modularize the build output and create a module library containing the jdk modules I created a new tool com.sun.classanalyzer.Modularizer to do the files copying in step 2. Both ClassAnalyzer and Modularizer will process classes/resources files that are updated since the previous build. The jdk build will update a new file submodules/.modules.update if classes are recompiled, a library is rebuilt, or a file is installed in the jdk. The modules build will use the timestamp of .modules.update file to determine if it should do an incremental or do a full modules build. Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000742.html [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000613.html [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000523.html [4] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000683.html From Ulf.Zibis at gmx.de Sun Jul 4 17:11:24 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 04 Jul 2010 19:11:24 +0200 Subject: possible bug in java.util.DeflaterOutputStream Message-ID: <4C30C0BC.4020206@gmx.de> Hi, writing data to a zip file returns following 2 error lines: bit length overflow code 0 bits 6->7 I use: DataOutputStream dos = new DataOutputStream(new DeflaterOutputStream(new FileOutputStream(outFilePathName))); Is there any idea, where this comes from? The class to run: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/src_sherman2/build/tools/generatecharacter/CharacterNamesGenerator6.java?rev=1106&view=markup (From NetBeans run configuration gen_sherman2_6) My project: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/JDK-7/j_l_Character_names/?rev=1106 If I write to normal file, no error occurs: DataOutputStream dos = new DataOutputStream(new FileOutputStream(outFilePathName)); -Ulf From David.Holmes at oracle.com Tue Jul 6 23:49:21 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 07 Jul 2010 09:49:21 +1000 Subject: New portion of improvements for Dual-Pivot Quicksort In-Reply-To: <4C20B978.1040607@mail.ru> References: <4C20A97C.2050601@mail.ru> <4C20B766.3010202@gmail.com> <4C20B978.1040607@mail.ru> Message-ID: <4C33C101.1010005@oracle.com> I asked someone to take a look at this and it seems that the problem is that a[less++] requires introduction of a temporary to store the pre-incremented index value which in turn increases register pressure and can lead to a register spill. This seems to not only be architecture dependent but even variable on the same architecture (as observed below). As Osvaldo noted C1 does not attempt to decide whether the increment can be reordered with the access and so allow removal of the temporary. You'd need the compiler folk (C1/C2) to comment on whether or not it would be reasonable/possible/practical for C1 to do that - so I've cc'ed them (though I'm not a member of their list so it may be a little while before it gets pushed through to them.) David Holmes Vladimir Iaroslavski said the following on 06/22/10 23:24: > both computers with Intel processor: > > Pentium, Intel, 4 CPU, 3.2 GHz, 2 Gb RAM > Pentium, Intel, 4 CPU, 2.8 GHz, 2 Gb RAM > > Osvaldo Pinali Doederlein wrote: >> Hi Vladimir, >> >>> Hello, >>> >>> I tried with the latest JDK, build 98 and see different behaviour >>> on two computers: 7570 / 8318 and 8560 / 8590, but sorting method >>> works slower with a[less++] instruction on both computers: >> >> Is the first computer (with larger performance diff) an AMD by any >> chance? It's odd that just the a[less++] would make the code so much >> slower. Perhaps the worst compiled code has additional costs in some >> CPUs, e.g. spoiling branch prediction for the bounds checking guards. >> >> Anyway the change is risk-free (including performance) and the >> advantage is important at least in some CPUs, so go ahead (FWIW wrt my >> opinion...). I just wish that C1 would be fixed to not need this kind >> of hacking - as I categorize this as a hack, not even as a "normal" >> low-level Java code optimization - because there are certainly >> millions of uses of the idiom "array[index++/--]" in JavaSE APIs and >> elsewhere. But I'm not familiar with the C1 source so I don't know if >> this is some low hanging fruit that could be addressed quickly (any >> HotSpot engineers there to comment?). >> >> A+ >> Osvaldo >> >>> first second >>> a[less] = ak; less++; / (a[less++] = ak; >>> >>> random: 16371 / 16696 14018 / 14326 >>> ascendant: 2706 / 2762 2884 / 2897 >>> descendant: 2994 / 3108 3170 / 3258 >>> organ pipes: 7073 / 7296 6939 / 7090 >>> stagger(2): 7765 / 8069 7531 / 7731 >>> period(1,2): 653 / 743 719 / 753 >>> random(1..4): 2152 / 2234 1567 / 1591 >>> >>> If I change Test class and populate the array with descendant >>> values, I still see difference in times: 4793 / 5718 >>> see updated attached Test class. >>> >>> Also I'm attaching the latest version of DualPivotQuicksort >>> with minor format changes. If you don't have comments, I'll >>> ask to to integrate the code at the end of this week. >>> >>> Thank you, >>> Vladimir >>> >>> Osvaldo Doederlein wrote: >>>> Hi Vladimir, >>>> >>>> 2010/6/19 Vladimir Iaroslavski >>> > >>>> >>>> Hello Osvaldo, >>>> >>>> I've prepared simple test which scans an array and does assignments >>>> for each element, >>>> see attached Test class: >>>> >>>> a[k] = a[less]; >>>> a[less++] = 0; // or a[less] = 0; less++; >>>> >>>> The result of running "java -client Test" is: >>>> >>>> a[less], less++; Time: 6998 >>>> a[less++]; Time: 8416 >>>> >>>> It is much more than 1%. Is it bug in JVM? Note that under >>>> server VM >>>> >>>> The amount of diff surely depends on the benchmark; your bench >>>> should "zoom" the problem by not having much other work polluting >>>> the measurement. But in my own test with b98 (32-bit), Q6600 CPU, >>>> I've got 5065/5079, so the diff is < 1%. The excessive disadvantage >>>> you report may be something bad in your older b84. >>>> >>>> Anyway I investigated the JIT-compiled code, details in the end >>>> (I've split the benchmark in two classes just to make the comparison >>>> simpler). The problem with "a[less++]" is that "less++" will first >>>> increment "less", _then_ it will use the old value (not-incremented) >>>> to index "a". C1 generates code that is equivalent to: >>>> >>>> int less_incremented = less + 1; >>>> a[less] = 0; >>>> less = less_incremented; >>>> >>>> ...which is a 1-to-1 translation of the IR coming off the bytecode. >>>> C1 is not smart enough to see that the increment can be reordered >>>> after the indexing, maybe because there's a data dependency as the >>>> indexing uses "less"; but due to the semantics of postfix "++" this >>>> dependency is for the before-increment value, so the reordering >>>> would be safe. Maybe that's just some simple missing heuristics that >>>> could be easily added? >>>> >>>> there is no difference between "a[less++]" and "a[less], less++". >>>> >>>> C2 generates completely different code,with 16X unrolling - this is >>>> the inner loop: >>>> >>>> 0x026a6e40: pxor %xmm0,%xmm0 ;*aload_0 >>>> ; - Test1::sort1 at 9 (line 23) >>>> 0x026a6e44: movq %xmm0,0xc(%ecx,%esi,4) >>>> 0x026a6e4a: movq %xmm0,0x14(%ecx,%esi,4) >>>> 0x026a6e50: movq %xmm0,0x1c(%ecx,%esi,4) >>>> 0x026a6e56: movq %xmm0,0x24(%ecx,%esi,4) >>>> 0x026a6e5c: movq %xmm0,0x2c(%ecx,%esi,4) >>>> 0x026a6e62: movq %xmm0,0x34(%ecx,%esi,4) >>>> 0x026a6e68: movq %xmm0,0x3c(%ecx,%esi,4) >>>> 0x026a6e6e: movq %xmm0,0x44(%ecx,%esi,4) ;*iastore >>>> ; - Test1::sort1 at 21 (line 24) >>>> 0x026a6e74: add $0x10,%esi ;*iinc >>>> ; - Test1::sort1 at 22 (line 22) >>>> 0x026a6e77: cmp %ebp,%esi >>>> 0x026a6e79: jl 0x026a6e44 >>>> >>>> There is some extra slow-path code to fill the remaining 1...15 >>>> elements if the loop length is not multiple of 16, and that's all. >>>> C2 detects the redundancy between the "k" and "less" vars, and kills >>>> the also-redundant "a[k] = a[less]" assignment so the net result is >>>> a simple zero-fill of the array. Maybe a different benchmark without >>>> these redundancies would make easier to see that C2 doesn't have a >>>> problem with the postfix "++", but if it had, I think it wouldn't >>>> reach the excellent result above. >>>> >>>> A+ >>>> Osvaldo >>>> >>>> >>>> I'm using JDK 7 on Windows XP: >>>> >>>> java version "1.7.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b84) >>>> Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> >>>> This is the C1 code for sort2()'s loop: >>>> >>>> 0x0251c1dc: cmp 0x8(%ecx),%esi ; implicit exception: >>>> dispatches to 0x0251c21e >>>> ;; 30 branch [AE] [RangeCheckStub: 0x454c640] [bci:13] >>>> 0x0251c1df: jae 0x0251c24a >>>> 0x0251c1e5: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>> ; - Test2::sort2 at 13 (line 23) >>>> 0x0251c1e9: cmp 0x8(%ecx),%edi >>>> ;; 36 branch [AE] [RangeCheckStub: 0x454c7e0] [bci:14] >>>> 0x0251c1ec: jae 0x0251c263 >>>> 0x0251c1f2: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>> ; - Test2::sort2 at 14 (line 23) >>>> >>>> (sort1/sort2 start to differ here) >>>> >>>> 0x0251c1f6: cmp 0x8(%ecx),%esi >>>> ;; 42 branch [AE] [RangeCheckStub: 0x454c980] [bci:18] >>>> 0x0251c1f9: jae 0x0251c27c >>>> 0x0251c1ff: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less] = 0; >>>> ; - Test2::sort2 at 18 (line 24) >>>> 0x0251c207: inc %esi ; ++less; >>>> 0x0251c208: inc %edi ; OopMap{ecx=Oop off=73} >>>> ;*goto: for k++ >>>> ; - Test2::sort2 at 25 (line 22) >>>> 0x0251c209: test %eax,0x1a0100 ;*goto >>>> ; - Test2::sort2 at 25 (line 22) >>>> ; {poll} >>>> ;; block B1 [4, 6] >>>> >>>> 0x0251c20f: cmp %edx,%edi >>>> ;; 22 branch [LT] [B2] >>>> 0x0251c211: jl 0x0251c1dc ;*if_icmpge: for k < right >>>> ; - Test2::sort2 at 6 (line 22) >>>> >>>> The code looks OK; C1 doesn't do much optimization - no unrolling, >>>> bounds check elimination - but it's otherwise just about the code >>>> you would expect for a simple JITting. >>>> Now, C1 code for sort1()'s loop: >>>> >>>> 0x024bc21c: cmp 0x8(%ecx),%esi ; implicit exception: >>>> dispatches to 0x024bc262 >>>> ;; 30 branch [AE] [RangeCheckStub: 0x44ee3b0] [bci:13] >>>> 0x024bc21f: jae 0x024bc28e >>>> 0x024bc225: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>> ; - Test1::sort1 at 13 (line 23) >>>> 0x024bc229: cmp 0x8(%ecx),%edi >>>> ;; 36 branch [AE] [RangeCheckStub: 0x44ee550] [bci:14] >>>> 0x024bc22c: jae 0x024bc2a7 >>>> 0x024bc232: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>> ; - Test1::sort1 at 14 (line 23) >>>> >>>> (sort1/sort2 start to differ here) >>>> >>>> 0x024bc236: mov %esi,%ebx ; Crap! C1 temps 'less' into >>>> %ebx >>>> 0x024bc238: inc %ebx ; ++less; (for the temp >>>> "less from future") >>>> >>>> 0x024bc239: cmp 0x8(%ecx),%esi ; %esi is still the "old >>>> less".... >>>> ;; 46 branch [AE] [RangeCheckStub: 0x44ee7b8] [bci:21] >>>> 0x024bc23c: jae 0x024bc2c0 >>>> 0x024bc242: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less++] = 0; >>>> ; - Test1::sort1 at 21 (line 24) >>>> 0x024bc24a: inc %edi ; OopMap{ecx=Oop off=75} >>>> ;*goto: for k++ >>>> ; - Test1::sort1 at 25 (line 22) >>>> 0x024bc24b: test %eax,0x1a0100 ; {poll} >>>> 0x024bc251: mov %ebx,%esi ;*goto >>>> ; - Test1::sort1 at 25 (line >>>> 22): for... >>>> ;; block B1 [4, 6] >>>> >>>> 0x024bc253: cmp %edx,%edi >>>> ;; 22 branch [LT] [B2] >>>> 0x024bc255: jl 0x024bc21c ;*if_icmpge >>>> ; - Test1::sort1 at 6 (line >>>> 22): for... From opinali at gmail.com Wed Jul 7 01:42:14 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Tue, 6 Jul 2010 22:42:14 -0300 Subject: New portion of improvements for Dual-Pivot Quicksort In-Reply-To: <4C33C101.1010005@oracle.com> References: <4C20A97C.2050601@mail.ru> <4C20B766.3010202@gmail.com> <4C20B978.1040607@mail.ru> <4C33C101.1010005@oracle.com> Message-ID: The ironic thing is that these operators were originally introduced in the C language, at least according to well-known folklore, as an optimization - taking advantage of inc/dec instructions from the PDP arch, in the old times when (I suppose) compilers wouldn't do even basic strength-reduction optimizations like x + 1 => inc x. But this works well for pre-inc/dec, but post-increment and post-decrement have a more complex semantics that requires inducing an extra temporary if the compiler is not smart enough. My personal coding style, since my days of C, enforces pre- instead of post- operators; I will always write ++i, never i++, when both choices have the same effect. This is exactly because it's the post- operators that have confusing and error-prone semantics, as soon as the inc/dec operation is used as RHS of a bigger expression (or used a parameter etc.), and not as an isolated statement. I will use post- operators only when I really need its semantics to make my code a little extra terse. And now we discover another gotcha of post- operators: potentially less efficient code generation. It's worth noticing this, because I the post- operators seem to be the preferred style for most people, they can even be found in many Java style guidelines... I wonder why. Perhaps it's just the name of the C++ language that has taught a generation to like this wrong style? In that case, the blame goes to Stroustrup, he should have named it "++C" instead. That would get extra nerd points too ;-) A+ Osvaldo 2010/7/6 David Holmes > I asked someone to take a look at this and it seems that the problem is > that a[less++] requires introduction of a temporary to store the > pre-incremented index value which in turn increases register pressure and > can lead to a register spill. This seems to not only be architecture > dependent but even variable on the same architecture (as observed below). > > As Osvaldo noted C1 does not attempt to decide whether the increment can be > reordered with the access and so allow removal of the temporary. You'd need > the compiler folk (C1/C2) to comment on whether or not it would be > reasonable/possible/practical for C1 to do that - so I've cc'ed them (though > I'm not a member of their list so it may be a little while before it gets > pushed through to them.) > > David Holmes > > Vladimir Iaroslavski said the following on 06/22/10 23:24: > > both computers with Intel processor: >> >> Pentium, Intel, 4 CPU, 3.2 GHz, 2 Gb RAM >> Pentium, Intel, 4 CPU, 2.8 GHz, 2 Gb RAM >> >> Osvaldo Pinali Doederlein wrote: >> >>> Hi Vladimir, >>> >>> Hello, >>>> >>>> I tried with the latest JDK, build 98 and see different behaviour >>>> on two computers: 7570 / 8318 and 8560 / 8590, but sorting method >>>> works slower with a[less++] instruction on both computers: >>>> >>> >>> Is the first computer (with larger performance diff) an AMD by any >>> chance? It's odd that just the a[less++] would make the code so much slower. >>> Perhaps the worst compiled code has additional costs in some CPUs, e.g. >>> spoiling branch prediction for the bounds checking guards. >>> >>> Anyway the change is risk-free (including performance) and the advantage >>> is important at least in some CPUs, so go ahead (FWIW wrt my opinion...). I >>> just wish that C1 would be fixed to not need this kind of hacking - as I >>> categorize this as a hack, not even as a "normal" low-level Java code >>> optimization - because there are certainly millions of uses of the idiom >>> "array[index++/--]" in JavaSE APIs and elsewhere. But I'm not familiar with >>> the C1 source so I don't know if this is some low hanging fruit that could >>> be addressed quickly (any HotSpot engineers there to comment?). >>> >>> A+ >>> Osvaldo >>> >>> first second >>>> a[less] = ak; less++; / (a[less++] = ak; >>>> >>>> random: 16371 / 16696 14018 / 14326 >>>> ascendant: 2706 / 2762 2884 / 2897 >>>> descendant: 2994 / 3108 3170 / 3258 >>>> organ pipes: 7073 / 7296 6939 / 7090 >>>> stagger(2): 7765 / 8069 7531 / 7731 >>>> period(1,2): 653 / 743 719 / 753 >>>> random(1..4): 2152 / 2234 1567 / 1591 >>>> >>>> If I change Test class and populate the array with descendant >>>> values, I still see difference in times: 4793 / 5718 >>>> see updated attached Test class. >>>> >>>> Also I'm attaching the latest version of DualPivotQuicksort >>>> with minor format changes. If you don't have comments, I'll >>>> ask to to integrate the code at the end of this week. >>>> >>>> Thank you, >>>> Vladimir >>>> >>>> Osvaldo Doederlein wrote: >>>> >>>>> Hi Vladimir, >>>>> >>>>> 2010/6/19 Vladimir Iaroslavski >>>> iaroslavski at mail.ru>> >>>>> >>>>> Hello Osvaldo, >>>>> >>>>> I've prepared simple test which scans an array and does assignments >>>>> for each element, >>>>> see attached Test class: >>>>> >>>>> a[k] = a[less]; >>>>> a[less++] = 0; // or a[less] = 0; less++; >>>>> >>>>> The result of running "java -client Test" is: >>>>> >>>>> a[less], less++; Time: 6998 >>>>> a[less++]; Time: 8416 >>>>> >>>>> It is much more than 1%. Is it bug in JVM? Note that under server VM >>>>> >>>>> The amount of diff surely depends on the benchmark; your bench should >>>>> "zoom" the problem by not having much other work polluting the measurement. >>>>> But in my own test with b98 (32-bit), Q6600 CPU, I've got 5065/5079, so the >>>>> diff is < 1%. The excessive disadvantage you report may be something bad in >>>>> your older b84. >>>>> >>>>> Anyway I investigated the JIT-compiled code, details in the end (I've >>>>> split the benchmark in two classes just to make the comparison simpler). The >>>>> problem with "a[less++]" is that "less++" will first increment "less", >>>>> _then_ it will use the old value (not-incremented) to index "a". C1 >>>>> generates code that is equivalent to: >>>>> >>>>> int less_incremented = less + 1; >>>>> a[less] = 0; >>>>> less = less_incremented; >>>>> >>>>> ...which is a 1-to-1 translation of the IR coming off the bytecode. C1 >>>>> is not smart enough to see that the increment can be reordered after the >>>>> indexing, maybe because there's a data dependency as the indexing uses >>>>> "less"; but due to the semantics of postfix "++" this dependency is for the >>>>> before-increment value, so the reordering would be safe. Maybe that's just >>>>> some simple missing heuristics that could be easily added? >>>>> >>>>> there is no difference between "a[less++]" and "a[less], less++". >>>>> >>>>> C2 generates completely different code,with 16X unrolling - this is the >>>>> inner loop: >>>>> >>>>> 0x026a6e40: pxor %xmm0,%xmm0 ;*aload_0 >>>>> ; - Test1::sort1 at 9 (line 23) >>>>> 0x026a6e44: movq %xmm0,0xc(%ecx,%esi,4) >>>>> 0x026a6e4a: movq %xmm0,0x14(%ecx,%esi,4) >>>>> 0x026a6e50: movq %xmm0,0x1c(%ecx,%esi,4) >>>>> 0x026a6e56: movq %xmm0,0x24(%ecx,%esi,4) >>>>> 0x026a6e5c: movq %xmm0,0x2c(%ecx,%esi,4) >>>>> 0x026a6e62: movq %xmm0,0x34(%ecx,%esi,4) >>>>> 0x026a6e68: movq %xmm0,0x3c(%ecx,%esi,4) >>>>> 0x026a6e6e: movq %xmm0,0x44(%ecx,%esi,4) ;*iastore >>>>> ; - Test1::sort1 at 21 (line 24) >>>>> 0x026a6e74: add $0x10,%esi ;*iinc >>>>> ; - Test1::sort1 at 22 (line 22) >>>>> 0x026a6e77: cmp %ebp,%esi >>>>> 0x026a6e79: jl 0x026a6e44 >>>>> >>>>> There is some extra slow-path code to fill the remaining 1...15 >>>>> elements if the loop length is not multiple of 16, and that's all. C2 >>>>> detects the redundancy between the "k" and "less" vars, and kills the >>>>> also-redundant "a[k] = a[less]" assignment so the net result is a simple >>>>> zero-fill of the array. Maybe a different benchmark without these >>>>> redundancies would make easier to see that C2 doesn't have a problem with >>>>> the postfix "++", but if it had, I think it wouldn't reach the excellent >>>>> result above. >>>>> >>>>> A+ >>>>> Osvaldo >>>>> >>>>> >>>>> I'm using JDK 7 on Windows XP: >>>>> >>>>> java version "1.7.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b84) >>>>> Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing) >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> >>>>> This is the C1 code for sort2()'s loop: >>>>> >>>>> 0x0251c1dc: cmp 0x8(%ecx),%esi ; implicit exception: dispatches >>>>> to 0x0251c21e >>>>> ;; 30 branch [AE] [RangeCheckStub: 0x454c640] [bci:13] >>>>> 0x0251c1df: jae 0x0251c24a >>>>> 0x0251c1e5: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>>> ; - Test2::sort2 at 13 (line 23) >>>>> 0x0251c1e9: cmp 0x8(%ecx),%edi >>>>> ;; 36 branch [AE] [RangeCheckStub: 0x454c7e0] [bci:14] >>>>> 0x0251c1ec: jae 0x0251c263 >>>>> 0x0251c1f2: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>>> ; - Test2::sort2 at 14 (line 23) >>>>> >>>>> (sort1/sort2 start to differ here) >>>>> >>>>> 0x0251c1f6: cmp 0x8(%ecx),%esi >>>>> ;; 42 branch [AE] [RangeCheckStub: 0x454c980] [bci:18] >>>>> 0x0251c1f9: jae 0x0251c27c >>>>> 0x0251c1ff: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less] = 0; >>>>> ; - Test2::sort2 at 18 (line 24) >>>>> 0x0251c207: inc %esi ; ++less; >>>>> 0x0251c208: inc %edi ; OopMap{ecx=Oop off=73} >>>>> ;*goto: for k++ >>>>> ; - Test2::sort2 at 25 (line 22) >>>>> 0x0251c209: test %eax,0x1a0100 ;*goto >>>>> ; - Test2::sort2 at 25 (line 22) >>>>> ; {poll} >>>>> ;; block B1 [4, 6] >>>>> >>>>> 0x0251c20f: cmp %edx,%edi >>>>> ;; 22 branch [LT] [B2] >>>>> 0x0251c211: jl 0x0251c1dc ;*if_icmpge: for k < right >>>>> ; - Test2::sort2 at 6 (line 22) >>>>> >>>>> The code looks OK; C1 doesn't do much optimization - no unrolling, >>>>> bounds check elimination - but it's otherwise just about the code you would >>>>> expect for a simple JITting. >>>>> Now, C1 code for sort1()'s loop: >>>>> >>>>> 0x024bc21c: cmp 0x8(%ecx),%esi ; implicit exception: dispatches >>>>> to 0x024bc262 >>>>> ;; 30 branch [AE] [RangeCheckStub: 0x44ee3b0] [bci:13] >>>>> 0x024bc21f: jae 0x024bc28e >>>>> 0x024bc225: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; >>>>> ; - Test1::sort1 at 13 (line 23) >>>>> 0x024bc229: cmp 0x8(%ecx),%edi >>>>> ;; 36 branch [AE] [RangeCheckStub: 0x44ee550] [bci:14] >>>>> 0x024bc22c: jae 0x024bc2a7 >>>>> 0x024bc232: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; >>>>> ; - Test1::sort1 at 14 (line 23) >>>>> >>>>> (sort1/sort2 start to differ here) >>>>> >>>>> 0x024bc236: mov %esi,%ebx ; Crap! C1 temps 'less' into >>>>> %ebx >>>>> 0x024bc238: inc %ebx ; ++less; (for the temp "less >>>>> from future") >>>>> >>>>> 0x024bc239: cmp 0x8(%ecx),%esi ; %esi is still the "old >>>>> less".... >>>>> ;; 46 branch [AE] [RangeCheckStub: 0x44ee7b8] [bci:21] >>>>> 0x024bc23c: jae 0x024bc2c0 >>>>> 0x024bc242: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less++] = 0; >>>>> ; - Test1::sort1 at 21 (line 24) >>>>> 0x024bc24a: inc %edi ; OopMap{ecx=Oop off=75} >>>>> ;*goto: for k++ >>>>> ; - Test1::sort1 at 25 (line 22) >>>>> 0x024bc24b: test %eax,0x1a0100 ; {poll} >>>>> 0x024bc251: mov %ebx,%esi ;*goto >>>>> ; - Test1::sort1 at 25 (line 22): >>>>> for... >>>>> ;; block B1 [4, 6] >>>>> >>>>> 0x024bc253: cmp %edx,%edi >>>>> ;; 22 branch [LT] [B2] >>>>> 0x024bc255: jl 0x024bc21c ;*if_icmpge >>>>> ; - Test1::sort1 at 6 (line 22): >>>>> for... >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jul 7 01:57:58 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 07 Jul 2010 01:57:58 +0000 Subject: hg: jdk7/tl/jdk: 6963723: Project Coin: Retrofit more JDK classes for ARM Message-ID: <20100707015825.8F78E477E4@hg.openjdk.java.net> Changeset: 425960cef714 Author: darcy Date: 2010-07-06 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/425960cef714 6963723: Project Coin: Retrofit more JDK classes for ARM Reviewed-by: alanb, malenkov, prr, amenkov ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/io/ObjectInput.java ! src/share/classes/java/io/ObjectOutput.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/Receiver.java ! src/share/classes/javax/sound/midi/Transmitter.java ! src/share/classes/javax/sound/sampled/Line.java From tom.rodriguez at oracle.com Wed Jul 7 03:27:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Jul 2010 20:27:22 -0700 Subject: New portion of improvements for Dual-Pivot Quicksort In-Reply-To: References: <4C20A97C.2050601@mail.ru> <4C20B766.3010202@gmail.com> <4C20B978.1040607@mail.ru> <4C33C101.1010005@oracle.com> Message-ID: I actually looked into this in some detail and the reason for the difference in C1 is two fold. First the state of the JVM at array load is slightly different for a[i++] vs. a[i], i++. In the first case the top state has a copy of the original i but the local for i has i+1. In the second there is only i. This increases the register pressure since we C1 currently keeps all the locals live in the JVM state for the possible exception for the range check. C1 doesn't always need to keep those values live and there is a workspace where where we are more aggressive about killing unneeded locals in the states used for exceptions. Those changes are probably (hopefully) coming to hs19. Unfortunately there's another reason for this specific example that we force both i and i + 1 to be live simultaneously. C1 doesn't do any cross block scheduling so values which are computed in one block but only used in a later one are evaluated in their original bytecode order relative to other bytecodes which could cause exceptions. This again means we evaluated i + 1 earlier than we absolutely have to since i + 1 is live out of the block into a phi. This is relatively easy to fix by replacing the pin_for_linear_scan logic with an explicit walk of the final ValueStack to evaluate anything which is live out but not yet evaluated. That way values which are live out but unused within the block are evaluated last. This gives you code that's exactly the same for both variants. So that's the long explanation. My recommendation is to continue to write the code in a natural way. tom On Jul 6, 2010, at 6:42 PM, Osvaldo Doederlein wrote: > The ironic thing is that these operators were originally introduced in the C language, at least according to well-known folklore, as an optimization - taking advantage of inc/dec instructions from the PDP arch, in the old times when (I suppose) compilers wouldn't do even basic strength-reduction optimizations like x + 1 => inc x. But this works well for pre-inc/dec, but post-increment and post-decrement have a more complex semantics that requires inducing an extra temporary if the compiler is not smart enough. > > My personal coding style, since my days of C, enforces pre- instead of post- operators; I will always write ++i, never i++, when both choices have the same effect. This is exactly because it's the post- operators that have confusing and error-prone semantics, as soon as the inc/dec operation is used as RHS of a bigger expression (or used a parameter etc.), and not as an isolated statement. I will use post- operators only when I really need its semantics to make my code a little extra terse. And now we discover another gotcha of post- operators: potentially less efficient code generation. It's worth noticing this, because I the post- operators seem to be the preferred style for most people, they can even be found in many Java style guidelines... I wonder why. > > Perhaps it's just the name of the C++ language that has taught a generation to like this wrong style? In that case, the blame goes to Stroustrup, he should have named it "++C" instead. That would get extra nerd points too ;-) > > A+ > Osvaldo > > 2010/7/6 David Holmes > I asked someone to take a look at this and it seems that the problem is that a[less++] requires introduction of a temporary to store the pre-incremented index value which in turn increases register pressure and can lead to a register spill. This seems to not only be architecture dependent but even variable on the same architecture (as observed below). > > As Osvaldo noted C1 does not attempt to decide whether the increment can be reordered with the access and so allow removal of the temporary. You'd need the compiler folk (C1/C2) to comment on whether or not it would be reasonable/possible/practical for C1 to do that - so I've cc'ed them (though I'm not a member of their list so it may be a little while before it gets pushed through to them.) > > David Holmes > > Vladimir Iaroslavski said the following on 06/22/10 23:24: > > both computers with Intel processor: > > Pentium, Intel, 4 CPU, 3.2 GHz, 2 Gb RAM > Pentium, Intel, 4 CPU, 2.8 GHz, 2 Gb RAM > > Osvaldo Pinali Doederlein wrote: > Hi Vladimir, > > Hello, > > I tried with the latest JDK, build 98 and see different behaviour > on two computers: 7570 / 8318 and 8560 / 8590, but sorting method > works slower with a[less++] instruction on both computers: > > Is the first computer (with larger performance diff) an AMD by any chance? It's odd that just the a[less++] would make the code so much slower. Perhaps the worst compiled code has additional costs in some CPUs, e.g. spoiling branch prediction for the bounds checking guards. > > Anyway the change is risk-free (including performance) and the advantage is important at least in some CPUs, so go ahead (FWIW wrt my opinion...). I just wish that C1 would be fixed to not need this kind of hacking - as I categorize this as a hack, not even as a "normal" low-level Java code optimization - because there are certainly millions of uses of the idiom "array[index++/--]" in JavaSE APIs and elsewhere. But I'm not familiar with the C1 source so I don't know if this is some low hanging fruit that could be addressed quickly (any HotSpot engineers there to comment?). > > A+ > Osvaldo > > first second > a[less] = ak; less++; / (a[less++] = ak; > > random: 16371 / 16696 14018 / 14326 > ascendant: 2706 / 2762 2884 / 2897 > descendant: 2994 / 3108 3170 / 3258 > organ pipes: 7073 / 7296 6939 / 7090 > stagger(2): 7765 / 8069 7531 / 7731 > period(1,2): 653 / 743 719 / 753 > random(1..4): 2152 / 2234 1567 / 1591 > > If I change Test class and populate the array with descendant > values, I still see difference in times: 4793 / 5718 > see updated attached Test class. > > Also I'm attaching the latest version of DualPivotQuicksort > with minor format changes. If you don't have comments, I'll > ask to to integrate the code at the end of this week. > > Thank you, > Vladimir > > Osvaldo Doederlein wrote: > Hi Vladimir, > > 2010/6/19 Vladimir Iaroslavski > > > Hello Osvaldo, > > I've prepared simple test which scans an array and does assignments > for each element, > see attached Test class: > > a[k] = a[less]; > a[less++] = 0; // or a[less] = 0; less++; > > The result of running "java -client Test" is: > > a[less], less++; Time: 6998 > a[less++]; Time: 8416 > > It is much more than 1%. Is it bug in JVM? Note that under server VM > > The amount of diff surely depends on the benchmark; your bench should "zoom" the problem by not having much other work polluting the measurement. But in my own test with b98 (32-bit), Q6600 CPU, I've got 5065/5079, so the diff is < 1%. The excessive disadvantage you report may be something bad in your older b84. > > Anyway I investigated the JIT-compiled code, details in the end (I've split the benchmark in two classes just to make the comparison simpler). The problem with "a[less++]" is that "less++" will first increment "less", _then_ it will use the old value (not-incremented) to index "a". C1 generates code that is equivalent to: > > int less_incremented = less + 1; > a[less] = 0; > less = less_incremented; > > ...which is a 1-to-1 translation of the IR coming off the bytecode. C1 is not smart enough to see that the increment can be reordered after the indexing, maybe because there's a data dependency as the indexing uses "less"; but due to the semantics of postfix "++" this dependency is for the before-increment value, so the reordering would be safe. Maybe that's just some simple missing heuristics that could be easily added? > > there is no difference between "a[less++]" and "a[less], less++". > > C2 generates completely different code,with 16X unrolling - this is the inner loop: > > 0x026a6e40: pxor %xmm0,%xmm0 ;*aload_0 > ; - Test1::sort1 at 9 (line 23) > 0x026a6e44: movq %xmm0,0xc(%ecx,%esi,4) > 0x026a6e4a: movq %xmm0,0x14(%ecx,%esi,4) > 0x026a6e50: movq %xmm0,0x1c(%ecx,%esi,4) > 0x026a6e56: movq %xmm0,0x24(%ecx,%esi,4) > 0x026a6e5c: movq %xmm0,0x2c(%ecx,%esi,4) > 0x026a6e62: movq %xmm0,0x34(%ecx,%esi,4) > 0x026a6e68: movq %xmm0,0x3c(%ecx,%esi,4) > 0x026a6e6e: movq %xmm0,0x44(%ecx,%esi,4) ;*iastore > ; - Test1::sort1 at 21 (line 24) > 0x026a6e74: add $0x10,%esi ;*iinc > ; - Test1::sort1 at 22 (line 22) > 0x026a6e77: cmp %ebp,%esi > 0x026a6e79: jl 0x026a6e44 > > There is some extra slow-path code to fill the remaining 1...15 elements if the loop length is not multiple of 16, and that's all. C2 detects the redundancy between the "k" and "less" vars, and kills the also-redundant "a[k] = a[less]" assignment so the net result is a simple zero-fill of the array. Maybe a different benchmark without these redundancies would make easier to see that C2 doesn't have a problem with the postfix "++", but if it had, I think it wouldn't reach the excellent result above. > > A+ > Osvaldo > > > I'm using JDK 7 on Windows XP: > > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b84) > Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing) > > Thanks, > Vladimir > > > > This is the C1 code for sort2()'s loop: > > 0x0251c1dc: cmp 0x8(%ecx),%esi ; implicit exception: dispatches to 0x0251c21e > ;; 30 branch [AE] [RangeCheckStub: 0x454c640] [bci:13] > 0x0251c1df: jae 0x0251c24a > 0x0251c1e5: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; > ; - Test2::sort2 at 13 (line 23) > 0x0251c1e9: cmp 0x8(%ecx),%edi > ;; 36 branch [AE] [RangeCheckStub: 0x454c7e0] [bci:14] > 0x0251c1ec: jae 0x0251c263 > 0x0251c1f2: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; > ; - Test2::sort2 at 14 (line 23) > > (sort1/sort2 start to differ here) > > 0x0251c1f6: cmp 0x8(%ecx),%esi > ;; 42 branch [AE] [RangeCheckStub: 0x454c980] [bci:18] > 0x0251c1f9: jae 0x0251c27c > 0x0251c1ff: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less] = 0; > ; - Test2::sort2 at 18 (line 24) > 0x0251c207: inc %esi ; ++less; > 0x0251c208: inc %edi ; OopMap{ecx=Oop off=73} > ;*goto: for k++ > ; - Test2::sort2 at 25 (line 22) > 0x0251c209: test %eax,0x1a0100 ;*goto > ; - Test2::sort2 at 25 (line 22) > ; {poll} > ;; block B1 [4, 6] > > 0x0251c20f: cmp %edx,%edi > ;; 22 branch [LT] [B2] > 0x0251c211: jl 0x0251c1dc ;*if_icmpge: for k < right > ; - Test2::sort2 at 6 (line 22) > > The code looks OK; C1 doesn't do much optimization - no unrolling, bounds check elimination - but it's otherwise just about the code you would expect for a simple JITting. > Now, C1 code for sort1()'s loop: > > 0x024bc21c: cmp 0x8(%ecx),%esi ; implicit exception: dispatches to 0x024bc262 > ;; 30 branch [AE] [RangeCheckStub: 0x44ee3b0] [bci:13] > 0x024bc21f: jae 0x024bc28e > 0x024bc225: mov 0xc(%ecx,%esi,4),%ebx ;*iaload: %ebx = a[less]; > ; - Test1::sort1 at 13 (line 23) > 0x024bc229: cmp 0x8(%ecx),%edi > ;; 36 branch [AE] [RangeCheckStub: 0x44ee550] [bci:14] > 0x024bc22c: jae 0x024bc2a7 > 0x024bc232: mov %ebx,0xc(%ecx,%edi,4) ;*iastore: a[k] = %ebx; > ; - Test1::sort1 at 14 (line 23) > > (sort1/sort2 start to differ here) > > 0x024bc236: mov %esi,%ebx ; Crap! C1 temps 'less' into %ebx > 0x024bc238: inc %ebx ; ++less; (for the temp "less from future") > > 0x024bc239: cmp 0x8(%ecx),%esi ; %esi is still the "old less".... > ;; 46 branch [AE] [RangeCheckStub: 0x44ee7b8] [bci:21] > 0x024bc23c: jae 0x024bc2c0 > 0x024bc242: movl $0x0,0xc(%ecx,%esi,4) ;*iastore: a[less++] = 0; > ; - Test1::sort1 at 21 (line 24) > 0x024bc24a: inc %edi ; OopMap{ecx=Oop off=75} > ;*goto: for k++ > ; - Test1::sort1 at 25 (line 22) > 0x024bc24b: test %eax,0x1a0100 ; {poll} > 0x024bc251: mov %ebx,%esi ;*goto > ; - Test1::sort1 at 25 (line 22): for... > ;; block B1 [4, 6] > > 0x024bc253: cmp %edx,%edi > ;; 22 branch [LT] [B2] > 0x024bc255: jl 0x024bc21c ;*if_icmpge > ; - Test1::sort1 at 6 (line 22): for... > From jon.vanalten at redhat.com Wed Jul 7 15:00:19 2010 From: jon.vanalten at redhat.com (jon.vanalten at redhat.com) Date: Wed, 7 Jul 2010 11:00:19 -0400 (EDT) Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <547871786.2206761278514731259.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- "Martin Buchholz" wrote: > The JDK should find some other anti-inlining technique. > I would go one step further, and say that perhaps this anti-inlining is no longer necessary. I tried taking these methods out entirely and simply setting the in/out/err streams to null initially. This works. Probably due to some combination of 1) they are later on set from JNI code, and 2) JSR133, which among other things changed some rules about static final variables, notably: "Static final fields may only be modified in the class initializer that defines them, with the ex- ception of the java.lang.System.in, java.lang.System.out, and java.lang.System.err static fields, which can be modified by the java.lang.System.setIn, java.lang.System.setOut, and java.lang.System.setErr methods." I've attached a patch that (for me) has not caused any problems. Does anyone else have thoughts about this? cheers, jon > On Mon, Jun 28, 2010 at 07:14, wrote: > > Hello all, > > > > We've been having a discussion on the downstream IcedTea bugzilla > about a potential jdk bug, and it seems prudent to bring it up here. > ?Link: > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394 > > > > Please ignore discussion there RE 32-bit *nix time overflow in 2038; > this is a glibc issue that Java cannot resolve. ?What I am more > concerned about is the complete incompatibility with any negative > currentTimeMillis() return value. > > > > TL/DR: System class does a (currentTimeMillis() > 0) check as part > of method that only exists to avoid inlining of the initial null > assignment of the in/out/err streams. ?So, if system time is before > January 1, 1970, java will not start. ?The bug reporter has given > several potential use cases where this could occur (summary in comment > 14 of bug report). > > > > In my opinion, this is a bug. ?The comment preceding the methods in > which this check occurs indicate that it is only to prevent inlining; > Java should not, IMO, care whether the system clock is set to 2367CE, > 2010, or 42BCE. ?Provided, of course, that the date falls within the > 64 bit signed long value that the currentTimeMillis() method returns. > ?In other words, I think that Java should not be concerned with > whether the system clock is in sync with real world time. > > > > I've tried changing the check to (currentTimeMillis() >= > Long.MIN_VALUE), to maintain the prevention of inlining while allowing > startup to proceed. ?Patch attached. ?This seems to work, in that when > system clock is before 1970 a program can actually start up. ?There > does not seem to be unwanted side effects when running a few simple > programs, although I have not done any real regression testing. > > > > Is this something that others think should be fixed in the JDK? ?Or > are Java users ultimately required to ensure that their system clock > is set accurately (and they are not time travelling hehe)? > > > > Related: I've been looking through other use of currentTimeMillis() > throughout the JDK, and I've found a few other places where there seem > to be assumptions made about the approximate expected return value. > ?If others are of the same opinion that Java should be agnostic about > what a "sensible" system time should be, then I'll summarize my > findings in a future post. > > > > Your thoughts are appreciated. > > > > cheers, > > > > jon -------------- next part -------------- A non-text attachment was scrubbed... Name: system.patch Type: text/x-patch Size: 2148 bytes Desc: not available URL: From kelly.ohair at oracle.com Wed Jul 7 16:42:00 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 7 Jul 2010 09:42:00 -0700 Subject: Need reviewer: Fixes to some link issues in the javadoc comments Message-ID: Need a reviewer: 6967036: Need to fix links with // in Javadoc comments http://cr.openjdk.java.net/~ohair/openjdk7/links-6967036/webrev/ -kto From mandy.chung at oracle.com Wed Jul 7 17:14:35 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 07 Jul 2010 10:14:35 -0700 Subject: Need reviewer: Fixes to some link issues in the javadoc comments In-Reply-To: References: Message-ID: <4C34B5FB.9010706@oracle.com> Looks good to me. Mandy Kelly O'Hair wrote: > > Need a reviewer: > > 6967036: Need to fix links with // in Javadoc comments > http://cr.openjdk.java.net/~ohair/openjdk7/links-6967036/webrev/ > > -kto > From kelly.ohair at oracle.com Wed Jul 7 17:18:44 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Wed, 07 Jul 2010 17:18:44 +0000 Subject: hg: jdk7/tl/jdk: 6954517: Testcase failure tools/launcher/UnicodeTest.sh Message-ID: <20100707171905.4289B47805@hg.openjdk.java.net> Changeset: d6f8ffc3c54a Author: ohair Date: 2010-07-07 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6f8ffc3c54a 6954517: Testcase failure tools/launcher/UnicodeTest.sh Reviewed-by: ksrini ! test/tools/launcher/UnicodeTest.sh From martinrb at google.com Wed Jul 7 22:39:10 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Jul 2010 15:39:10 -0700 Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <762458204.1753351278003952199.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <744984656.1753281278003876288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <762458204.1753351278003952199.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: On Thu, Jul 1, 2010 at 10:05, wrote: > Hi Martin, > > Thanks for your input. > > ----- "Martin Buchholz" wrote: > >> It's not at all clear that one cannot solve the y2038 problem on >> systems with a 32-bit time_t. >> That's what Michael Schwern is trying to do here: >> http://code.google.com/p/y2038/ >> His code is available. >> > > Unfortunately unless I am missing something this example is not solving the y2038 problem for when a 32-bit system clock reaches overflow. ?See: > > http://code.google.com/p/y2038/wiki/HowItWorks > > It is simply allowing for representations of future times beyond 2038. ?Java already has this. The JDK appears to implement currentTimeMillis by simply calling gettimeofday and using the time_t values in that directly, without any additional cleverness. But I thought the whole point of the y2038 project is to provide the additional cleverness that you can conjure up a 64-bit time_t on a system that only has a 32-bit time_t. Martin From martinrb at google.com Wed Jul 7 23:09:37 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Jul 2010 16:09:37 -0700 Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <547871786.2206761278514731259.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: On Wed, Jul 7, 2010 at 08:00, wrote: > > ----- "Martin Buchholz" wrote: > > >> The JDK should find some other anti-inlining technique. >> > > I would go one step further, and say that perhaps this anti-inlining is no longer necessary. ?I tried taking these methods out entirely and simply setting the in/out/err streams to null initially. ?This works. ?Probably due to some combination of 1) they are later on set from JNI code, and 2) JSR133, which among other things changed some rules about static final variables, notably: > > "Static final fields may only be modified in the class initializer that defines them, with the ex- > ception of the java.lang.System.in, java.lang.System.out, and java.lang.System.err static > fields, which can be modified by the java.lang.System.setIn, java.lang.System.setOut, and > java.lang.System.setErr methods." That's a specification for what a JDK has to do. Perhaps the anti-inlining trick in System.java is one way that the Sun JDK tries to ensure that the JIT does not treat these fields as constant (although there is code in hotspot that is aware of the 3 special fields). > I've attached a patch that (for me) has not caused any problems. ?Does anyone else have thoughts about this? It seems hard to predict what the JVM will do under any circumstances. In particular, it's untestable. Martin From martinrb at google.com Wed Jul 7 23:33:04 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Jul 2010 16:33:04 -0700 Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <547871786.2206761278514731259.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: Hi Jon, Alan, Chris, Jon, I have a more conservative version of your patch, that uses blank finals, only calls currentTimeMillis once instead of 3 times, and only fails in the unlikely event of currentTimeMillis == Long.MIN_VALUE. I'm too afraid to remove the anti-inlining entirely. http://cr.openjdk.java.net/~martin/webrevs/openjdk7/TimeTravel/ Could someone at Oracle file a bug and provide review? Alan? Chris? Martin On Wed, Jul 7, 2010 at 08:00, wrote: > > ----- "Martin Buchholz" wrote: > > >> The JDK should find some other anti-inlining technique. >> > > I would go one step further, and say that perhaps this anti-inlining is no longer necessary. ?I tried taking these methods out entirely and simply setting the in/out/err streams to null initially. ?This works. ?Probably due to some combination of 1) they are later on set from JNI code, and 2) JSR133, which among other things changed some rules about static final variables, notably: > > "Static final fields may only be modified in the class initializer that defines them, with the ex- > ception of the java.lang.System.in, java.lang.System.out, and java.lang.System.err static > fields, which can be modified by the java.lang.System.setIn, java.lang.System.setOut, and > java.lang.System.setErr methods." > > I've attached a patch that (for me) has not caused any problems. ?Does anyone else have thoughts about this? > > cheers, > > jon > >> On Mon, Jun 28, 2010 at 07:14, ? wrote: >> > Hello all, >> > >> > We've been having a discussion on the downstream IcedTea bugzilla >> about a potential jdk bug, and it seems prudent to bring it up here. >> ?Link: >> > >> > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394 >> > >> > Please ignore discussion there RE 32-bit *nix time overflow in 2038; >> this is a glibc issue that Java cannot resolve. ?What I am more >> concerned about is the complete incompatibility with any negative >> currentTimeMillis() return value. >> > >> > TL/DR: System class does a (currentTimeMillis() > 0) check as part >> of method that only exists to avoid inlining of the initial null >> assignment of the in/out/err streams. ?So, if system time is before >> January 1, 1970, java will not start. ?The bug reporter has given >> several potential use cases where this could occur (summary in comment >> 14 of bug report). >> > >> > In my opinion, this is a bug. ?The comment preceding the methods in >> which this check occurs indicate that it is only to prevent inlining; >> Java should not, IMO, care whether the system clock is set to 2367CE, >> 2010, or 42BCE. ?Provided, of course, that the date falls within the >> 64 bit signed long value that the currentTimeMillis() method returns. >> ?In other words, I think that Java should not be concerned with >> whether the system clock is in sync with real world time. >> > >> > I've tried changing the check to (currentTimeMillis() >= >> Long.MIN_VALUE), to maintain the prevention of inlining while allowing >> startup to proceed. ?Patch attached. ?This seems to work, in that when >> system clock is before 1970 a program can actually start up. ?There >> does not seem to be unwanted side effects when running a few simple >> programs, although I have not done any real regression testing. >> > >> > Is this something that others think should be fixed in the JDK? ?Or >> are Java users ultimately required to ensure that their system clock >> is set accurately (and they are not time travelling hehe)? >> > >> > Related: I've been looking through other use of currentTimeMillis() >> throughout the JDK, and I've found a few other places where there seem >> to be assumptions made about the approximate expected return value. >> ?If others are of the same opinion that Java should be agnostic about >> what a "sensible" system time should be, then I'll summarize my >> findings in a future post. >> > >> > Your thoughts are appreciated. >> > >> > cheers, >> > >> > jon > From David.Holmes at oracle.com Thu Jul 8 01:08:19 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 11:08:19 +1000 Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: References: <547871786.2206761278514731259.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4C352503.3040909@oracle.com> I think there has been some confusion here. It seems to me that the anti-inlining that is being referred to is javac's "inlining" of compile-time constants - BUT that doesn't apply to reference types other than String, so it seems to me that the current code contortions serve no useful purpose and direct initialization to null could have been used. There is a second memory-model issue concerning these fields but basically that requires that no code gets compiled and caches the initial null values of these fields, prior to the setXX methods being called to initialize them correctly. I don't see how the use of the current code would change that one way or another though, so again the current code seems to serve no purpose. Did I miss something? David Holmes Martin Buchholz said the following on 07/08/10 09:33: > Hi Jon, Alan, Chris, > > Jon, I have a more conservative version of your patch, > that uses blank finals, only calls currentTimeMillis once instead of 3 times, > and only fails in the unlikely event of currentTimeMillis == Long.MIN_VALUE. > > I'm too afraid to remove the anti-inlining entirely. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/TimeTravel/ > > Could someone at Oracle file a bug and provide review? > Alan? Chris? > > Martin > > On Wed, Jul 7, 2010 at 08:00, wrote: >> ----- "Martin Buchholz" wrote: >> >> >>> The JDK should find some other anti-inlining technique. >>> >> I would go one step further, and say that perhaps this anti-inlining is no longer necessary. I tried taking these methods out entirely and simply setting the in/out/err streams to null initially. This works. Probably due to some combination of 1) they are later on set from JNI code, and 2) JSR133, which among other things changed some rules about static final variables, notably: >> >> "Static final fields may only be modified in the class initializer that defines them, with the ex- >> ception of the java.lang.System.in, java.lang.System.out, and java.lang.System.err static >> fields, which can be modified by the java.lang.System.setIn, java.lang.System.setOut, and >> java.lang.System.setErr methods." >> >> I've attached a patch that (for me) has not caused any problems. Does anyone else have thoughts about this? >> >> cheers, >> >> jon >> >>> On Mon, Jun 28, 2010 at 07:14, wrote: >>>> Hello all, >>>> >>>> We've been having a discussion on the downstream IcedTea bugzilla >>> about a potential jdk bug, and it seems prudent to bring it up here. >>> Link: >>>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394 >>>> >>>> Please ignore discussion there RE 32-bit *nix time overflow in 2038; >>> this is a glibc issue that Java cannot resolve. What I am more >>> concerned about is the complete incompatibility with any negative >>> currentTimeMillis() return value. >>>> TL/DR: System class does a (currentTimeMillis() > 0) check as part >>> of method that only exists to avoid inlining of the initial null >>> assignment of the in/out/err streams. So, if system time is before >>> January 1, 1970, java will not start. The bug reporter has given >>> several potential use cases where this could occur (summary in comment >>> 14 of bug report). >>>> In my opinion, this is a bug. The comment preceding the methods in >>> which this check occurs indicate that it is only to prevent inlining; >>> Java should not, IMO, care whether the system clock is set to 2367CE, >>> 2010, or 42BCE. Provided, of course, that the date falls within the >>> 64 bit signed long value that the currentTimeMillis() method returns. >>> In other words, I think that Java should not be concerned with >>> whether the system clock is in sync with real world time. >>>> I've tried changing the check to (currentTimeMillis() >= >>> Long.MIN_VALUE), to maintain the prevention of inlining while allowing >>> startup to proceed. Patch attached. This seems to work, in that when >>> system clock is before 1970 a program can actually start up. There >>> does not seem to be unwanted side effects when running a few simple >>> programs, although I have not done any real regression testing. >>>> Is this something that others think should be fixed in the JDK? Or >>> are Java users ultimately required to ensure that their system clock >>> is set accurately (and they are not time travelling hehe)? >>>> Related: I've been looking through other use of currentTimeMillis() >>> throughout the JDK, and I've found a few other places where there seem >>> to be assumptions made about the approximate expected return value. >>> If others are of the same opinion that Java should be agnostic about >>> what a "sensible" system time should be, then I'll summarize my >>> findings in a future post. >>>> Your thoughts are appreciated. >>>> >>>> cheers, >>>> >>>> jon From martinrb at google.com Thu Jul 8 05:38:02 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Jul 2010 22:38:02 -0700 Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <4C352503.3040909@oracle.com> References: <547871786.2206761278514731259.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <4C352503.3040909@oracle.com> Message-ID: On Wed, Jul 7, 2010 at 18:08, David Holmes wrote: > I think there has been some confusion here. It seems to me that the > anti-inlining that is being referred to is javac's "inlining" of > compile-time constants - BUT that doesn't apply to reference types other > than String, so it seems to me that the current code contortions serve no > useful purpose and direct initialization to null could have been used. I was actually afraid of what the VM would do, not javac. I freely admit to a bit of superstition. Surely there must have been a time when the anti-inlining was effective? Anyways, with two votes for making the code sane, I'll go along and simply initialize to null. http://cr.openjdk.java.net/~martin/webrevs/openjdk7/TimeTravel/ If there's a problem with setOut, we'll surely find out before this jdk goes into production. Martin > There is a second memory-model issue concerning these fields but basically > that requires that no code gets compiled and caches the initial null values > of these fields, prior to the setXX methods being called to initialize them > correctly. I don't see how the use of the current code would change that one > way or another though, so again the current code seems to serve no purpose. > > Did I miss something? > > David Holmes From David.Holmes at oracle.com Thu Jul 8 07:36:25 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 08 Jul 2010 17:36:25 +1000 Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: References: <547871786.2206761278514731259.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1664188027.2207121278514819921.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <4C352503.3040909@oracle.com> Message-ID: <4C357FF9.7050303@oracle.com> Hi Martin, Martin Buchholz said the following on 07/08/10 15:38: > On Wed, Jul 7, 2010 at 18:08, David Holmes wrote: >> I think there has been some confusion here. It seems to me that the >> anti-inlining that is being referred to is javac's "inlining" of >> compile-time constants - BUT that doesn't apply to reference types other >> than String, so it seems to me that the current code contortions serve no >> useful purpose and direct initialization to null could have been used. > > I was actually afraid of what the VM would do, not javac. I don't see how this impacts VM compilation - even if such compilation were to occur this early in the VM initialization process - but we should be able to test this easily enough - perhaps with -Xcomp > I freely admit to a bit of superstition. > Surely there must have been a time when the > anti-inlining was effective? This was very early code from late 1996 so perhaps then the rules for compile-time constants were not clear. The comment for this change simply states: "Initialize properties and streams in an explicit method in order to avoid doing I/O before the thread system is initialized." which seems unrelated to the coding changes in question. That said, given this is pre-hotspot perhaps early VMs did have an issue compiling this code during initialization. Certainly the code seems to be geared towards avoiding the inlining of the nullXXXStream methods themselves - with the currentTimeMillis() check being a non-trivial equivalent of "true" ? Though again I can't see how not-inlining, or inlining, those methods, would affect anything. > Anyways, with two votes for making the code sane, > I'll go along and simply initialize to null. > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/TimeTravel/ Looks okay to me, but this: Summary: Accept negative values of currentTimeMillis as valid should be more like: Summary: remove unnecessary check of currentTimeMillis I've filed 6967533 > If there's a problem with setOut, we'll surely find out before this jdk > goes into production. Let us hope so. As the old saying goes "never take down a fence without knowing why it was put up in the first place" ;-) Cheers, David > Martin > >> There is a second memory-model issue concerning these fields but basically >> that requires that no code gets compiled and caches the initial null values >> of these fields, prior to the setXX methods being called to initialize them >> correctly. I don't see how the use of the current code would change that one >> way or another though, so again the current code seems to serve no purpose. >> >> Did I miss something? >> >> David Holmes From jon.vanalten at redhat.com Thu Jul 8 13:16:25 2010 From: jon.vanalten at redhat.com (jon.vanalten at redhat.com) Date: Thu, 8 Jul 2010 09:16:25 -0400 (EDT) Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <1473853423.2342971278594817787.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1870161638.2347021278594985873.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- "Martin Buchholz" wrote: > On Thu, Jul 1, 2010 at 10:05, wrote: > > Hi Martin, > > > > Thanks for your input. > > > > ----- "Martin Buchholz" wrote: > > > >> It's not at all clear that one cannot solve the y2038 problem on > >> systems with a 32-bit time_t. > >> That's what Michael Schwern is trying to do here: > >> http://code.google.com/p/y2038/ > >> His code is available. > >> > > > > Unfortunately unless I am missing something this example is not > solving the y2038 problem for when a 32-bit system clock reaches > overflow. ?See: > > > > http://code.google.com/p/y2038/wiki/HowItWorks > > > > It is simply allowing for representations of future times beyond > 2038. ?Java already has this. > > The JDK appears to implement currentTimeMillis by simply calling > gettimeofday and using the time_t values in that directly, without > any > additional cleverness. But I thought the whole point of the y2038 > project is to provide the additional cleverness that you can conjure > up a 64-bit time_t on a system that only has a 32-bit time_t. > Err, perhaps I have been clear like mud. The functions targeted by y2038 are those that take a time value and break it down into a struct tm. They do not provide any tricks for retrieving the current system time. When I said that "Java already has this", I meant that within the Java libraries, the data types used already allow for representation of a wide range of dates. For example, with currentTimeMillis() returns a long, which (if we ignore any underlying implementation or host system issues) allows dates nearly 300 million years into the past or future. The Date/Calendar classes similarly can represent far past and far future dates. Definitely, both for currentTimeMillis() and for other internal use of gettimeofday(), Java is currently vulnerable to 32-bit system clock overflow. I've been looking at this and have some ideas for workarounds. More to follow in future post(s). cheers, jon From jon.vanalten at redhat.com Thu Jul 8 13:20:15 2010 From: jon.vanalten at redhat.com (Jon VanAlten) Date: Thu, 8 Jul 2010 09:20:15 -0400 (EDT) Subject: System.currentTimeMillis check in System class during startup. In-Reply-To: <4C357FF9.7050303@oracle.com> Message-ID: <1747050562.2350381278595215035.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi David and Martin, Thanks so much for your time (heh, punny) and thoughts, and for taking the ball and running with it. cheers, jon ----- "David Holmes" wrote: > Hi Martin, > > Martin Buchholz said the following on 07/08/10 15:38: > > On Wed, Jul 7, 2010 at 18:08, David Holmes > wrote: > >> I think there has been some confusion here. It seems to me that > the > >> anti-inlining that is being referred to is javac's "inlining" of > >> compile-time constants - BUT that doesn't apply to reference types > other > >> than String, so it seems to me that the current code contortions > serve no > >> useful purpose and direct initialization to null could have been > used. > > > > I was actually afraid of what the VM would do, not javac. > > I don't see how this impacts VM compilation - even if such compilation > > were to occur this early in the VM initialization process - but we > should be able to test this easily enough - perhaps with -Xcomp > > > I freely admit to a bit of superstition. > > Surely there must have been a time when the > > anti-inlining was effective? > > This was very early code from late 1996 so perhaps then the rules for > > compile-time constants were not clear. The comment for this change > simply states: > > "Initialize properties and streams in an explicit method in order to > avoid doing I/O before the thread system is initialized." > > which seems unrelated to the coding changes in question. That said, > given this is pre-hotspot perhaps early VMs did have an issue > compiling > this code during initialization. Certainly the code seems to be geared > > towards avoiding the inlining of the nullXXXStream methods themselves > - > with the currentTimeMillis() check being a non-trivial equivalent of > "true" ? Though again I can't see how not-inlining, or inlining, those > > methods, would affect anything. > > > Anyways, with two votes for making the code sane, > > I'll go along and simply initialize to null. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/TimeTravel/ > > Looks okay to me, but this: > > Summary: Accept negative values of currentTimeMillis as valid > > should be more like: > > Summary: remove unnecessary check of currentTimeMillis > > I've filed 6967533 > > > If there's a problem with setOut, we'll surely find out before this > jdk > > goes into production. > > Let us hope so. As the old saying goes "never take down a fence > without > knowing why it was put up in the first place" ;-) > > Cheers, > David > > > Martin > > > >> There is a second memory-model issue concerning these fields but > basically > >> that requires that no code gets compiled and caches the initial > null values > >> of these fields, prior to the setXX methods being called to > initialize them > >> correctly. I don't see how the use of the current code would change > that one > >> way or another though, so again the current code seems to serve no > purpose. > >> > >> Did I miss something? > >> > >> David Holmes From kumar.x.srinivasan at oracle.com Fri Jul 9 16:54:24 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 09 Jul 2010 16:54:24 +0000 Subject: hg: jdk7/tl/jdk: 6930056: (launcher) Need to remove or build as part of test these liblibrary.so files Message-ID: <20100709165439.08BD547879@hg.openjdk.java.net> Changeset: f13e94562d84 Author: ksrini Date: 2010-07-09 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f13e94562d84 6930056: (launcher) Need to remove or build as part of test these liblibrary.so files Reviewed-by: ohair, darcy - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so From mandy.chung at oracle.com Fri Jul 9 16:56:13 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 09 Jul 2010 09:56:13 -0700 Subject: Review request for 6926663: incremental modules build support In-Reply-To: <4C2E6E2D.7020905@oracle.com> References: <4C2E6E2D.7020905@oracle.com> Message-ID: <4C3754AD.6090107@oracle.com> Alan, Kelly, The webrevs are updated: http://cr.openjdk.java.net/~mchung/6926663/jdk-webrev.01/ http://cr.openjdk.java.net/~mchung/6926663/top-webrev.01/ You have seen most of the changes in the jigsaw-dev discussion. The main changes for the incremental build are as follows: 1. make/common/shared/Defs.gmk - added JDK_IMAGE_NAME and JRE_IMAGE_NAME variables (that are also used by the top forest repo) 2. make/modules/Makefile has the most significant change to support incremental build 3. make/common/Library.gmk, Defs.gmk - call TouchModule (defined in Defs-modules.gmk) to record if non-class file is updated. 4. ClassAnalyzer - moved from make/modules/tools to make/tools/classanalyzer to separate from make/modules/Makefile so that the tool is built once (if no change is made). - take a properties file to specify properties of the output modules as well as the names of a few platform well-known modules 5. make/modules/modules.properties - specify the properties for jdk modules e.g. name of the boot and base module Kelly, Alan is going to do a detailed review of the class analyzer tool when he returns from vacation next week. Can you help review other makefile changes? Thanks Mandy Mandy Chung wrote: > Alan, Kelly, > > Webrev: > http://cr.openjdk.java.net/~mchung/6926663 > > It in fact contains 2 fixes: > 1. integrate the latest jdk modularity fixes from jigsaw repos > - add modules target in the top forest makefile [1] > - support SKIP_BOOT_CYCLE=false modules build [2] > - fix a couple of bugs in the launcher [3] > - add JDK_HOST_PATH to support cross-architectural modules build [4] > - cleanup on the modules.config and module names in makefiles > > 2. incremental modules build support to ease jdk development > - the changes are mainly in make/modules and > make/tools/classanalyzer files. > > The modules build includes two main steps: > a. run the class analyzer tool to assign classes and resources in > the jdk modules and analyzes their dependencies > b. modularize the build output and create a module library > containing the jdk modules > > I created a new tool com.sun.classanalyzer.Modularizer to do the files > copying in step 2. Both ClassAnalyzer and Modularizer will process > classes/resources files that are updated since the previous build. > The jdk build will update a new file submodules/.modules.update if > classes are recompiled, a library is rebuilt, or a file is installed > in the jdk. The modules build will use the timestamp of > .modules.update file to determine if it should do an incremental or do > a full modules build. > > Thanks > Mandy > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000742.html > [2] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000613.html > [3] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000523.html > > [4] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-March/000683.html From pawel.veselov at gmail.com Fri Jul 9 17:32:43 2010 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Fri, 9 Jul 2010 10:32:43 -0700 Subject: Timer death Message-ID: Greetings, After debugging an issue in one of my projects, I've realized that the problem was that a timer task simply died because VM was out of memory. The fact that I catch any Throwable around the code that threw the OOM error didn't particularly help. The error was logged, but the timer thread still died. Well, may be it didn't die at this point, I do see the exception handling code executed (it logged something else from the catch{} block as well), and I really hope (don't believe) that a thread would die when normal exception handling was executed and the exception wasn't re-thrown upstream. But, I'm not here to ramble about particulates about my specific situations. When I started thinking about how do I detect this somehow, I also realized that it's not normally possible to determine if any specific timer is alive or not. I see two ways to determine that: a) Schedule a single empty task on a timer. If you get back an IllegalStateException, then the timer thread is gone (the code suggests if the thread leaves the main loop for any reason, any scheduling will cause IllegalStateException). b) When the timer is created, schedule a single task, and determine the timer thread during the task execution (current thread), and then check whether the thread is running or not. Now, both of those are hacky, "a" schedules a task for no reason, and "b" will stop working if timer implementation becomes capable of scheduling tasks on multiple threads for whatever load-balancing reasons. I would suggest adding a method to either retrieve a timer thread (sort of bad, because this will make the timer implementation to always use a single thread), or simply a method that tells whether the timer is alive or not (whether this would now translate into whether the thread is alive or not), so the program can attempt to recover (or take any other action, like shooting itself) if the timer stopped working. My overall issue with this (I know, kind of late to realize this now), is that it's really hard to recover from OOMs, or even detect that they are happening, and all of the sudden your application threads start to simply disappear, and you need yet another thread that would go check they are alive and take some action (and who is to say that thread won't die as well, and you won't notice that either). java.lang.OutOfMemoryError: Java heap space at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at com.mysql.jdbc.Util.handleNewInstance(Util.java:409) at com.mysql.jdbc.ResultSetImpl.getInstance(ResultSetImpl.java:382) at com.mysql.jdbc.MysqlIO.buildResultSetWithRows(MysqlIO.java:2604) at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:487) at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2582) at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1758) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2172) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2690) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2619) at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1465) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) Thanks, Pawel. From ariel at weisberg.ws Fri Jul 9 17:44:20 2010 From: ariel at weisberg.ws (Ariel Weisberg) Date: Fri, 09 Jul 2010 13:44:20 -0400 Subject: Timer death In-Reply-To: References: Message-ID: <1278697460.15095.1384108765@webmail.messagingengine.com> Hi Pawel, You have pointed out a number of known issues with Timer. The class is not deprecated, but there is a much improved version available in java.util.concurrent.ScheduledThreadPoolExecutor (http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/). That too has its owns quirks when tasks leak Exceptions, but it is still an improvement. You should read the STPE specific javadoc for the various execute/submit/schedule methods carefully and make sure to extend STPE in order to implement java.util.concurrent.ThreadPoolExecutor.afterExecute() (and see the javadoc for that method for some more magic) in order to make sure you can catch and handle exceptions thrown by tasks. It's interesting that the javadoc for Timer doesn't mention STPE. Might be a worthwhile enhancement. Hope this helps, Ariel Weisberg On Fri, 09 Jul 2010 10:32 -0700, "Pawel Veselov" wrote: > Greetings, > > After debugging an issue in one of my projects, I've realized that the > problem was that a timer task simply died because VM was out of > memory. > The fact that I catch any Throwable around the code that threw the OOM > error didn't particularly help. The error was logged, but the timer > thread still died. > Well, may be it didn't die at this point, I do see the exception > handling code executed (it logged something else from the catch{} > block as well), and I really hope (don't believe) that a thread would > die when normal exception handling was executed and the exception > wasn't re-thrown upstream. > > But, I'm not here to ramble about particulates about my specific > situations. When I started thinking about how do I detect this > somehow, I also realized that it's not normally possible to determine > if any specific timer is alive or not. I see two ways to determine > that: > > a) Schedule a single empty task on a timer. If you get back an > IllegalStateException, then the timer thread is gone (the code > suggests if the thread leaves the main loop for any reason, any > scheduling will cause IllegalStateException). > b) When the timer is created, schedule a single task, and determine > the timer thread during the task execution (current thread), and then > check whether the thread is running or not. > > Now, both of those are hacky, "a" schedules a task for no reason, and > "b" will stop working if timer implementation becomes capable of > scheduling tasks on multiple threads for whatever load-balancing > reasons. > > I would suggest adding a method to either retrieve a timer thread > (sort of bad, because this will make the timer implementation to > always use a single thread), or simply a method that tells whether the > timer is alive or not (whether this would now translate into whether > the thread is alive or not), so the program can attempt to recover (or > take any other action, like shooting itself) if the timer stopped > working. > > My overall issue with this (I know, kind of late to realize this now), > is that it's really hard to recover from OOMs, or even detect that > they are happening, and all of the sudden your application threads > start to simply disappear, and you need yet another thread that would > go check they are alive and take some action (and who is to say that > thread won't die as well, and you won't notice that either). > > java.lang.OutOfMemoryError: Java heap space > at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:409) > at com.mysql.jdbc.ResultSetImpl.getInstance(ResultSetImpl.java:382) > at com.mysql.jdbc.MysqlIO.buildResultSetWithRows(MysqlIO.java:2604) > at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:487) > at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2582) > at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1758) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2172) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2690) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2619) > at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1465) > > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > > > Thanks, > Pawel. > From ariel at weisberg.ws Fri Jul 9 17:55:26 2010 From: ariel at weisberg.ws (Ariel Weisberg) Date: Fri, 09 Jul 2010 13:55:26 -0400 Subject: Timer death In-Reply-To: References: Message-ID: <1278698126.18754.1384108969@webmail.messagingengine.com> Hi Pawel, One last thing I forgot to mention. I don't consider OOME to be recoverable (hence it extends Error) although some do. The best you can hope to do is log that it occurred and possibly limit the corruption to persistent or foreign state that can occur before the JVM exits. If an OOM occurs in one thread it might have occurred in another (one not necessarily managed by your application) at a point that is not exception safe. http://stackoverflow.com/questions/2679330/catching-java-lang-outofmemoryerror Regards, Ariel Weisberg On Fri, 09 Jul 2010 10:32 -0700, "Pawel Veselov" wrote: > Greetings, > > After debugging an issue in one of my projects, I've realized that the > problem was that a timer task simply died because VM was out of > memory. > The fact that I catch any Throwable around the code that threw the OOM > error didn't particularly help. The error was logged, but the timer > thread still died. > Well, may be it didn't die at this point, I do see the exception > handling code executed (it logged something else from the catch{} > block as well), and I really hope (don't believe) that a thread would > die when normal exception handling was executed and the exception > wasn't re-thrown upstream. > > But, I'm not here to ramble about particulates about my specific > situations. When I started thinking about how do I detect this > somehow, I also realized that it's not normally possible to determine > if any specific timer is alive or not. I see two ways to determine > that: > > a) Schedule a single empty task on a timer. If you get back an > IllegalStateException, then the timer thread is gone (the code > suggests if the thread leaves the main loop for any reason, any > scheduling will cause IllegalStateException). > b) When the timer is created, schedule a single task, and determine > the timer thread during the task execution (current thread), and then > check whether the thread is running or not. > > Now, both of those are hacky, "a" schedules a task for no reason, and > "b" will stop working if timer implementation becomes capable of > scheduling tasks on multiple threads for whatever load-balancing > reasons. > > I would suggest adding a method to either retrieve a timer thread > (sort of bad, because this will make the timer implementation to > always use a single thread), or simply a method that tells whether the > timer is alive or not (whether this would now translate into whether > the thread is alive or not), so the program can attempt to recover (or > take any other action, like shooting itself) if the timer stopped > working. > > My overall issue with this (I know, kind of late to realize this now), > is that it's really hard to recover from OOMs, or even detect that > they are happening, and all of the sudden your application threads > start to simply disappear, and you need yet another thread that would > go check they are alive and take some action (and who is to say that > thread won't die as well, and you won't notice that either). > > java.lang.OutOfMemoryError: Java heap space > at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:409) > at com.mysql.jdbc.ResultSetImpl.getInstance(ResultSetImpl.java:382) > at com.mysql.jdbc.MysqlIO.buildResultSetWithRows(MysqlIO.java:2604) > at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:487) > at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2582) > at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1758) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2172) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2690) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2619) > at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1465) > > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > > > Thanks, > Pawel. > From martinrb at google.com Sat Jul 10 02:25:36 2010 From: martinrb at google.com (martinrb at google.com) Date: Sat, 10 Jul 2010 02:25:36 +0000 Subject: hg: jdk7/tl/jdk: 6967533: Epoch bug: ExceptionInInitializerError on systems with uninitialized clock Message-ID: <20100710022555.0036F47894@hg.openjdk.java.net> Changeset: da8526047e5f Author: martin Date: 2010-07-09 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da8526047e5f 6967533: Epoch bug: ExceptionInInitializerError on systems with uninitialized clock Summary: Remove (hopefully!) unnecessary check of currentTimeMillis Reviewed-by: dholmes Contributed-by: Jon VanAlten ! src/share/classes/java/lang/System.java From dl at cs.oswego.edu Sat Jul 10 13:35:31 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 10 Jul 2010 09:35:31 -0400 Subject: Thread.getState() very slow Message-ID: <4C387723.2070407@cs.oswego.edu> I've been trying out some improvements in ForkJoin that involve repeatedly scanning threads to check whether they are still in state Thread.State.RUNNABLE. This is shockingly slow because getState() is implemented using a lookup table that requires a global lock (to ensure initialization) plus boxing to do the lookup. Practically any other implementation would be faster. For example, simply scanning the small static array of sun.misc.VM.getThreadStateValues. And surely there are better ways. Is anyone looking into this? Or alternatively, is there a faster way to check that internal field Thread.threadStatus has the value mapping to RUNNABLE? If not, I might try contributing a patch. -Doug From David.Holmes at oracle.com Sun Jul 11 04:09:47 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 11 Jul 2010 14:09:47 +1000 Subject: Thread.getState() very slow In-Reply-To: <4C387723.2070407@cs.oswego.edu> References: <4C387723.2070407@cs.oswego.edu> Message-ID: <4C39440B.5070501@oracle.com> Hi Doug, Doug Lea said the following on 07/10/10 23:35: > I've been trying out some improvements in ForkJoin > that involve repeatedly scanning threads to check > whether they are still in state Thread.State.RUNNABLE. My question is why you want to check for Runnable? Is this a heuristic check to see that the thread is not blocked? Only basic monitor related blocking will update the thread state. Is that enough for what you want? Not to mention the inherent race in doing the check. > This is shockingly slow because getState() is implemented > using a lookup table that requires a global lock > (to ensure initialization) plus boxing to do the lookup. We can easily fix the lock issue with a DCL check and making the main map volatile. (Or simply skip lazy initialization as I would think this is always used!) Is the boxing really an issue? Due to the values used there should not be any object creation - right? That said the set of states is small enough that two arrays could easily be used instead of the maps. > Practically any other implementation would be faster. > For example, simply scanning the small static array of > sun.misc.VM.getThreadStateValues. And surely there are > better ways. > > Is anyone looking into this? I don't see any CRs related to this so I would not expect anyone to be looking at it ... until now of course :) > Or alternatively, is there a faster way to check that > internal field Thread.threadStatus has the value mapping > to RUNNABLE? Can you use Unsafe to grab the field directly, or would the reflection make it too slow? Cheers, David > If not, I might try contributing a patch. > > -Doug > From dl at cs.oswego.edu Sun Jul 11 11:20:01 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 11 Jul 2010 07:20:01 -0400 Subject: Thread.getState() very slow In-Reply-To: <4C39440B.5070501@oracle.com> References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com> Message-ID: <4C39A8E1.4050502@cs.oswego.edu> On 07/11/10 00:09, David Holmes wrote: > Doug Lea said the following on 07/10/10 23:35: >> I've been trying out some improvements in ForkJoin >> that involve repeatedly scanning threads to check >> whether they are still in state Thread.State.RUNNABLE. > > My question is why you want to check for Runnable? Is this a heuristic check to > see that the thread is not blocked? Only basic monitor related blocking will > update the thread state. Is that enough for what you want? It's one part of a starvation detector for which it is OK to be wrong conservatively. For some of the motivation, see the concurrency-interest post http://cs.oswego.edu/pipermail/concurrency-interest/2010-July/007251.html > > That said the set of states is small enough that two arrays could easily be used > instead of the maps. Or, depending on the range of values of Thread.threadStatus, bit maps might work, and would avoid traversal. Also, while I'm at it, field Thread.threadStatus is suspiciously not declared volatile. > >> Or alternatively, is there a faster way to check that >> internal field Thread.threadStatus has the value mapping >> to RUNNABLE? > > Can you use Unsafe to grab the field directly, or would the reflection make it > too slow? > That's what I'm currently doing as a sleazy workaround. The sleaziness is not the Unsafe, which is basically fine since this is planned for JDK code, but having to guess at startup that the first value I get must be the one associated with RUNNABLE. -Doug From David.Holmes at oracle.com Sun Jul 11 22:20:32 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 12 Jul 2010 08:20:32 +1000 Subject: Thread.getState() very slow In-Reply-To: <4C39A8E1.4050502@cs.oswego.edu> References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com> <4C39A8E1.4050502@cs.oswego.edu> Message-ID: <4C3A43B0.8010200@oracle.com> Hi Doug, Doug Lea said the following on 07/11/10 21:20: > Also, while I'm at it, field Thread.threadStatus is suspiciously not > declared volatile. Agreed - technically this should be a volatile field. In practice I think it only means that the window in which a stale value might be seen is slightly longer. If threadStatus were exported directly it might be more of an issue, but as an internal detail of getState() it is not likely to be. >> Can you use Unsafe to grab the field directly, or would the reflection >> make it too slow? >> > > That's what I'm currently doing as a sleazy workaround. > The sleaziness is not the Unsafe, which is basically fine > since this is planned for JDK code, but having to guess at startup > that the first value I get must be the one associated with RUNNABLE. I thought this would be fairly simple but looking deeper into this it is a lot more complicated than I thought. There is a three-level mapping from: OS/VM thread state -> VM ThreadStatus -> java.lang.ThreadState and it is a M:N:1 mapping At least a startup you should be able to get the current thread's threadStatus and know that it represents RUNNABLE. In addition I suspect the lazy initialization may be more necessary than I thought given the time at which this initialization might occur during the VM initialization sequence. I'd have to experiment (once I've remembered how to build regular SE Hotspot and the OpenJDK libs :) ) Some input from the original implementors would be useful (Martin? Mandy? ...) That all said, you are the best person to evaluate the performance impact of any changes so it might be best if you are the one to do the initial experiments - using a simple volatile + DCL for the init as a first attempt perhaps. David > > -Doug > From martinrb at google.com Mon Jul 12 02:02:23 2010 From: martinrb at google.com (Martin Buchholz) Date: Sun, 11 Jul 2010 19:02:23 -0700 Subject: Thread.getState() very slow In-Reply-To: <4C3A43B0.8010200@oracle.com> References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com> <4C39A8E1.4050502@cs.oswego.edu> <4C3A43B0.8010200@oracle.com> Message-ID: On Sun, Jul 11, 2010 at 15:20, David Holmes wrote: > I thought this would be fairly simple but looking deeper into this it is a > lot more complicated than I thought. There is a three-level mapping from: > > OS/VM thread state -> VM ThreadStatus -> java.lang.ThreadState > > and it is a M:N:1 mapping I'm surprised by this as well. I had also assumed that Thread.getState would be cheap, and simple. > Some input from the original implementors would be useful (Martin? Mandy? I don't know anything about the implementation of Thread.getState. Mandy? Martin From mandy.chung at oracle.com Mon Jul 12 07:44:03 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Jul 2010 00:44:03 -0700 Subject: Thread.getState() very slow In-Reply-To: References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com> <4C39A8E1.4050502@cs.oswego.edu> <4C3A43B0.8010200@oracle.com> Message-ID: <4C3AC7C3.9060900@oracle.com> Martin Buchholz wrote: >> Some input from the original implementors would be useful (Martin? Mandy? >> > > I don't know anything about the implementation of Thread.getState. Mandy? > > > I'm on vacation and will return on Thurs. We didn't do much optimization in the implementation. It has been a while and I need to look at the implementation to comment on it further (will do that when I return from vacation). Mandy From Alan.Bateman at oracle.com Mon Jul 12 09:02:12 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Jul 2010 10:02:12 +0100 Subject: Thread.getState() very slow In-Reply-To: References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com> <4C39A8E1.4050502@cs.oswego.edu> <4C3A43B0.8010200@oracle.com> Message-ID: <4C3ADA14.4020003@oracle.com> Martin Buchholz wrote: > : > I don't know anything about the implementation of Thread.getState. Mandy? > Mandy is on vacation at the moment so we might not hear from her for a few days. Looking through the history, the implementation doesn't seem to have changed since 2004. It does appear that the original implementation had a small startup impact and that this was addressed by 5026930 leading to the current implementation. Clearly it needs to be re-examined now. I couldn't find any existing bugs but as it was added for M&M usage, then it's possible that it's not widely used and so the performance issue just hasn't been noticed. -Alan. From chris.hegarty at oracle.com Mon Jul 12 17:19:31 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 12 Jul 2010 17:19:31 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100712172028.D9D334792A@hg.openjdk.java.net> Changeset: a7f8f269f741 Author: chegar Date: 2010-07-12 18:13 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a7f8f269f741 6967937: Scope id no longer being set after 6931566 Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c ! test/java/net/Inet6Address/B6214234.java Changeset: 1371a2d5f3a8 Author: chegar Date: 2010-07-12 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1371a2d5f3a8 6967684: httpserver using a non thread-safe SimpleDateFormat Reviewed-by: michaelm ! src/share/classes/sun/net/httpserver/ExchangeImpl.java Changeset: bb0b32ffefe9 Author: chegar Date: 2010-07-12 18:18 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bb0b32ffefe9 6966846: Incorrect assertion in java.net.Inet6Address.readObject Reviewed-by: michaelm ! src/share/classes/java/net/Inet6Address.java From kumar.x.srinivasan at oracle.com Mon Jul 12 22:37:45 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 12 Jul 2010 22:37:45 +0000 Subject: hg: jdk7/tl/jdk: 6921472: RFE: java launcher code needs clean up Message-ID: <20100712223755.DE00747937@hg.openjdk.java.net> Changeset: d3fa95d0710c Author: ksrini Date: 2010-07-09 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3fa95d0710c 6921472: RFE: java launcher code needs clean up Summary: This changeset also contains fixes for 6405284, 6753938 and 6922500 Reviewed-by: darcy ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java From daniel.daugherty at oracle.com Mon Jul 12 22:52:42 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 12 Jul 2010 22:52:42 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100712225301.AA47C47939@hg.openjdk.java.net> Changeset: ddf825161d2d Author: dcubed Date: 2010-07-12 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ddf825161d2d 6968401: 3/3 disable tests added by 6942989 until 6964018 is fixed Summary: Disable AnonLoggerWeakRefLeak.sh and LoggerWeakRefLeak.sh Reviewed-by: ohair ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 4e365ef6576d Author: dcubed Date: 2010-07-12 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e365ef6576d Merge From jonathan.gibbons at oracle.com Mon Jul 12 23:38:23 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 12 Jul 2010 23:38:23 +0000 Subject: hg: jdk7/tl/langtools: 6968497: localized text appears in raw diagnostic Message-ID: <20100712233826.BAF114793B@hg.openjdk.java.net> Changeset: 064468702a8d Author: jjg Date: 2010-07-12 16:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/064468702a8d 6968497: localized text appears in raw diagnostic Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/generics/6946618/T6946618c.java ! test/tools/javac/generics/6946618/T6946618c.out From dmitry.samersoff at sun.com Tue Jul 13 11:36:55 2010 From: dmitry.samersoff at sun.com (dmitry.samersoff at sun.com) Date: Tue, 13 Jul 2010 11:36:55 +0000 Subject: hg: jdk7/tl/jdk: 6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if java.net.preferIPvStack property set Message-ID: <20100713113711.343AB47956@hg.openjdk.java.net> Changeset: 25050030a320 Author: dsamersoff Date: 2010-07-13 15:32 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25050030a320 6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if java.net.preferIPvStack property set Summary: User can disable ipv6 explicitly, have to check it Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c + test/java/net/NetworkInterface/IPv4Only.java From weijun.wang at sun.com Tue Jul 13 12:27:38 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 13 Jul 2010 12:27:38 +0000 Subject: hg: jdk7/tl/jdk: 6670889: Keystore created under Hindi Locale causing ArrayIndexOutOfBoundsException Message-ID: <20100713122748.2DCF547958@hg.openjdk.java.net> Changeset: f3a4c1947fd1 Author: weijun Date: 2010-07-13 20:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f3a4c1947fd1 6670889: Keystore created under Hindi Locale causing ArrayIndexOutOfBoundsException Reviewed-by: chegar ! src/share/classes/sun/security/util/DerOutputStream.java + test/sun/security/util/DerOutputStream/LocaleInTime.java From kasperni at gmail.com Tue Jul 13 17:13:31 2010 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 13 Jul 2010 19:13:31 +0200 Subject: HashMap bug for large map sizes Message-ID: <4C3C9EBB.9070902@gmail.com> Hi, I don't know if this has been discussed before. But I was looking at the HashMap implementation today and noticed that there are some issues with very large sized hashmaps with more then Integer.MAX_VALUE elements. 1. The Map contract says that "If the map contains more than Integer.MAX_VALUE elements, returns Integer.MAX_VALUE." The current implementation will just wrap around and return negative numbers when you add elements (size++). 2. If the size of a HashMap has wrapped around and returns negative size you cannot deserialize it. Because of this loop in readObject for (int i=0; iInteger.MAX_VALUE we would write s.writeInt(Integer.MAX_VALUE); for (int i=0;i References: <4C3C9EBB.9070902@gmail.com> Message-ID: <4C3CA6C8.5090905@oracle.com> On 13/07/2010 18:13, Kasper Nielsen wrote: > s.writeInt(Integer.MAX_VALUE); > > for (int i=0;i > } > > s.writeLong(size);//write the real size > > for (long i=Integer.MAX_VALUE;i ...read remaining elements > } Adding a field to the serial form would probably be better. Tom From jonathan.gibbons at oracle.com Wed Jul 14 02:14:41 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Jul 2010 02:14:41 +0000 Subject: hg: jdk7/tl/langtools: 6966732: replace use of static Log.getLocalizedString with non-static alternative where possible Message-ID: <20100714021442.CA9D247978@hg.openjdk.java.net> Changeset: a5454419dd46 Author: jjg Date: 2010-07-13 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a5454419dd46 6966732: replace use of static Log.getLocalizedString with non-static alternative where possible Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java From jonathan.gibbons at oracle.com Wed Jul 14 02:18:15 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Jul 2010 02:18:15 +0000 Subject: hg: jdk7/tl/langtools: 6968434: test CheckResourceKeys fails on control builds Message-ID: <20100714021816.EDD5B47979@hg.openjdk.java.net> Changeset: 0e1fab5cffc8 Author: jjg Date: 2010-07-13 19:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0e1fab5cffc8 6968434: test CheckResourceKeys fails on control builds Reviewed-by: darcy ! test/tools/javac/diags/CheckResourceKeys.java From jonathan.gibbons at oracle.com Wed Jul 14 02:21:30 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Jul 2010 02:21:30 +0000 Subject: hg: jdk7/tl/langtools: 6968789: incorrect text in "diamond not supported" message Message-ID: <20100714022131.C8DAA4797A@hg.openjdk.java.net> Changeset: e57b27703e8b Author: jjg Date: 2010-07-13 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e57b27703e8b 6968789: incorrect text in "diamond not supported" message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/resources/compiler.properties From fweimer at bfk.de Wed Jul 14 13:25:05 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 14 Jul 2010 13:25:05 +0000 Subject: Timer death In-Reply-To: (Pawel Veselov's message of "Fri\, 9 Jul 2010 10\:32\:43 -0700") References: Message-ID: <824og2p55a.fsf@mid.bfk.de> * Pawel Veselov: > The fact that I catch any Throwable around the code that threw the > OOM error didn't particularly help. The error was logged, but the > timer thread still died. By definition, a VM which throws an Error (or even VirtualMachineError) is unstable and needs to be restarted. The description of VirtualMachineError makes that pretty clear. You cannot even know that the thread that triggers such exceptions is responsible for their actual cause. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pawel.veselov at gmail.com Wed Jul 14 15:08:17 2010 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Wed, 14 Jul 2010 08:08:17 -0700 Subject: Timer death In-Reply-To: <824og2p55a.fsf@mid.bfk.de> References: <824og2p55a.fsf@mid.bfk.de> Message-ID: On Wed, Jul 14, 2010 at 6:25 AM, Florian Weimer wrote: > * Pawel Veselov: > > > The fact that I catch any Throwable around the code that threw the > > OOM error didn't particularly help. The error was logged, but the > > timer thread still died. > > By definition, a VM which throws an Error (or even > VirtualMachineError) is unstable and needs to be restarted. The > description of VirtualMachineError makes that pretty clear. You > cannot even know that the thread that triggers such exceptions is > responsible for their actual cause. > Considering the fact that its probably unreasonable to ask the user code to catch the VME everywhere, or that VME may not even reach the user code, should we have something like -XX:DieOnVME= ? Or global VM VME handler that has certain amount of pre-reserved memory, which gets executed before VM terminates, and can be configured? Thanks, Pawel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.arrenbrecht at gmail.com Wed Jul 14 15:38:54 2010 From: peter.arrenbrecht at gmail.com (Peter Arrenbrecht) Date: Wed, 14 Jul 2010 17:38:54 +0200 Subject: JavaDoc for Closeable.close() still a copy of Stream.close()? Message-ID: See http://hg.openjdk.java.net/jdk7/modules/jdk/file/tip/src/share/classes/java/io/Closeable.java and compare http://developer.android.com/reference/java/io/Closeable.html#close() Cheers, -parren From Alan.Bateman at oracle.com Wed Jul 14 15:54:29 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Jul 2010 16:54:29 +0100 Subject: JavaDoc for Closeable.close() still a copy of Stream.close()? In-Reply-To: References: Message-ID: <4C3DDDB5.8010601@oracle.com> Peter Arrenbrecht wrote: > See > > http://hg.openjdk.java.net/jdk7/modules/jdk/file/tip/src/share/classes/java/io/Closeable.java > > and compare > > http://developer.android.com/reference/java/io/Closeable.html#close() > > > Cheers, > -parren > The master forest is jdk7/jdk7 (I think jdk7/modules was the forest for jsr277, not sure, but it hasn't been sync'ed in a long time). In any case, I think this is what you are looking for: http://hg.openjdk.java.net/jdk7/tl/jdk/file/tip/src/share/classes/java/io/Closeable.java and it should be some future promoted build (probably jdk7-b103). -Alan. From kumar.x.srinivasan at oracle.COM Wed Jul 14 17:23:04 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 14 Jul 2010 10:23:04 -0700 Subject: JavaDoc for Closeable.close() still a copy of Stream.close()? In-Reply-To: <4C3DDDB5.8010601@oracle.com> References: <4C3DDDB5.8010601@oracle.com> Message-ID: <4C3DF278.1090204@oracle.COM> On 7/14/2010 8:54 AM, Alan Bateman wrote: > Peter Arrenbrecht wrote: >> See >> >> http://hg.openjdk.java.net/jdk7/modules/jdk/file/tip/src/share/classes/java/io/Closeable.java >> >> >> and compare >> >> http://developer.android.com/reference/java/io/Closeable.html#close() >> >> >> Cheers, >> -parren > The master forest is jdk7/jdk7 (I think jdk7/modules was the forest > for jsr277, not sure, but it hasn't been sync'ed in a long time). Correct used for JSR-277, now this is defunct. Kumar > > In any case, I think this is what you are looking for: > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/tip/src/share/classes/java/io/Closeable.java > > > and it should be some future promoted build (probably jdk7-b103). > > -Alan. > > > > From David.Holmes at oracle.com Wed Jul 14 23:20:00 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 15 Jul 2010 09:20:00 +1000 Subject: Timer death In-Reply-To: <824og2p55a.fsf@mid.bfk.de> References: <824og2p55a.fsf@mid.bfk.de> Message-ID: <4C3E4620.3000003@oracle.com> Florian Weimer said the following on 07/14/10 23:25: > * Pawel Veselov: > >> The fact that I catch any Throwable around the code that threw the >> OOM error didn't particularly help. The error was logged, but the >> timer thread still died. > > By definition, a VM which throws an Error (or even > VirtualMachineError) is unstable and needs to be restarted. The > description of VirtualMachineError makes that pretty clear. You > cannot even know that the thread that triggers such exceptions is > responsible for their actual cause. An OutOfMemoryError for the Java heap does not fall into that category. OOM is a transient failure in many circumstances. David Holmes From David.Holmes at oracle.com Wed Jul 14 23:22:30 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 15 Jul 2010 09:22:30 +1000 Subject: Timer death In-Reply-To: References: Message-ID: <4C3E46B6.2070204@oracle.com> Pawel Veselov said the following on 07/10/10 03:32: > After debugging an issue in one of my projects, I've realized that the > problem was that a timer task simply died because VM was out of > memory. > The fact that I catch any Throwable around the code that threw the OOM > error didn't particularly help. The error was logged, but the timer > thread still died. If you caught the exception and continued with your code then the timer didn't die. If you caught the exception and your code completed then the timer thread may have encountered a secondary exception while performing its internal actions - which means the timer thread would then die. As Ariel stated look at ScheduledThreadPoolExecutor instead. David Holmes > Well, may be it didn't die at this point, I do see the exception > handling code executed (it logged something else from the catch{} > block as well), and I really hope (don't believe) that a thread would > die when normal exception handling was executed and the exception > wasn't re-thrown upstream. > > But, I'm not here to ramble about particulates about my specific > situations. When I started thinking about how do I detect this > somehow, I also realized that it's not normally possible to determine > if any specific timer is alive or not. I see two ways to determine > that: > > a) Schedule a single empty task on a timer. If you get back an > IllegalStateException, then the timer thread is gone (the code > suggests if the thread leaves the main loop for any reason, any > scheduling will cause IllegalStateException). > b) When the timer is created, schedule a single task, and determine > the timer thread during the task execution (current thread), and then > check whether the thread is running or not. > > Now, both of those are hacky, "a" schedules a task for no reason, and > "b" will stop working if timer implementation becomes capable of > scheduling tasks on multiple threads for whatever load-balancing > reasons. > > I would suggest adding a method to either retrieve a timer thread > (sort of bad, because this will make the timer implementation to > always use a single thread), or simply a method that tells whether the > timer is alive or not (whether this would now translate into whether > the thread is alive or not), so the program can attempt to recover (or > take any other action, like shooting itself) if the timer stopped > working. > > My overall issue with this (I know, kind of late to realize this now), > is that it's really hard to recover from OOMs, or even detect that > they are happening, and all of the sudden your application threads > start to simply disappear, and you need yet another thread that would > go check they are alive and take some action (and who is to say that > thread won't die as well, and you won't notice that either). > > java.lang.OutOfMemoryError: Java heap space > at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:409) > at com.mysql.jdbc.ResultSetImpl.getInstance(ResultSetImpl.java:382) > at com.mysql.jdbc.MysqlIO.buildResultSetWithRows(MysqlIO.java:2604) > at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:487) > at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2582) > at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1758) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2172) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2690) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2619) > at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1465) > > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > > > Thanks, > Pawel. From pawel.veselov at gmail.com Thu Jul 15 00:08:06 2010 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Wed, 14 Jul 2010 17:08:06 -0700 Subject: Timer death In-Reply-To: <4C3E4620.3000003@oracle.com> References: <824og2p55a.fsf@mid.bfk.de> <4C3E4620.3000003@oracle.com> Message-ID: > Florian Weimer said the following on 07/14/10 23:25: >> * Pawel Veselov: >>> The fact that I catch any Throwable around the code that threw the >>> OOM error didn't particularly help. The error was logged, but the >>> timer thread still died. >> By definition, a VM which throws an Error (or even >> VirtualMachineError) is unstable and needs to be restarted. ?The >> description of VirtualMachineError makes that pretty clear. ?You >> cannot even know that the thread that triggers such exceptions is >> responsible for their actual cause. > An OutOfMemoryError for the Java heap does not fall into that category. OOM > is a transient failure in many circumstances. Not to be a nag here, but VirtualMachineError javadoc says "Thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it *to continue operating*.", and OutOfMemoryError extends VME. It is true that it is a transient failure in many circumstances, but if its impossible to find out, for an application, what the circumstances and implications are, along with whether these errors are even being thrown around, what should the application do? From David.Holmes at oracle.com Thu Jul 15 00:47:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 15 Jul 2010 10:47:51 +1000 Subject: Timer death In-Reply-To: References: <824og2p55a.fsf@mid.bfk.de> <4C3E4620.3000003@oracle.com> Message-ID: <4C3E5AB7.5000209@oracle.com> Pawel Veselov said the following on 07/15/10 10:08: >> Florian Weimer said the following on 07/14/10 23:25: >>> * Pawel Veselov: >>>> The fact that I catch any Throwable around the code that threw the >>>> OOM error didn't particularly help. The error was logged, but the >>>> timer thread still died. >>> By definition, a VM which throws an Error (or even >>> VirtualMachineError) is unstable and needs to be restarted. The >>> description of VirtualMachineError makes that pretty clear. You >>> cannot even know that the thread that triggers such exceptions is >>> responsible for their actual cause. >> An OutOfMemoryError for the Java heap does not fall into that category. OOM >> is a transient failure in many circumstances. > > Not to be a nag here, but VirtualMachineError javadoc says "Thrown to > indicate that the Java Virtual Machine is broken or has run out of > resources necessary for it *to continue operating*.", and > OutOfMemoryError extends VME. I think it is a historical mistake that OOME is a subclass of VME, as least so far as the non-recoverability in the Java-heap is concerned. I would suggest (somewhat tongue-in-cheek) that it was done at a time when people were far more familiar with OOM being a fatal error in C, than with it being a transient condition in a GC'd language. That said there should have been different OOME types for the Java heap and native-heap exhaustion (the latter of which is typically so fatal you don't even get the OOME thrown). > It is true that it is a transient > failure in many circumstances, but if its impossible to find out, for > an application, what the circumstances and implications are, along > with whether these errors are even being thrown around, what should > the application do? Serious applications that get OOME for heap exhaustion typically attempt: - retry (GC could be in progress) - request explicit GC - request explicit finalization - free up other memory used by the application (eg purge data structures) - some combination of the above Cheers, David Holmes From martinrb at google.com Thu Jul 15 01:37:27 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 Jul 2010 18:37:27 -0700 Subject: Timer death In-Reply-To: <4C3E5AB7.5000209@oracle.com> References: <824og2p55a.fsf@mid.bfk.de> <4C3E4620.3000003@oracle.com> <4C3E5AB7.5000209@oracle.com> Message-ID: On Wed, Jul 14, 2010 at 17:47, David Holmes wrote: > Pawel Veselov said the following on 07/15/10 10:08: > I think it is a historical mistake that OOME is a subclass of VME, as least > so far as the non-recoverability in the Java-heap is concerned. I would > suggest (somewhat tongue-in-cheek) that it was done at a time when people > were far more familiar with OOM being a fatal error in C, than with it being > a transient condition in a GC'd language. That said there should have been > different OOME types for the Java heap and native-heap exhaustion (the > latter of which is typically so fatal you don't even get the OOME thrown). I agree that OOME in Java is more recoverable than similar occurrence in C, and I have tried hard to write code that will not corrupt data structures even in the presence of OOME, but it's hard to get such code right, and most code out there doesn't even really try, so there is a good chance that your application will no longer operate quite right. Really good applications will have redundancy at the process or machine (or datacenter!) level, and on OOME, will die gracefully to be replaced by another instance. Martin From David.Holmes at oracle.com Thu Jul 15 01:45:10 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 15 Jul 2010 11:45:10 +1000 Subject: Timer death In-Reply-To: References: <824og2p55a.fsf@mid.bfk.de> <4C3E4620.3000003@oracle.com> <4C3E5AB7.5000209@oracle.com> Message-ID: <4C3E6826.6000603@oracle.com> Hi Martin, Martin Buchholz said the following on 07/15/10 11:37: > On Wed, Jul 14, 2010 at 17:47, David Holmes wrote: >> Pawel Veselov said the following on 07/15/10 10:08: >> I think it is a historical mistake that OOME is a subclass of VME, as least >> so far as the non-recoverability in the Java-heap is concerned. I would >> suggest (somewhat tongue-in-cheek) that it was done at a time when people >> were far more familiar with OOM being a fatal error in C, than with it being >> a transient condition in a GC'd language. That said there should have been >> different OOME types for the Java heap and native-heap exhaustion (the >> latter of which is typically so fatal you don't even get the OOME thrown). > > I agree that OOME in Java is more recoverable than similar occurrence in C, > and I have tried hard to write code that will not corrupt data structures > even in the presence of OOME, but it's hard to get such code right, > and most code out there doesn't even really try, so there is a good chance > that your application will no longer operate quite right. Really good > applications > will have redundancy at the process or machine (or datacenter!) level, > and on OOME, will die gracefully to be replaced by another instance. You are of course completely right. OOMEs are only potentially recoverable at the attempted allocation site. Once the OOME has propagated you need all the intervening code to be async-exception safe which is very rarely the case. I stand corrected. David Holmes From maurizio.cimadamore at oracle.com Thu Jul 15 15:46:07 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 15 Jul 2010 15:46:07 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100715154610.E9BD7479E1@hg.openjdk.java.net> Changeset: b49b0d72c071 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b49b0d72c071 6967002: JDK7 b99 javac compilation error (java.lang.AssertionError) Summary: bug in JavacParser related to parsing of type annotations in varargs position Reviewed-by: jjg Contributed-by: mahmood at notnoop.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/typeAnnotations/6967002/T6967002.java + test/tools/javac/typeAnnotations/6967002/T6967002.out Changeset: 472e74211e11 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/472e74211e11 6964669: javac reports error on miranda methods Summary: synthetic name clash check should not apply to miranda methods Reviewed-by: jjg Contributed-by: tomas.zezula at sun.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/miranda/6964669/T6964669.java + test/tools/javac/miranda/6964669/pkg/A.java + test/tools/javac/miranda/6964669/pkg/B.java + test/tools/javac/miranda/6964669/pkg/C.java From joe.darcy at oracle.com Fri Jul 16 01:03:16 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 16 Jul 2010 01:03:16 +0000 Subject: hg: jdk7/tl/jdk: 6963622: Project Coin: Refinements to suppressed exceptions Message-ID: <20100716010326.819AA479F8@hg.openjdk.java.net> Changeset: ab65f46ae092 Author: darcy Date: 2010-07-15 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ab65f46ae092 6963622: Project Coin: Refinements to suppressed exceptions Reviewed-by: alanb, forax, jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java From mandy.chung at oracle.com Fri Jul 16 03:43:05 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Jul 2010 20:43:05 -0700 Subject: Thread.getState() very slow In-Reply-To: <4C3A43B0.8010200@oracle.com> References: <4C387723.2070407@cs.oswego.edu> <4C39440B.5070501@oracle.com> <4C39A8E1.4050502@cs.oswego.edu> <4C3A43B0.8010200@oracle.com> Message-ID: <4C3FD549.5060007@oracle.com> Hi Doug, David, I'm not aware of any CRs related to the performance of Thread.getState(). Like Alan said, the implementation hasn't been changed since JDK 5 release. Probably the existing usage of Thread.getState() is not as performance sensitive as the starvation detector requires and thus the performance issue hasn't been noticed. David Holmes wrote: > Hi Doug, > > Doug Lea said the following on 07/11/10 21:20: >> Also, while I'm at it, field Thread.threadStatus is suspiciously not >> declared volatile. > > Agreed - technically this should be a volatile field. In practice I > think it only means that the window in which a stale value might be > seen is slightly longer. If threadStatus were exported directly it > might be more of an issue, but as an internal detail of getState() it > is not likely to be. > >>> Can you use Unsafe to grab the field directly, or would the >>> reflection make it too slow? >>> >> >> That's what I'm currently doing as a sleazy workaround. >> The sleaziness is not the Unsafe, which is basically fine >> since this is planned for JDK code, but having to guess at startup >> that the first value I get must be the one associated with RUNNABLE. > > I thought this would be fairly simple but looking deeper into this it > is a lot more complicated than I thought. There is a three-level > mapping from: > > OS/VM thread state -> VM ThreadStatus -> java.lang.ThreadState > > and it is a M:N:1 mapping > This is complicated than it needed to. I vaguely remember that the current implementation considered the compatibility issue between different version of hotspot VM and JDK (e.g. older VM running on a newer JDK with a new Thread.State enum). Also, the java_lang_Thread::ThreadStatus in hotspot was defined as ordinal values that we wanted to avoid those values hardcoded in both hotspot and jdk. Later it was changed to a hierarchical thread state represented as a bit vector (4980307) that we should have revised the implementation to map the bit vector directly to Thread.State enum but clearly the change in jdk was not done. > At least a startup you should be able to get the current thread's > threadStatus and know that it represents RUNNABLE. > > In addition I suspect the lazy initialization may be more necessary > than I thought given the time at which this initialization might occur > during the VM initialization sequence. I'd have to experiment (once > I've remembered how to build regular SE Hotspot and the OpenJDK libs :) ) > > Some input from the original implementors would be useful (Martin? > Mandy? ...) > Looking at the hotspot implementation (src/share/vm/classfile/javaClasses.hpp), java_lang_Thread::ThreadStatus is defined as a bit vector of JVMTI thread state flags: http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState I think making Thread.threadStatus a volatile field and using JVMTI_JAVA_LANG_THREAD_STATE_MASK to convert Thread.threadStatus to Thread.State enum would be a good solution. > That all said, you are the best person to evaluate the performance > impact of any changes so it might be best if you are the one to do the > initial experiments - using a simple volatile + DCL for the init as a > first attempt perhaps. > It'd be great if Doug can do the experiment and evaluate the performance impact. If you want me to prototype the jdk change, let me know and I should be able to make some time to do it next week. Mandy > David > >> >> -Doug >> From xueming.shen at oracle.com Fri Jul 16 20:49:30 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 16 Jul 2010 20:49:30 +0000 Subject: hg: jdk7/tl/jdk: 6964313: Find sun/nio/cs/ext issue with CreateSymbols, then move sun/nio/cs/ext to charset.jar Message-ID: <20100716204952.8A78847A40@hg.openjdk.java.net> Changeset: a3747592bdf7 Author: sherman Date: 2010-07-16 16:45 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a3747592bdf7 6964313: Find sun/nio/cs/ext issue with CreateSymbols, then move sun/nio/cs/ext to charset.jar Summary: Removed the duplicate sun.nio.cs.ext entries from rt.jar and moved X11 charsets into charsets.jar Reviewed-by: ohair ! make/common/Release.gmk ! make/sun/nio/cs/Makefile From joe.darcy at oracle.com Sat Jul 17 02:34:40 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 17 Jul 2010 02:34:40 +0000 Subject: hg: jdk7/tl/langtools: 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler; ... Message-ID: <20100717023447.0088E47A51@hg.openjdk.java.net> Changeset: 13354e1abba7 Author: darcy Date: 2010-07-16 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/13354e1abba7 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler 6964740: Project Coin: More tests for ARM compiler changes 6965277: Project Coin: Correctness issues in ARM implementation 6967065: add -Xlint warning category for Automatic Resource Management (ARM) Reviewed-by: jjb, darcy, mcimadamore, jjg, briangoetz Contributed-by: tball at google.com ! make/build.properties ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/TryWithResources/ArmLint.java + test/tools/javac/TryWithResources/ArmLint.out + test/tools/javac/TryWithResources/BadTwr.java + test/tools/javac/TryWithResources/BadTwr.out + test/tools/javac/TryWithResources/BadTwrSyntax.java + test/tools/javac/TryWithResources/BadTwrSyntax.out + test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/TryWithResources/ImplicitFinal.java + test/tools/javac/TryWithResources/ImplicitFinal.out + test/tools/javac/TryWithResources/PlainTry.java + test/tools/javac/TryWithResources/PlainTry.out + test/tools/javac/TryWithResources/PlainTry6.out + test/tools/javac/TryWithResources/ResourceOutsideTry.java + test/tools/javac/TryWithResources/ResourceOutsideTry.out + test/tools/javac/TryWithResources/ResourceTypeVar.java + test/tools/javac/TryWithResources/TwrFlow.java + test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/TryWithResources/TwrInference.java + test/tools/javac/TryWithResources/TwrIntersection.java + test/tools/javac/TryWithResources/TwrIntersection02.java + test/tools/javac/TryWithResources/TwrIntersection02.out + test/tools/javac/TryWithResources/TwrMultiCatch.java + test/tools/javac/TryWithResources/TwrOnNonResource.java + test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/TryWithResources/TwrTests.java + test/tools/javac/TryWithResources/WeirdTwr.java + test/tools/javac/processing/model/element/TestResourceVariable.java From mark.reinhold at oracle.com Sat Jul 17 03:45:45 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 16 Jul 2010 20:45:45 -0700 Subject: hg: jdk7/tl/langtools: 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler; ... In-Reply-To: joe.darcy@oracle.com; Sat, 17 Jul 2010 02:34:40 -0000; <20100717023447.0088E47A51@hg.openjdk.java.net> Message-ID: <20100717034545.1FB61B926@eggemoggin.niobe.net> > From: joe.darcy at oracle.com > Date: Sat, 17 Jul 2010 02:34:40 +0000 > Changeset: 13354e1abba7 > Author: darcy > Date: 2010-07-16 19:35 -0700 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/13354e1abba7 > > 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler > 6964740: Project Coin: More tests for ARM compiler changes > 6965277: Project Coin: Correctness issues in ARM implementation > 6967065: add -Xlint warning category for Automatic Resource Management (ARM) > Reviewed-by: jjb, darcy, mcimadamore, jjg, briangoetz > Contributed-by: tball at google.com It's great to see this go in! Thanks to everyone involved. - Mark From joe.darcy at oracle.com Sat Jul 17 04:50:59 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 16 Jul 2010 21:50:59 -0700 Subject: hg: jdk7/tl/langtools: 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler; ... In-Reply-To: <20100717034545.1FB61B926@eggemoggin.niobe.net> References: <20100717034545.1FB61B926@eggemoggin.niobe.net> Message-ID: <4C4136B3.1050705@oracle.com> mark.reinhold at oracle.com wrote: >> From: joe.darcy at oracle.com >> Date: Sat, 17 Jul 2010 02:34:40 +0000 >> > > >> Changeset: 13354e1abba7 >> Author: darcy >> Date: 2010-07-16 19:35 -0700 >> URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/13354e1abba7 >> >> 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler >> 6964740: Project Coin: More tests for ARM compiler changes >> 6965277: Project Coin: Correctness issues in ARM implementation >> 6967065: add -Xlint warning category for Automatic Resource Management (ARM) >> Reviewed-by: jjb, darcy, mcimadamore, jjg, briangoetz >> Contributed-by: tball at google.com >> > > It's great to see this go in! Thanks to everyone involved. > > - Mark > Neal also provided review feedback and I neglected to list him as a reviewer. Sorry for the omission and thanks for the comments Neal, -Joe From weijun.wang at sun.com Mon Jul 19 02:04:09 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Mon, 19 Jul 2010 02:04:09 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100719020430.2242C47ACA@hg.openjdk.java.net> Changeset: 9a1bd20fc71c Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9a1bd20fc71c 6969683: Generify ResolverConfiguration codes Reviewed-by: alanb, chegar ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/sun/net/dns/ResolverConfiguration.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java Changeset: 4022e0c84507 Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4022e0c84507 6969292: make DNS lookup for realm/kdc really work Reviewed-by: alanb, valeriep ! src/share/classes/sun/security/krb5/Config.java From sean.mullan at oracle.com Tue Jul 20 16:22:30 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 20 Jul 2010 16:22:30 +0000 Subject: hg: jdk7/tl/jdk: 6870553: X509Certificate.getSigAlgName method description uses non-standard algorithm name as example Message-ID: <20100720162240.9AED947B1F@hg.openjdk.java.net> Changeset: 9d1994d53a67 Author: mullan Date: 2010-07-20 10:41 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d1994d53a67 6870553: X509Certificate.getSigAlgName method description uses non-standard algorithm name as example Reviewed-by: xuelei ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java From chris.hegarty at oracle.com Wed Jul 21 12:32:42 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 21 Jul 2010 12:32:42 +0000 Subject: hg: jdk7/tl/jdk: 6969395: TEST_BUG: Tests in java/net sun/net problems Message-ID: <20100721123252.3BEE547B4C@hg.openjdk.java.net> Changeset: 58f325ba3e27 Author: chegar Date: 2010-07-21 13:29 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58f325ba3e27 6969395: TEST_BUG: Tests in java/net sun/net problems Reviewed-by: alanb ! test/ProblemList.txt ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test11.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test6a.java ! test/com/sun/net/httpserver/Test7a.java ! test/com/sun/net/httpserver/Test8a.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/bugs/B6361557.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/java/net/DatagramSocket/DatagramTimeout.java ! test/java/net/DatagramSocket/SendSize.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/SetOutgoingIf.java ! test/java/net/ResponseCache/B6181108.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java - test/java/net/Socket/AccurateTimeout.java ! test/java/net/Socket/CloseAvailable.java ! test/java/net/Socket/DeadlockTest.java ! test/java/net/Socket/LingerTest.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/Socket/ProxyCons.java ! test/java/net/Socket/ReadTimeout.java ! test/java/net/Socket/SetReceiveBufferSize.java ! test/java/net/Socket/SetSoLinger.java ! test/java/net/Socket/ShutdownBoth.java ! test/java/net/Socket/SoTimeout.java ! test/java/net/Socket/Timeout.java ! test/java/net/Socket/UrgentDataTest.java ! test/java/net/Socket/asyncClose/BrokenPipe.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/SocketInputStream/SocketClosedException.java ! test/java/net/SocketInputStream/SocketTimeout.java ! test/java/net/URL/GetContent.java ! test/java/net/URLClassLoader/ClassLoad.java ! test/java/net/URLConnection/DisconnectAfterEOF.java ! test/java/net/URLConnection/HandleContentTypeWithAttrs.java ! test/java/net/URLConnection/HttpContinueStackOverflow.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java ! test/java/net/URLConnection/ResendPostBody.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/net/URLConnection/TimeoutTest.java ! test/java/net/URLConnection/URLConnectionHeaders.java ! test/java/net/URLConnection/ZeroContentLength.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java ! test/sun/net/ftp/FtpGetContent.java ! test/sun/net/ftp/FtpURL.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/HttpClient/MultiThreadTest.java ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java ! test/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java ! test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/protocol/http/DigestTest.java From chris.hegarty at oracle.com Wed Jul 21 12:53:06 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 21 Jul 2010 12:53:06 +0000 Subject: hg: jdk7/tl/jdk: 6970262: TEST_BUG: test/java/net/NetworkInterface/IPv4Only.java has wrong test name in @run tag Message-ID: <20100721125315.3AAA847B4D@hg.openjdk.java.net> Changeset: f90999d7c404 Author: chegar Date: 2010-07-21 13:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f90999d7c404 6970262: TEST_BUG: test/java/net/NetworkInterface/IPv4Only.java has wrong test name in @run tag Reviewed-by: alanb, dsamersoff ! test/java/net/NetworkInterface/IPv4Only.java From alan.bateman at oracle.com Wed Jul 21 18:31:50 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 21 Jul 2010 18:31:50 +0000 Subject: hg: jdk7/tl/jdk: 6963907: (so) Socket adapter need to implement sendUrgentData Message-ID: <20100721183206.E5DFF47B65@hg.openjdk.java.net> Changeset: 3902c742b5b1 Author: alanb Date: 2010-07-21 18:08 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3902c742b5b1 6963907: (so) Socket adapter need to implement sendUrgentData Reviewed-by: chegar ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c + test/java/nio/channels/SocketChannel/OutOfBand.java From joe.darcy at oracle.com Thu Jul 22 02:04:51 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 21 Jul 2010 19:04:51 -0700 Subject: Code review request for 6717780 "(coll spec) LinkedList api documentation provides the wrong method name" Message-ID: <4C47A743.7060507@oracle.com> Hello. Please code review this simple fix to the LinkedList javadoc for bug 6717780 "(coll spec) LinkedList api documentation provides the wrong method name:" in the sentence "In addition to implementing the List interface, the LinkedList class provides uniformly named methods to get, remove and insert an element at the beginning and end of the list." the word "insert" should be "add". I've also added text to explicitly state that the beginning-of-list methods are operationFirst and the end of list methods are operationLast. Patch below, full webrev at http://cr.openjdk.java.net/~darcy/6717780.0/ Thanks, -Joe --- old/src/share/classes/java/util/LinkedList.java 2010-07-21 18:58:12.000000000 -0700 +++ new/src/share/classes/java/util/LinkedList.java 2010-07-21 18:58:12.000000000 -0700 @@ -26,14 +26,15 @@ package java.util; /** - * Linked list implementation of the {@code List} interface. Implements all - * optional list operations, and permits all elements (including - * {@code null}). In addition to implementing the {@code List} interface, - * the {@code LinkedList} class provides uniformly named methods to - * {@code get}, {@code remove} and {@code insert} an element at the - * beginning and end of the list. These operations allow linked lists to be - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque - * double-ended queue}. + * Linked list implementation of the {@code List} interface. + * Implements all optional list operations, and permits all elements + * (including {@code null}). In addition to implementing the {@code + * List} interface, the {@code LinkedList} class provides uniformly + * named methods to {@code get}, {@code remove} and {@code add} an + * element at the beginning (operation{@code First}) and end + * (operation{@code Last}) of the list. These operations allow + * linked lists to be used as a stack, {@linkplain Queue queue}, or + * {@linkplain Deque double-ended queue}. * *

The class implements the {@code Deque} interface, providing * first-in-first-out queue operations for {@code add}, From daniel.daugherty at oracle.com Thu Jul 22 02:26:46 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 22 Jul 2010 02:26:46 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20100722022714.A10C847B78@hg.openjdk.java.net> Changeset: d899526a187a Author: dcubed Date: 2010-07-21 16:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d899526a187a 6941287: 4/4 jrunscriptTest.sh test does not work right under Cygwin Summary: Add golden_diff variable for doing proper golden file diffs on Cygwin. Reviewed-by: ohair, dholmes ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh Changeset: 946236dc5c96 Author: dcubed Date: 2010-07-21 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/946236dc5c96 6962804: 4/4 ShellScaffold tests can fail without a specific reason Summary: Add more diagnostics for failures. Only copy target file in grepForString when NL is missing. Reviewed-by: ohair, dholmes ! test/com/sun/jdi/ShellScaffold.sh Changeset: 9cb77130999f Author: dcubed Date: 2010-07-21 17:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cb77130999f 6964018: 3/4 AnonLoggerWeakRefLeak and LoggerWeakRefLeak can fail in JPRT Summary: Refactor test/sun/tools/common/* code and refactor AnonLoggerWeakRefLeak and LoggerWeakRefLeak to use it. Reviewed-by: ohair, alanb ! test/java/util/logging/AnonLoggerWeakRefLeak.java ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.java ! test/java/util/logging/LoggerWeakRefLeak.sh ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/common/CommonTests.sh ! test/sun/tools/common/ShutdownSimpleApplication.java ! test/sun/tools/common/SimpleApplication.java + test/sun/tools/common/SleeperApplication.java ! test/sun/tools/jhat/ParseTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jstack/Basic.sh From David.Holmes at oracle.com Thu Jul 22 02:33:20 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 22 Jul 2010 12:33:20 +1000 Subject: Code review request for 6717780 "(coll spec) LinkedList api documentation provides the wrong method name" In-Reply-To: <4C47A743.7060507@oracle.com> References: <4C47A743.7060507@oracle.com> Message-ID: <4C47ADF0.4020502@oracle.com> Joe, Looks good to me. David Joe Darcy said the following on 07/22/10 12:04: > Hello. > > Please code review this simple fix to the LinkedList javadoc for bug > 6717780 "(coll spec) LinkedList api documentation provides the wrong > method name:" in the sentence > > "In addition to implementing the List interface, the LinkedList class > provides uniformly named methods to get, remove and insert an element at > the beginning and end of the list." > > the word "insert" should be "add". I've also added text to explicitly > state that the beginning-of-list methods are operationFirst and the end > of list methods are operationLast. > > Patch below, full webrev at > http://cr.openjdk.java.net/~darcy/6717780.0/ > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/LinkedList.java 2010-07-21 > 18:58:12.000000000 -0700 > +++ new/src/share/classes/java/util/LinkedList.java 2010-07-21 > 18:58:12.000000000 -0700 > @@ -26,14 +26,15 @@ > package java.util; > > /** > - * Linked list implementation of the {@code List} interface. > Implements all > - * optional list operations, and permits all elements (including > - * {@code null}). In addition to implementing the {@code List} interface, > - * the {@code LinkedList} class provides uniformly named methods to > - * {@code get}, {@code remove} and {@code insert} an element at the > - * beginning and end of the list. These operations allow linked lists > to be > - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque > - * double-ended queue}. > + * Linked list implementation of the {@code List} interface. > + * Implements all optional list operations, and permits all elements > + * (including {@code null}). In addition to implementing the {@code > + * List} interface, the {@code LinkedList} class provides uniformly > + * named methods to {@code get}, {@code remove} and {@code add} an > + * element at the beginning (operation{@code First}) and end > + * (operation{@code Last}) of the list. These operations allow > + * linked lists to be used as a stack, {@linkplain Queue queue}, or > + * {@linkplain Deque double-ended queue}. > * > *

The class implements the {@code Deque} interface, providing > * first-in-first-out queue operations for {@code add}, > From martinrb at google.com Thu Jul 22 02:34:59 2010 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Jul 2010 19:34:59 -0700 Subject: Code review request for 6717780 "(coll spec) LinkedList api documentation provides the wrong method name" In-Reply-To: <4C47A743.7060507@oracle.com> References: <4C47A743.7060507@oracle.com> Message-ID: Perhaps much of the text is redundant with the specification in the second paragraph, that talks about how a LinkedList is also a Deque. Perhaps the sentence starting In addition to should be removed, a remnant of a time when LinkedList did not implement Deque? Martin On Wed, Jul 21, 2010 at 19:04, Joe Darcy wrote: > Hello. > > Please code review this simple fix to the LinkedList javadoc for bug > 6717780 "(coll spec) LinkedList api documentation provides the wrong method > name:" in the sentence > > "In addition to implementing the List interface, the LinkedList class > provides uniformly named methods to get, remove and insert an element at the > beginning and end of the list." > > the word "insert" should be "add". I've also added text to explicitly > state that the beginning-of-list methods are operationFirst and the end of > list methods are operationLast. > > Patch below, full webrev at > http://cr.openjdk.java.net/~darcy/6717780.0/ > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/LinkedList.java 2010-07-21 > 18:58:12.000000000 -0700 > +++ new/src/share/classes/java/util/LinkedList.java 2010-07-21 > 18:58:12.000000000 -0700 > @@ -26,14 +26,15 @@ > package java.util; > > /** > - * Linked list implementation of the {@code List} interface. Implements > all > - * optional list operations, and permits all elements (including > - * {@code null}). In addition to implementing the {@code List} interface, > - * the {@code LinkedList} class provides uniformly named methods to > - * {@code get}, {@code remove} and {@code insert} an element at the > - * beginning and end of the list. These operations allow linked lists to > be > - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque > - * double-ended queue}. > + * Linked list implementation of the {@code List} interface. > + * Implements all optional list operations, and permits all elements > + * (including {@code null}). In addition to implementing the {@code > + * List} interface, the {@code LinkedList} class provides uniformly > + * named methods to {@code get}, {@code remove} and {@code add} an > + * element at the beginning (operation{@code First}) and end > + * (operation{@code Last}) of the list. These operations allow > + * linked lists to be used as a stack, {@linkplain Queue queue}, or > + * {@linkplain Deque double-ended queue}. > * > *

The class implements the {@code Deque} interface, providing > * first-in-first-out queue operations for {@code add}, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jul 22 16:40:36 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 22 Jul 2010 09:40:36 -0700 Subject: Code review request for 6717780 "(coll spec) LinkedList api documentation provides the wrong method name" In-Reply-To: References: <4C47A743.7060507@oracle.com> Message-ID: <4C487484.1050300@oracle.com> Martin Buchholz wrote: > Perhaps much of the text is redundant with the specification in the > second paragraph, that talks about how a LinkedList is also a Deque. > > Perhaps the sentence starting > In addition to > > > > should be removed, a remnant of a time when LinkedList did not > implement Deque? Hmm. I'm more inclined to keep the revised sentence "In addition to implementing the List interface, the LinkedList class provides uniformly named methods to get, remove and add an element at the beginning (operationFirst) and end (operationLast) of the list." and combine the next two sentences like so: "These operations allow linked lists to be used as a stack, queue, or deque (double-ended queue); implementing the Deque interface includes support for first-in-first-out operations for add and poll." What do you think? -Joe > > Martin > > On Wed, Jul 21, 2010 at 19:04, Joe Darcy > wrote: > > Hello. > > Please code review this simple fix to the LinkedList javadoc for > bug 6717780 "(coll spec) LinkedList api documentation provides the > wrong method name:" in the sentence > > "In addition to implementing the List interface, the LinkedList > class provides uniformly named methods to get, remove and insert > an element at the beginning and end of the list." > > the word "insert" should be "add". I've also added text to > explicitly state that the beginning-of-list methods are > operationFirst and the end of list methods are operationLast. > > Patch below, full webrev at > http://cr.openjdk.java.net/~darcy/6717780.0/ > > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/LinkedList.java 2010-07-21 > 18:58:12.000000000 -0700 > +++ new/src/share/classes/java/util/LinkedList.java 2010-07-21 > 18:58:12.000000000 -0700 > @@ -26,14 +26,15 @@ > package java.util; > > /** > - * Linked list implementation of the {@code List} interface. > Implements all > - * optional list operations, and permits all elements (including > - * {@code null}). In addition to implementing the {@code List} > interface, > - * the {@code LinkedList} class provides uniformly named methods to > - * {@code get}, {@code remove} and {@code insert} an element at the > - * beginning and end of the list. These operations allow linked > lists to be > - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque > - * double-ended queue}. > + * Linked list implementation of the {@code List} interface. > + * Implements all optional list operations, and permits all elements > + * (including {@code null}). In addition to implementing the {@code > + * List} interface, the {@code LinkedList} class provides uniformly > + * named methods to {@code get}, {@code remove} and {@code add} an > + * element at the beginning (operation{@code First}) and end > + * (operation{@code Last}) of the list. These operations > allow > + * linked lists to be used as a stack, {@linkplain Queue queue}, or > + * {@linkplain Deque double-ended queue}. > * > *

The class implements the {@code Deque} interface, providing > * first-in-first-out queue operations for {@code add}, > > From jonathan.gibbons at oracle.com Thu Jul 22 18:03:33 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 22 Jul 2010 18:03:33 +0000 Subject: hg: jdk7/tl/langtools: 6968063: provide examples of code that generate diagnostics Message-ID: <20100722180335.8045E47BA3@hg.openjdk.java.net> Changeset: 3640b60bd0f6 Author: jjg Date: 2010-07-22 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3640b60bd0f6 6968063: provide examples of code that generate diagnostics Reviewed-by: mcimadamore ! make/build.xml + test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/Example.java + test/tools/javac/diags/FileManager.java + test/tools/javac/diags/HTMLWriter.java + test/tools/javac/diags/README.examples.txt + test/tools/javac/diags/RunExamples.java + test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/AbstractCantBeAccessed.java + test/tools/javac/diags/examples/AbstractCantBeInstantiated.java + test/tools/javac/diags/examples/AbstractMethodCantHaveBody.java + test/tools/javac/diags/examples/AlreadyDefined.java + test/tools/javac/diags/examples/AlreadyDefinedImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/diags/examples/AnnoNotApplicable.java + test/tools/javac/diags/examples/AnnoNotValidForType.java + test/tools/javac/diags/examples/AnnoValueMustBeAnnotation.java + test/tools/javac/diags/examples/AnnoValueMustBeClassLiteral.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/AnnosWithoutProcessors.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/processors/AnnoProc.java + test/tools/javac/diags/examples/AnnotationMissingValue.java + test/tools/javac/diags/examples/AnnotationMustBeNameValue.java + test/tools/javac/diags/examples/AnnotationsNotSupported.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoArgs.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoQualForNew.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoTypeArgs.java + test/tools/javac/diags/examples/AnonymousClass.java + test/tools/javac/diags/examples/ArrayAndVarargs.java + test/tools/javac/diags/examples/ArrayDimMissing.java + test/tools/javac/diags/examples/ArrayRequired.java + test/tools/javac/diags/examples/AssertAsIdentifier.java + test/tools/javac/diags/examples/AssertAsIdentifier2.java + test/tools/javac/diags/examples/AttrMustBeConstant.java + test/tools/javac/diags/examples/BadSourceFileHeader/BadSourceFileHeader.java + test/tools/javac/diags/examples/BadSourceFileHeader/sourcepath/p/A.java + test/tools/javac/diags/examples/BreakOutsideSwitchLoop.java + test/tools/javac/diags/examples/CallMustBeFirst.java + test/tools/javac/diags/examples/CannotCreateArrayWithTypeArgs.java + test/tools/javac/diags/examples/CantApplyDiamond.java + test/tools/javac/diags/examples/CantAssignToFinal.java + test/tools/javac/diags/examples/CantDeref.java + test/tools/javac/diags/examples/CantExtendIntfAnno.java + test/tools/javac/diags/examples/CantImplement.java + test/tools/javac/diags/examples/CantInheritDiffArg.java + test/tools/javac/diags/examples/CantRefBeforeConstr.java + test/tools/javac/diags/examples/CantResolve.java + test/tools/javac/diags/examples/CantResolveArgs.java + test/tools/javac/diags/examples/CantResolveArgsParams.java + test/tools/javac/diags/examples/CantResolveLocation.java + test/tools/javac/diags/examples/CantResolveLocationArgs.java + test/tools/javac/diags/examples/CantResolveLocationArgsParams.java + test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/ClashesWith.java + test/tools/javac/diags/examples/ClassCantWrite.java + test/tools/javac/diags/examples/ClassPublicInFile.java + test/tools/javac/diags/examples/ConcreteInheritanceConflict.java + test/tools/javac/diags/examples/ConstExprRequired.java + test/tools/javac/diags/examples/ConstantSVUID.java + test/tools/javac/diags/examples/ContinueOutsideLoop.java + test/tools/javac/diags/examples/CountError.java + test/tools/javac/diags/examples/CountErrorPlural.java + test/tools/javac/diags/examples/CountWarn.java + test/tools/javac/diags/examples/CountWarnPlural.java + test/tools/javac/diags/examples/CyclicAnnoElement.java + test/tools/javac/diags/examples/CyclicInheritance.java + test/tools/javac/diags/examples/DefaultAllowedInIntfAnnotationMember.java + test/tools/javac/diags/examples/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedFilenameAdditional.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPluralAdditional.java + test/tools/javac/diags/examples/DiamondInvalidArg.java + test/tools/javac/diags/examples/DiamondInvalidArgs.java + test/tools/javac/diags/examples/DiamondNotSupported.java + test/tools/javac/diags/examples/DirPathElementNotFound.java + test/tools/javac/diags/examples/DivZero.java + test/tools/javac/diags/examples/DoesNotOverride.java + test/tools/javac/diags/examples/DoesntExist.java + test/tools/javac/diags/examples/DotClassExpected.java + test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationMemberValue.java + test/tools/javac/diags/examples/DuplicateCaseLabel.java + test/tools/javac/diags/examples/DuplicateClass.java + test/tools/javac/diags/examples/DuplicateDefaultLabel.java + test/tools/javac/diags/examples/ElseWithoutIf.java + test/tools/javac/diags/examples/EmptyBytecodeIdent.java + test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/diags/examples/EmptyIf.java + test/tools/javac/diags/examples/EnclClassRequired.java + test/tools/javac/diags/examples/EnumAnnoValueMustBeEnumConst.java + test/tools/javac/diags/examples/EnumAsIdentifier.java + test/tools/javac/diags/examples/EnumAsIdentifier2.java + test/tools/javac/diags/examples/EnumCantBeInstantiated.java + test/tools/javac/diags/examples/EnumConstRequired.java + test/tools/javac/diags/examples/EnumLabelUnqualified.java + test/tools/javac/diags/examples/EnumNoFinalize.java + test/tools/javac/diags/examples/EnumNoSubclassing.java + test/tools/javac/diags/examples/EnumTypesNotExtensible.java + test/tools/javac/diags/examples/EnumsMustBeStatic.java + test/tools/javac/diags/examples/EnumsNotSupported.java + test/tools/javac/diags/examples/ErrProcMessager/ErrProcMessager.java + test/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/ErrSyntheticNameConflict.java + test/tools/javac/diags/examples/Error.java + test/tools/javac/diags/examples/ErrorReadingFile.java + test/tools/javac/diags/examples/ExceptAlreadyCaught.java + test/tools/javac/diags/examples/ExceptNeverThrown.java + test/tools/javac/diags/examples/Expected2.java + test/tools/javac/diags/examples/Expected3.java + test/tools/javac/diags/examples/FinalParamCantBeAssigned.java + test/tools/javac/diags/examples/FinallyCannotComplete.java + test/tools/javac/diags/examples/FinallyWithoutTry.java + test/tools/javac/diags/examples/FloatNumberTooLarge.java + test/tools/javac/diags/examples/FloatNumberTooSmall.java + test/tools/javac/diags/examples/ForeachNotApplicable.java + test/tools/javac/diags/examples/ForeachNotSupported.java + test/tools/javac/diags/examples/GenericArrayCreation.java + test/tools/javac/diags/examples/GenericThrowable.java + test/tools/javac/diags/examples/GenericsNotSupported.java + test/tools/javac/diags/examples/HasBeenDeprecated.java + test/tools/javac/diags/examples/IdentifierExpected.java + test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java + test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/IllegalComboModifiers.java + test/tools/javac/diags/examples/IllegalEnumStaticRef.java + test/tools/javac/diags/examples/IllegalEscapeChar.java + test/tools/javac/diags/examples/IllegalForwardRef.java + test/tools/javac/diags/examples/IllegalInitializer.java + test/tools/javac/diags/examples/IllegalLineEndInCharLit.java + test/tools/javac/diags/examples/IllegalNonAsciiDigit.java + test/tools/javac/diags/examples/IllegalQualNotIcls.java + test/tools/javac/diags/examples/IllegalSelfRef.java + test/tools/javac/diags/examples/IllegalStartOfExpr.java + test/tools/javac/diags/examples/IllegalUnderscore.java + test/tools/javac/diags/examples/IllegalUnicodeEscape.java + test/tools/javac/diags/examples/ImportRequiresCanonical/ImportRequiresCanonical.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/Base.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/ExtendsBase.java + test/tools/javac/diags/examples/ImproperSVUID.java + test/tools/javac/diags/examples/ImproperTypeInnerRawParam.java + test/tools/javac/diags/examples/ImproperTypeParamMissing.java + test/tools/javac/diags/examples/IncomparableTypes.java + test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InconvertibleTypes.java + test/tools/javac/diags/examples/InexactVarargsCall.java + test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InheritFromFinal.java + test/tools/javac/diags/examples/InitializerMustComplete.java + test/tools/javac/diags/examples/InnerClassCantHaveStatic.java + test/tools/javac/diags/examples/IntNumberTooLarge.java + test/tools/javac/diags/examples/InterfaceExpected.java + test/tools/javac/diags/examples/InterfaceNotAllowed.java + test/tools/javac/diags/examples/IntfAnnotationCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfAnnotationMemberClash.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveParams.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfMethodCantHaveBody.java + test/tools/javac/diags/examples/InvalidAnnoMemberType.java + test/tools/javac/diags/examples/InvalidBinaryNumber.java + test/tools/javac/diags/examples/InvalidHexNumber.java + test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/diags/examples/InvalidInstanceof.java + test/tools/javac/diags/examples/InvalidMethodDecl.java + test/tools/javac/diags/examples/KindnameClass.java + test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/KindnameMethod.java + test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/LabelInUse.java + test/tools/javac/diags/examples/LocalEnum.java + test/tools/javac/diags/examples/LocalVarNeedsFinal.java + test/tools/javac/diags/examples/LongSVUID.java + test/tools/javac/diags/examples/MalformedFpLit.java + test/tools/javac/diags/examples/MalformedSupported/MalformedSupported.java + test/tools/javac/diags/examples/MalformedSupported/processors/AnnoProc.java + test/tools/javac/diags/examples/MethodDoesNotOverride.java + test/tools/javac/diags/examples/MightBeAssignedInLoop.java + test/tools/javac/diags/examples/MissingDeprecatedAnnotation.java + test/tools/javac/diags/examples/MissingMethodBody.java + test/tools/javac/diags/examples/MissingReturnStatement.java + test/tools/javac/diags/examples/MissingReturnValue.java + test/tools/javac/diags/examples/MissingSVUID.java + test/tools/javac/diags/examples/ModifierNotAllowed.java + test/tools/javac/diags/examples/MulticatchCantBeAssigned.java + test/tools/javac/diags/examples/MulticatchMustBeFinal.java + test/tools/javac/diags/examples/MulticatchNotSupported.java + test/tools/javac/diags/examples/NameClashSameErasure.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NativeMethodCantHaveBody.java + test/tools/javac/diags/examples/NeitherConditionalSubtype.java + test/tools/javac/diags/examples/NewNotAllowedInAnno.java + test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NoExplicitAnnoProcRequested.java + test/tools/javac/diags/examples/NoInterfaceExpected.java + test/tools/javac/diags/examples/NoInterfaceHere.java + test/tools/javac/diags/examples/NoJavaLang.java + test/tools/javac/diags/examples/NoSuperclass.java + test/tools/javac/diags/examples/NonStaticCantBeRef.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/NotDefAccessClassIntfCantAccess.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/p/C.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/NotDefPublicCantAccess.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/p/C.java + test/tools/javac/diags/examples/NotEnclClass.java + test/tools/javac/diags/examples/NotLoopLabel.java + test/tools/javac/diags/examples/NotWithinBounds.java + test/tools/javac/diags/examples/Note.java + test/tools/javac/diags/examples/NoteProcMessager/NoteProcMessager.java + test/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/Orphaned.java + test/tools/javac/diags/examples/OverrideDoesntThrow.java + test/tools/javac/diags/examples/OverrideIncompatibleReturn.java + test/tools/javac/diags/examples/OverrideMeth.java + test/tools/javac/diags/examples/OverrideStatic.java + test/tools/javac/diags/examples/OverrideUncheckedReturn.java + test/tools/javac/diags/examples/OverrideUncheckedThrown.java + test/tools/javac/diags/examples/OverrideVarargsExtra.java + test/tools/javac/diags/examples/OverrideVarargsMissing.java + test/tools/javac/diags/examples/OverrideWeakerAccess.java + test/tools/javac/diags/examples/PackageAnnos.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/p/package-info.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/package-info.java + test/tools/javac/diags/examples/PathElementNotFound.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q/C.java + test/tools/javac/diags/examples/PossibleFallThrough.java + test/tools/javac/diags/examples/PossibleLossPrecision.java + test/tools/javac/diags/examples/PrematureEOF.java + test/tools/javac/diags/examples/PrintProcessorInfo/PrintProcessorInfo.java + test/tools/javac/diags/examples/PrintProcessorInfo/processors/AnnoProc.java + test/tools/javac/diags/examples/PrintRounds/PrintRounds.java + test/tools/javac/diags/examples/PrintRounds/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcCantFindClass/ProcCantFindClass.java + test/tools/javac/diags/examples/ProcCantFindClass/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcFileReopening/ProcFileReopening.java + test/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIllegalFileName/ProcIllegalFileName.java + test/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/ProcIncompatibleSourceVersion.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcOnlyNoProcs.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/ProcPackageDoesNotExist.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcTypeRecreate/ProcTypeRecreate.java + test/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/ProcUnclosedTypeFiles.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/ProcUseImplicit.java + test/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/ProcUseProcOrImplicit.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/ProcessorCantInstantiate.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcessorNotFound.java + test/tools/javac/diags/examples/ProcessorWrongType/ProcessorWrongType.java + test/tools/javac/diags/examples/ProcessorWrongType/processors/AnnoProc.java + test/tools/javac/diags/examples/QualifiedNewStaticClass.java + test/tools/javac/diags/examples/RawClassUse.java + test/tools/javac/diags/examples/RecursiveConstrInvocation.java + test/tools/javac/diags/examples/RedundantCast.java + test/tools/javac/diags/examples/RefAmbiguous.java + test/tools/javac/diags/examples/RepeatedAnnotationTarget.java + test/tools/javac/diags/examples/RepeatedInterface.java + test/tools/javac/diags/examples/RepeatedModifier.java + test/tools/javac/diags/examples/ReportAccess.java + test/tools/javac/diags/examples/ResourceClosed.java + test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java + test/tools/javac/diags/examples/ResourceNotApplicableToType.java + test/tools/javac/diags/examples/ResourceNotReferenced.java + test/tools/javac/diags/examples/ReturnOutsideMethod.java + test/tools/javac/diags/examples/StaticImportNotSupported.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/Other.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java + test/tools/javac/diags/examples/StaticNotQualifiedByType.java + test/tools/javac/diags/examples/StringConstRequired.java + test/tools/javac/diags/examples/StringSwitchNotSupported.java + test/tools/javac/diags/examples/SunApiFilename.java + test/tools/javac/diags/examples/SunApiFilenameAdditional.java + test/tools/javac/diags/examples/SunApiPlural/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPlural/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPluralAdditional.java + test/tools/javac/diags/examples/SunProprietary.java + test/tools/javac/diags/examples/SuperNotAllowedInEnum.java + test/tools/javac/diags/examples/ThrowsNotAllowedInAnno.java + test/tools/javac/diags/examples/TryResourceNotSupported.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinallyOrResource.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java + test/tools/javac/diags/examples/TypeFoundRequired.java + test/tools/javac/diags/examples/TypeNoParams.java + test/tools/javac/diags/examples/TypeReqClassArray.java + test/tools/javac/diags/examples/TypeReqRef.java + test/tools/javac/diags/examples/TypeVarCantBeDeref.java + test/tools/javac/diags/examples/TypeVarMayNotBeFollowedByOtherBounds.java + test/tools/javac/diags/examples/TypesIncompatible.java + test/tools/javac/diags/examples/UncheckedAssign.java + test/tools/javac/diags/examples/UncheckedAssignToVar.java + test/tools/javac/diags/examples/UncheckedCall.java + test/tools/javac/diags/examples/UncheckedCast.java + test/tools/javac/diags/examples/UncheckedClash.java + test/tools/javac/diags/examples/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedFilenameAdditional.java + test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java + test/tools/javac/diags/examples/UncheckedImplement.java + test/tools/javac/diags/examples/UncheckedMethodInvocation.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedPlural.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename1.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename2.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedPluralAdditional.java + test/tools/javac/diags/examples/UnclosedBytecodeIdent.java + test/tools/javac/diags/examples/UnclosedCharLiteral.java + test/tools/javac/diags/examples/UnclosedComment.java + test/tools/javac/diags/examples/UnclosedStringLiteral.java + test/tools/javac/diags/examples/UndefinedLabel.java + test/tools/javac/diags/examples/UndeterminedType1.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/UnmatchedProcessorOptions.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/processors/AnnoProc.java + test/tools/javac/diags/examples/UnnamedPackage.java + test/tools/javac/diags/examples/UnreachableStatement.java + test/tools/javac/diags/examples/UnreportedException.java + test/tools/javac/diags/examples/UnreportedExceptionDefaultConstructor.java + test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java + test/tools/javac/diags/examples/UnsupportedEncoding.java + test/tools/javac/diags/examples/UnsupportedFpLit.java + test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java + test/tools/javac/diags/examples/VarMightAlreadyBeAssigned.java + test/tools/javac/diags/examples/VarMightNotHaveBeenInitialized.java + test/tools/javac/diags/examples/VarargsClash.java + test/tools/javac/diags/examples/VarargsFilename.java + test/tools/javac/diags/examples/VarargsFilenameAdditional.java + test/tools/javac/diags/examples/VarargsImplement.java + test/tools/javac/diags/examples/VarargsNonReifiableType.java + test/tools/javac/diags/examples/VarargsNotSupported.java + test/tools/javac/diags/examples/VarargsOverride.java + test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java + test/tools/javac/diags/examples/Verbose.java + test/tools/javac/diags/examples/VoidNotAllowed.java + test/tools/javac/diags/examples/WarnForwardRef.java + test/tools/javac/diags/examples/WarnProcMessager/WarnProcMessager.java + test/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/WarnSelfRef.java + test/tools/javac/diags/examples/WarnSyntheticNameConflict.java + test/tools/javac/diags/examples/WarningAndWerror.java + test/tools/javac/diags/examples/WhereCaptured.java + test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereIntersection.java + test/tools/javac/diags/examples/WhereTypeVar.java + test/tools/javac/diags/examples/WrongNumberTypeArgs.java From martinrb at google.com Thu Jul 22 23:20:08 2010 From: martinrb at google.com (Martin Buchholz) Date: Thu, 22 Jul 2010 16:20:08 -0700 Subject: Code review request for 6717780 "(coll spec) LinkedList api documentation provides the wrong method name" In-Reply-To: <4C487484.1050300@oracle.com> References: <4C47A743.7060507@oracle.com> <4C487484.1050300@oracle.com> Message-ID: Here's a possible counter-patch that removes a lot of text by delegating most of the wording to the Deque javadoc, and makes LinkedList's Dequeness as first-class as its Listness. diff --git a/src/share/classes/java/util/LinkedList.java b/src/share/classes/java/util/LinkedList.java --- a/src/share/classes/java/util/LinkedList.java +++ b/src/share/classes/java/util/LinkedList.java @@ -26,18 +26,9 @@ package java.util; /** - * Linked list implementation of the {@code List} interface. Implements all - * optional list operations, and permits all elements (including - * {@code null}). In addition to implementing the {@code List} interface, - * the {@code LinkedList} class provides uniformly named methods to - * {@code get}, {@code remove} and {@code insert} an element at the - * beginning and end of the list. These operations allow linked lists to be - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque - * double-ended queue}. - * - *

The class implements the {@code Deque} interface, providing - * first-in-first-out queue operations for {@code add}, - * {@code poll}, along with other stack and deque operations. + * Linked list implementation of the {@link List} and {@link Deque} interfaces. + * Implements all optional operations, and permits all elements (including + * {@code null}). * *

All of the operations perform as could be expected for a doubly-linked * list. Operations that index into the list will traverse the list from Martin On Thu, Jul 22, 2010 at 09:40, Joe Darcy wrote: > Martin Buchholz wrote: > >> Perhaps much of the text is redundant with the specification in the second >> paragraph, that talks about how a LinkedList is also a Deque. >> >> Perhaps the sentence starting >> In addition to >> >> >> should be removed, a remnant of a time when LinkedList did not implement >> Deque? >> > > Hmm. I'm more inclined to keep the revised sentence > > "In addition to implementing the List interface, the LinkedList class > provides uniformly named methods to get, remove and add an element at the > beginning (operationFirst) and end (operationLast) of the list." > > and combine the next two sentences like so: > > "These operations allow linked lists to be used as a stack, queue, or deque > (double-ended queue); implementing the Deque interface includes support for > first-in-first-out operations for add and poll." > > What do you think? > > -Joe > >> >> Martin >> >> >> On Wed, Jul 21, 2010 at 19:04, Joe Darcy > joe.darcy at oracle.com>> wrote: >> >> Hello. >> >> Please code review this simple fix to the LinkedList javadoc for >> bug 6717780 "(coll spec) LinkedList api documentation provides the >> wrong method name:" in the sentence >> >> "In addition to implementing the List interface, the LinkedList >> class provides uniformly named methods to get, remove and insert >> an element at the beginning and end of the list." >> >> the word "insert" should be "add". I've also added text to >> explicitly state that the beginning-of-list methods are >> operationFirst and the end of list methods are operationLast. >> >> Patch below, full webrev at >> http://cr.openjdk.java.net/~darcy/6717780.0/ >> >> >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/util/LinkedList.java 2010-07-21 >> 18:58:12.000000000 -0700 >> +++ new/src/share/classes/java/util/LinkedList.java 2010-07-21 >> 18:58:12.000000000 -0700 >> @@ -26,14 +26,15 @@ >> package java.util; >> >> /** >> - * Linked list implementation of the {@code List} interface. >> Implements all >> - * optional list operations, and permits all elements (including >> - * {@code null}). In addition to implementing the {@code List} >> interface, >> - * the {@code LinkedList} class provides uniformly named methods to >> - * {@code get}, {@code remove} and {@code insert} an element at the >> - * beginning and end of the list. These operations allow linked >> lists to be >> - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque >> - * double-ended queue}. >> + * Linked list implementation of the {@code List} interface. >> + * Implements all optional list operations, and permits all elements >> + * (including {@code null}). In addition to implementing the {@code >> + * List} interface, the {@code LinkedList} class provides uniformly >> + * named methods to {@code get}, {@code remove} and {@code add} an >> + * element at the beginning (operation{@code First}) and end >> + * (operation{@code Last}) of the list. These operations >> allow >> + * linked lists to be used as a stack, {@linkplain Queue queue}, or >> + * {@linkplain Deque double-ended queue}. >> * >> *

The class implements the {@code Deque} interface, providing >> * first-in-first-out queue operations for {@code add}, >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Fri Jul 23 00:04:53 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 22 Jul 2010 17:04:53 -0700 Subject: Code review request for 6717780 "(coll spec) LinkedList api documentation provides the wrong method name" In-Reply-To: References: <4C47A743.7060507@oracle.com> <4C487484.1050300@oracle.com> Message-ID: <4C48DCA5.9040001@oracle.com> Yes, that is more concise while still conveying the needed information. I'll be a reviewer if you want to push your counter-patch. -Joe Martin Buchholz wrote: > Here's a possible counter-patch that removes a lot of text by > delegating most of the wording to the Deque javadoc, and makes > LinkedList's Dequeness as first-class as its Listness. > > diff --git a/src/share/classes/java/util/LinkedList.java > b/src/share/classes/java/util/LinkedList.java > --- a/src/share/classes/java/util/LinkedList.java > +++ b/src/share/classes/java/util/LinkedList.java > @@ -26,18 +26,9 @@ > package java.util; > > /** > - * Linked list implementation of the {@code List} interface. > Implements all > - * optional list operations, and permits all elements (including > - * {@code null}). In addition to implementing the {@code List} > interface, > - * the {@code LinkedList} class provides uniformly named methods to > - * {@code get}, {@code remove} and {@code insert} an element at the > - * beginning and end of the list. These operations allow linked > lists to be > - * used as a stack, {@linkplain Queue queue}, or {@linkplain Deque > - * double-ended queue}. > - * > - *

The class implements the {@code Deque} interface, providing > - * first-in-first-out queue operations for {@code add}, > - * {@code poll}, along with other stack and deque operations. > + * Linked list implementation of the {@link List} and {@link Deque} > interfaces. > + * Implements all optional operations, and permits all elements > (including > + * {@code null}). > * > *

All of the operations perform as could be expected for a > doubly-linked > * list. Operations that index into the list will traverse the list from > > Martin > > On Thu, Jul 22, 2010 at 09:40, Joe Darcy > wrote: > > Martin Buchholz wrote: > > Perhaps much of the text is redundant with the specification > in the second paragraph, that talks about how a LinkedList is > also a Deque. > > Perhaps the sentence starting > In addition to > > > should be removed, a remnant of a time when LinkedList did > not implement Deque? > > > Hmm. I'm more inclined to keep the revised sentence > > "In addition to implementing the List interface, the LinkedList > class provides uniformly named methods to get, remove and add an > element at the beginning (operationFirst) and end (operationLast) > of the list." > > and combine the next two sentences like so: > > "These operations allow linked lists to be used as a stack, queue, > or deque (double-ended queue); implementing the Deque interface > includes support for first-in-first-out operations for add and poll." > > What do you think? > > -Joe > > > Martin > > > On Wed, Jul 21, 2010 at 19:04, Joe Darcy >> wrote: > > Hello. > > Please code review this simple fix to the LinkedList > javadoc for > bug 6717780 "(coll spec) LinkedList api documentation > provides the > wrong method name:" in the sentence > > "In addition to implementing the List interface, the LinkedList > class provides uniformly named methods to get, remove and > insert > an element at the beginning and end of the list." > > the word "insert" should be "add". I've also added text to > explicitly state that the beginning-of-list methods are > operationFirst and the end of list methods are operationLast. > > Patch below, full webrev at > http://cr.openjdk.java.net/~darcy/6717780.0/ > > > > > Thanks, > > -Joe > > --- old/src/share/classes/java/util/LinkedList.java > 2010-07-21 > 18:58:12.000000000 -0700 > +++ new/src/share/classes/java/util/LinkedList.java > 2010-07-21 > 18:58:12.000000000 -0700 > @@ -26,14 +26,15 @@ > package java.util; > > /** > - * Linked list implementation of the {@code List} interface. > Implements all > - * optional list operations, and permits all elements > (including > - * {@code null}). In addition to implementing the {@code > List} > interface, > - * the {@code LinkedList} class provides uniformly named > methods to > - * {@code get}, {@code remove} and {@code insert} an > element at the > - * beginning and end of the list. These operations allow > linked > lists to be > - * used as a stack, {@linkplain Queue queue}, or > {@linkplain Deque > - * double-ended queue}. > + * Linked list implementation of the {@code List} interface. > + * Implements all optional list operations, and permits > all elements > + * (including {@code null}). In addition to implementing > the {@code > + * List} interface, the {@code LinkedList} class provides > uniformly > + * named methods to {@code get}, {@code remove} and {@code > add} an > + * element at the beginning (operation{@code > First}) and end > + * (operation{@code Last}) of the list. These > operations > allow > + * linked lists to be used as a stack, {@linkplain Queue > queue}, or > + * {@linkplain Deque double-ended queue}. > * > *

The class implements the {@code Deque} interface, > providing > * first-in-first-out queue operations for {@code add}, > > > > From vincent.x.ryan at oracle.com Fri Jul 23 16:41:36 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 23 Jul 2010 16:41:36 +0000 Subject: hg: jdk7/tl/jdk: 6676075: RegistryContext (com.sun.jndi.url.rmi.rmiURLContext) coding problem Message-ID: <20100723164145.8FF9A47BF7@hg.openjdk.java.net> Changeset: 748f004aeb5c Author: vinnie Date: 2010-07-23 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/748f004aeb5c 6676075: RegistryContext (com.sun.jndi.url.rmi.rmiURLContext) coding problem Reviewed-by: mullan ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java + test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java From martinrb at google.com Fri Jul 23 23:33:36 2010 From: martinrb at google.com (Martin Buchholz) Date: Fri, 23 Jul 2010 16:33:36 -0700 Subject: Micro-summit for core-libs-dev ? Message-ID: A number of us folks who contribute to core libraries (myself, Doug Lea and Joshua Bloch) will be paying a rare visit to the Santa Clara Oracle campus for the JVM languages summit next week. Oracle folks working on core libraries might want to say hi and have informal discussions. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at sun.com Sat Jul 24 15:50:07 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Sat, 24 Jul 2010 15:50:07 +0000 Subject: hg: jdk7/tl/jdk: 6867345: Turkish regional options cause NPE in sun.security.x509.AlgorithmId.algOID Message-ID: <20100724155038.B868B47C36@hg.openjdk.java.net> Changeset: 56217857ccd7 Author: xuelei Date: 2010-07-24 22:59 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/56217857ccd7 6867345: Turkish regional options cause NPE in sun.security.x509.AlgorithmId.algOID Reviewed-by: mullan, weijun ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java + test/sun/security/x509/AlgorithmId/TurkishRegion.java From forax at univ-mlv.fr Sun Jul 25 05:32:09 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 25 Jul 2010 07:32:09 +0200 Subject: Micro-summit for core-libs-dev ? In-Reply-To: References: Message-ID: <4C4BCC59.1010004@univ-mlv.fr> Le 24/07/2010 01:33, Martin Buchholz a ?crit : > A number of us folks who contribute to core libraries (myself, Doug > Lea and Joshua Bloch) will be paying a rare visit to the Santa Clara > Oracle campus for the JVM languages summit next week. Oracle folks > working on core libraries might want to say hi and have informal > discussions. > > Martin I will be here too :) R?mi From weijun.wang at sun.com Mon Jul 26 09:22:52 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Mon, 26 Jul 2010 09:22:52 +0000 Subject: hg: jdk7/tl/jdk: 6972005: ConfPlusProp.java test failure when DNS has info for realm Message-ID: <20100726092335.790C247C8A@hg.openjdk.java.net> Changeset: 402ff3e81922 Author: weijun Date: 2010-07-26 17:21 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/402ff3e81922 6972005: ConfPlusProp.java test failure when DNS has info for realm Reviewed-by: xuelei ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/confplusprop.conf ! test/sun/security/krb5/confplusprop2.conf From martinrb at google.com Mon Jul 26 15:21:14 2010 From: martinrb at google.com (martinrb at google.com) Date: Mon, 26 Jul 2010 15:21:14 +0000 Subject: hg: jdk7/tl/jdk: 6717780: (coll spec) LinkedList api documentation provides the wrong method name Message-ID: <20100726152154.F3E9747C97@hg.openjdk.java.net> Changeset: db21b420d038 Author: martin Date: 2010-07-26 08:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/db21b420d038 6717780: (coll spec) LinkedList api documentation provides the wrong method name Summary: Cleanup by simply making Deque equal status with List Reviewed-by: darcy ! src/share/classes/java/util/LinkedList.java From frances.ho at oracle.com Mon Jul 26 15:43:34 2010 From: frances.ho at oracle.com (Frances Ho) Date: Mon, 26 Jul 2010 08:43:34 -0700 Subject: Micro-summit for core-libs-dev ? In-Reply-To: References: Message-ID: <4C4DAD26.5020601@oracle.com> This is great! Can you let us know what your schedule so I can try to setup a corelib conversation? Thanks. _Frances On 7/23/2010 4:33 PM, Martin Buchholz wrote: > A number of us folks who contribute to core libraries (myself, Doug Lea > and Joshua Bloch) will be paying a rare visit to the Santa Clara Oracle > campus for the JVM languages summit next week. Oracle folks working on > core libraries might want to say hi and have informal discussions. > > Martin From kelly.ohair at oracle.com Mon Jul 26 16:12:15 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 26 Jul 2010 09:12:15 -0700 Subject: Micro-summit for core-libs-dev ? In-Reply-To: <4C4DAD26.5020601@oracle.com> References: <4C4DAD26.5020601@oracle.com> Message-ID: <1CF84106-7B5C-4561-B564-06237ED591EE@oracle.com> Good idea. -kto On Jul 26, 2010, at 8:43 AM, Frances Ho wrote: > > This is great! Can you let us know what your schedule so I can try to > setup a corelib conversation? Thanks. > > _Frances > > > On 7/23/2010 4:33 PM, Martin Buchholz wrote: >> A number of us folks who contribute to core libraries (myself, Doug >> Lea and Joshua Bloch) will be paying a rare visit to the Santa >> Clara Oracle campus for the JVM languages summit next week. Oracle >> folks working on core libraries might want to say hi and have >> informal discussions. >> Martin From jonathan.gibbons at oracle.com Mon Jul 26 21:20:19 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 26 Jul 2010 21:20:19 +0000 Subject: hg: jdk7/tl/langtools: 6971882: Remove -XDstdout from javac test Message-ID: <20100726212021.A24C447CA5@hg.openjdk.java.net> Changeset: 4172cfff05f0 Author: jjg Date: 2010-07-26 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4172cfff05f0 6971882: Remove -XDstdout from javac test Reviewed-by: darcy ! test/tools/javac/4980495/static/Test.java ! test/tools/javac/4980495/std/Test.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6330920/T6330920.java ! test/tools/javac/6491592/T6491592.java ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/CyclicInheritance.java ! test/tools/javac/Digits.java ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendsAccess/ExtendsAccess.java ! test/tools/javac/FloatingPointChanges/BadConstructorModifiers.java ! test/tools/javac/IllegalAnnotation.java ! test/tools/javac/InnerNamedConstant_2.java ! test/tools/javac/InterfaceMemberClassModifiers.java ! test/tools/javac/LocalClasses_2.java ! test/tools/javac/NameCollision.java ! test/tools/javac/NestedInnerClassNames.java ! test/tools/javac/NonStaticFieldExpr1.java ! test/tools/javac/NonStaticFieldExpr2.java ! test/tools/javac/NonStaticFieldExpr3.java ! test/tools/javac/OverridePosition.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_1.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_2.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_3.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.java ! test/tools/javac/StringsInSwitch/NonConstantLabel.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels1.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels2.java ! test/tools/javac/SynchronizedClass.java ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4906100.java ! test/tools/javac/T4994049/T4994049.java ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5024091/T5024091.java ! test/tools/javac/T5048776.java ! test/tools/javac/T6214885.java ! test/tools/javac/T6224167.java ! test/tools/javac/T6227617.java ! test/tools/javac/T6230128.java ! test/tools/javac/T6231847.java ! test/tools/javac/T6241723.java ! test/tools/javac/T6245591.java ! test/tools/javac/T6247324.java ! test/tools/javac/T6394563.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depDocComment/DeprecatedDocComment.java ! test/tools/javac/depDocComment/SuppressDeprecation.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/annotation/Test3.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/depOverrides/doccomment/Test3.java ! test/tools/javac/enum/6384542/T6384542.java ! test/tools/javac/enum/6384542/T6384542a.java ! test/tools/javac/enum/forwardRef/T6425594.java ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/6207386/T6207386.java ! test/tools/javac/generics/6359951/T6359951.java ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/wildcards/6437894/T6437894.java ! test/tools/javac/lint/NoWarn.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/positions/T6253161.java ! test/tools/javac/positions/T6253161a.java ! test/tools/javac/positions/T6264029.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java ! test/tools/javac/rawDiags/Error.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/rawDiags/Warning.java ! test/tools/javac/unicode/UnicodeNewline.java ! test/tools/javac/warnings/Deprecation.java ! test/tools/javac/warnings/DivZero.java ! test/tools/javac/warnings/FallThrough.java ! test/tools/javac/warnings/Unchecked.java From jonathan.gibbons at oracle.com Mon Jul 26 21:26:05 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 26 Jul 2010 21:26:05 +0000 Subject: hg: jdk7/tl/langtools: 6957438: improve code for generating warning messages containing option names Message-ID: <20100726212607.01F5247CA6@hg.openjdk.java.net> Changeset: d1bd93028447 Author: jjg Date: 2010-07-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d1bd93028447 6957438: improve code for generating warning messages containing option names Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! test/tools/javac/diags/examples/CountWarn.java ! test/tools/javac/diags/examples/CountWarnPlural.java ! test/tools/javac/diags/examples/Error.java From daniel.daugherty at oracle.com Mon Jul 26 21:44:18 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 26 Jul 2010 21:44:18 +0000 Subject: hg: jdk7/tl/jdk: 6971847: 4/4 jmap '-histo:live' option is necessary for proper leak detection Message-ID: <20100726214427.EA96F47CA7@hg.openjdk.java.net> Changeset: 1bfa1c864553 Author: dcubed Date: 2010-07-26 09:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bfa1c864553 6971847: 4/4 jmap '-histo:live' option is necessary for proper leak detection Summary: Add work around for 6971851. Abort if 'histo:live' option isn't supported. Reviewed-by: alanb, darcy ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh From xuelei.fan at sun.com Tue Jul 27 08:16:19 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Tue, 27 Jul 2010 08:16:19 +0000 Subject: hg: jdk7/tl/jdk: 6870947: 15 sec delay detecting "socket closed" condition when a TCP connection is reset by an LDAP server Message-ID: <20100727081628.A284B47CC0@hg.openjdk.java.net> Changeset: 83be262e654c Author: xuelei Date: 2010-07-27 16:07 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83be262e654c 6870947: 15 sec delay detecting "socket closed" condition when a TCP connection is reset by an LDAP server Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/Connection.java From vincent.x.ryan at oracle.com Tue Jul 27 11:51:52 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 27 Jul 2010 11:51:52 +0000 Subject: hg: jdk7/tl/jdk: 6972409: Cease emitting LDAP filter debug messages Message-ID: <20100727115223.4B9DE47CC8@hg.openjdk.java.net> Changeset: 5ff8b884a92c Author: vinnie Date: 2010-07-27 11:40 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5ff8b884a92c 6972409: Cease emitting LDAP filter debug messages Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java From jonathan.gibbons at oracle.com Tue Jul 27 18:33:18 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 27 Jul 2010 18:33:18 +0000 Subject: hg: jdk7/tl/langtools: 6972327: JCTree.pos incorrect for annotations without modifiers and package Message-ID: <20100727183322.5C4D247CD7@hg.openjdk.java.net> Changeset: b29160d1b3e0 Author: jjg Date: 2010-07-27 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b29160d1b3e0 6972327: JCTree.pos incorrect for annotations without modifiers and package Reviewed-by: mcimadamore Contributed-by: jan.lahoda at sun.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T6972327.java From jonathan.gibbons at oracle.com Tue Jul 27 18:52:20 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 27 Jul 2010 18:52:20 +0000 Subject: hg: jdk7/tl/langtools: 6403456: -Werror should work with annotation processing Message-ID: <20100727185222.557A547CD8@hg.openjdk.java.net> Changeset: ed354a00f76b Author: jjg Date: 2010-07-27 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ed354a00f76b 6403456: -Werror should work with annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/werror/WError1.java + test/tools/javac/processing/werror/WError1.out + test/tools/javac/processing/werror/WErrorGen.java + test/tools/javac/processing/werror/WErrorGen.out + test/tools/javac/processing/werror/WErrorLast.java + test/tools/javac/processing/werror/WErrorLast.out From martinrb at google.com Tue Jul 27 04:57:56 2010 From: martinrb at google.com (Martin Buchholz) Date: Mon, 26 Jul 2010 21:57:56 -0700 Subject: Micro-summit for core-libs-dev ? In-Reply-To: <4C4DB849.3070001@oracle.com> References: <4C4DB849.3070001@oracle.com> Message-ID: Well, we already had an informal get-together 4pm Monday... I think it might be too hard to set up a formal meeting. Vaguely around 5pm might be a good time to catch people before they go home for the day. Martin On Mon, Jul 26, 2010 at 09:31, Frances Ho wrote: > > First of all, I'm think we'll need a one-hour slot. There are folks > on East Coast who would like to join in so today(Monday) would be out. > Following up with possible time slots for the micro-summit, the schedule > is pretty packed and each workshop slot are already packed with 2 or > more sessions in parallel. > > So please let me know 1) whether you can make either the 8-9am or 5-6pm > slot on Tue or Wed, 2) if there's any scheduled talk slot you can > skip for the corelib conversation and 3) if you're attending what agenda > item you're interested in. I know you guys would be busy all day > but if possible please let me know by COB today and I'll send out email > tonight. > > > Thanks! > > -Frances > > > On 7/23/2010 4:33 PM, Martin Buchholz wrote: > >> A number of us folks who contribute to core libraries (myself, Doug Lea >> and Joshua Bloch) will be paying a rare visit to the Santa Clara Oracle >> campus for the JVM languages summit next week. Oracle folks working on core >> libraries might want to say hi and have informal discussions. >> >> Martin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Thu Jul 29 13:33:59 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 29 Jul 2010 13:33:59 +0000 Subject: hg: jdk7/tl/jdk: 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated; ... Message-ID: <20100729133443.2AFCA47D4C@hg.openjdk.java.net> Changeset: 24741c4bf300 Author: alanb Date: 2010-07-29 13:08 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/24741c4bf300 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated 6799037: (fs) MappedByteBuffer.load crash with unaligned file-mapping (sol) Reviewed-by: chegar, forax ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/windows/native/java/nio/MappedByteBuffer.c ! test/java/nio/MappedByteBuffer/Basic.java + test/java/nio/MappedByteBuffer/Truncate.java From maurizio.cimadamore at oracle.com Thu Jul 29 15:10:31 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 29 Jul 2010 15:10:31 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100729151037.22B5847D56@hg.openjdk.java.net> Changeset: 36c4ec4525b4 Author: mcimadamore Date: 2010-07-29 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/36c4ec4525b4 6938454: Unable to determine generic type in program that compiles under Java 6 Summary: a redundant dubtyping check causes spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6938454/T6938454a.java + test/tools/javac/generics/inference/6938454/T6938454b.java Changeset: e79e8efe1b3e Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e79e8efe1b3e 6972747: CheckExamples fail when assertions are enabled Summary: The test calls the wrong version of JavacMessage constructor Reviewed-by: jjg ! test/tools/javac/diags/Example.java Changeset: 62f3f07002ea Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/62f3f07002ea 6970833: Try-with-resource implementation throws an NPE during Flow analysis Summary: Updated logic not to rely upon Symbol.implementation (which check in superinterfaces) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/TryWithResources/ResourceInterface.java + test/tools/javac/TryWithResources/ResourceInterface.out From chris.hegarty at oracle.com Thu Jul 29 16:05:58 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 29 Jul 2010 16:05:58 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100729160641.ACD2247D59@hg.openjdk.java.net> Changeset: a8a79f5b669e Author: chegar Date: 2010-07-29 10:02 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8a79f5b669e 6972374: NetworkInterface.getNetworkInterfaces throws "java.net.SocketException" on Solaris zone Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c Changeset: d82ed433304e Author: chegar Date: 2010-07-29 17:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d82ed433304e Merge From jonathan.gibbons at oracle.com Fri Jul 30 01:07:23 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Jul 2010 01:07:23 +0000 Subject: hg: jdk7/tl/langtools: 6972556: warning for using a file name instead of a binary name for Filer.createSourceFile Message-ID: <20100730010726.CDE1847D82@hg.openjdk.java.net> Changeset: 4a7979c3ce15 Author: jjg Date: 2010-07-29 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4a7979c3ce15 6972556: warning for using a file name instead of a binary name for Filer.createSourceFile Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ProcSuspiciousClassName/ProcSuspiciousClassName.java + test/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java From jonathan.gibbons at oracle.com Fri Jul 30 02:27:50 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Jul 2010 02:27:50 +0000 Subject: hg: jdk7/tl/langtools: 6340549: javax.tools.JavaCompilerTool.getStandardFileManager().list() includes directories Message-ID: <20100730022752.CF61D47D86@hg.openjdk.java.net> Changeset: 8a5c98a695ae Author: jjg Date: 2010-07-29 19:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8a5c98a695ae 6340549: javax.tools.JavaCompilerTool.getStandardFileManager().list() includes directories Reviewed-by: darcy + test/tools/javac/T6340549.java From jonathan.gibbons at oracle.com Fri Jul 30 02:30:40 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Jul 2010 02:30:40 +0000 Subject: hg: jdk7/tl/langtools: 6966604: JavacFiler not correctly notified of lastRound Message-ID: <20100730023042.5EB2E47D87@hg.openjdk.java.net> Changeset: 2cf925ad67ab Author: jjg Date: 2010-07-29 19:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2cf925ad67ab 6966604: JavacFiler not correctly notified of lastRound Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ProcFileCreateLastRound/ProcFileCreateLastRound.java + test/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java + test/tools/javac/processing/filer/TestLastRound.java + test/tools/javac/processing/filer/TestLastRound.out ! test/tools/javac/processing/werror/WErrorGen.java From lana.steuck at oracle.com Fri Jul 30 06:15:51 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 06:15:51 +0000 Subject: hg: jdk7/tl: 9 new changesets Message-ID: <20100730061551.DB28D47D96@hg.openjdk.java.net> Changeset: 3b147bf5a0e9 Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3b147bf5a0e9 Merge Changeset: b218a53ec7d3 Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/b218a53ec7d3 Merge Changeset: 4193eaf5f1b8 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4193eaf5f1b8 Added tag jdk7-b100 for changeset b218a53ec7d3 ! .hgtags Changeset: 055626b50d2d Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/055626b50d2d Added tag jdk7-b101 for changeset 4193eaf5f1b8 ! .hgtags Changeset: 9cda7c220c08 Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9cda7c220c08 Merge Changeset: a136a51f5113 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/a136a51f5113 Merge Changeset: 86a3df41c0c7 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/86a3df41c0c7 Added tag jdk7-b102 for changeset a136a51f5113 ! .hgtags Changeset: f1ba69da5003 Author: ohair Date: 2010-07-26 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f1ba69da5003 6972274: Fix the use of egrep -ci in the top level makefile sanity checks Reviewed-by: prr ! make/sanity-rules.gmk Changeset: be2aedc4e3b1 Author: mikejwre Date: 2010-07-28 21:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/be2aedc4e3b1 Merge From lana.steuck at oracle.com Fri Jul 30 06:15:57 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 06:15:57 +0000 Subject: hg: jdk7/tl/corba: 7 new changesets Message-ID: <20100730061601.A0C9647D97@hg.openjdk.java.net> Changeset: 8eeca6e452de Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/8eeca6e452de Merge Changeset: a56d734a1e97 Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/a56d734a1e97 Merge Changeset: 86a239832646 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/86a239832646 Added tag jdk7-b100 for changeset a56d734a1e97 ! .hgtags Changeset: d130544adab3 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/d130544adab3 Added tag jdk7-b101 for changeset 86a239832646 ! .hgtags Changeset: 98da66f47273 Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/98da66f47273 Merge Changeset: 78561a957790 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/78561a957790 Merge Changeset: 11e7678c3eb1 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/11e7678c3eb1 Added tag jdk7-b102 for changeset 78561a957790 ! .hgtags From lana.steuck at oracle.com Fri Jul 30 06:20:21 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 06:20:21 +0000 Subject: hg: jdk7/tl/hotspot: 56 new changesets Message-ID: <20100730062156.44E4E47D99@hg.openjdk.java.net> Changeset: e13a5c0ed5e2 Author: prr Date: 2010-06-29 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e13a5c0ed5e2 6964882: 32 bit JDK does not build on 64 bit Windows platforms Reviewed-by: ohair, valeriep ! make/windows/makefiles/defs.make Changeset: ad1977f08c4d Author: mikejwre Date: 2010-06-30 18:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ad1977f08c4d Merge Changeset: 6c3a919105b6 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6c3a919105b6 Added tag jdk7-b100 for changeset ad1977f08c4d ! .hgtags Changeset: 75b254ea860e Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75b254ea860e Added tag jdk7-b101 for changeset 6c3a919105b6 ! .hgtags Changeset: 136b78722a08 Author: jrose Date: 2010-06-09 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/136b78722a08 6939203: JSR 292 needs method handle constants Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType; extend 'ldc' bytecode. Reviewed-by: twisti, never ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeDisassembler.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeInvoke.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciCPCache.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: d93949c5bdcc Author: kvn Date: 2010-06-10 13:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d93949c5bdcc 6730276: JDI_REGRESSION tests fail with "Error: count must be non-zero" error on x86 Summary: Modify assembler code to check for 0 count for all copy routines. Reviewed-by: never, ysr, jcoomes ! src/os_cpu/linux_x86/vm/copy_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/utilities/copy.cpp ! src/share/vm/utilities/copy.hpp Changeset: b918d354830a Author: jrose Date: 2010-06-12 22:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b918d354830a 6960865: ldc of unloaded class throws an assert in ciTypeFlow Summary: Support java_mirror for unloaded klasses, arrays as well as instances. Simplify ciTypeFlow by removing unused path. Reviewed-by: kvn ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciTypeFlow.cpp Changeset: d179e225c164 Author: twisti Date: 2010-06-14 00:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d179e225c164 6960550: Missing semicolon in Zero Summary: There is a missing semicolon in cppInterpreter_zero.cpp. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: 0b4ee1df1b44 Author: never Date: 2010-06-15 12:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0b4ee1df1b44 6952176: Remove debug flag from adlc makefile for 6Update trains Reviewed-by: kvn, twisti ! make/linux/makefiles/adlc.make Changeset: 78fc92dfd4ca Author: never Date: 2010-06-15 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/78fc92dfd4ca Merge Changeset: 2389669474a6 Author: jrose Date: 2010-06-15 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2389669474a6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/thread.cpp Changeset: 4311f23817fd Author: kvn Date: 2010-06-15 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4311f23817fd 6959430: Make sure raw loads have control edge Summary: check that raw loads have control edge Reviewed-by: never, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! 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/parse1.cpp Changeset: 79107c3a6bd5 Author: tonyp Date: 2010-05-07 13:14 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/79107c3a6bd5 6949307: G1: raise a vm error, do not core dump, if target pause time and target interval are inconsistent Summary: First, change the guarantee to raising a vm error. Second, set the interval dynamically, and based on the pause time target, if it is not set explicitly. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 215576b54709 Author: tonyp Date: 2010-04-22 15:20 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/215576b54709 6946048: G1: improvements to +PrintGCDetails output Summary: Small improvements to G1's PrintGCDetails output. It also includes minor formatting details. Reviewed-by: ysr, johnc ! 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/g1RemSet.cpp Changeset: fdde661c8e06 Author: jmasa Date: 2010-06-23 08:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fdde661c8e06 6952853: SIGSEGV with UseAdaptiveGCBoundary on 64b linux running jvm2008 Summary: Shrinking of a generation and the corresponding card table was causing part of the card table to be uncommitted. Reviewed-by: jcoomes ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: 0d781caf0cbb Author: jmasa Date: 2010-06-23 15:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0d781caf0cbb Merge Changeset: b8537b881421 Author: jmasa Date: 2010-06-24 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b8537b881421 Merge Changeset: ff38d05ea86f Author: never Date: 2010-06-18 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ff38d05ea86f 6956958: assert(is_clean() || is_call_to_compiled() || is_call_to_interpreted() || is_optimized() || is_megam Reviewed-by: kvn ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: 38e8278318ca Author: never Date: 2010-06-21 14:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/38e8278318ca 6656830: assert((*p)->is_oop(),"expected an oop while scanning weak refs") Reviewed-by: dcubed, kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 9887b5e57f9e Author: iveresov Date: 2010-06-22 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9887b5e57f9e 6962980: C1: stub area should take into account method handle deopt stub Reviewed-by: twisti, never ! src/share/vm/c1/c1_Compilation.cpp Changeset: 5f249b390094 Author: kvn Date: 2010-06-23 09:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5f249b390094 6947341: JVM Crash running Oracle ATG CRMDemo Summary: Missing protected page below heap with compressed oops on Linux with large pages use. Reviewed-by: never, phh, jcoomes ! src/share/vm/runtime/virtualspace.cpp Changeset: 5a297ea605c7 Author: jrose Date: 2010-06-26 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5a297ea605c7 Merge Changeset: d678e3277048 Author: kvn Date: 2010-06-28 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d678e3277048 6964479: widen normalization of small int and long values should be symmetric Summary: normalize widen value in xmeet() and xdual() methods for types Int and Long so the type meet will be symmetric. Reviewed-by: jrose ! src/share/vm/opto/type.cpp Changeset: 6027dddc26c6 Author: kvn Date: 2010-06-28 14:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6027dddc26c6 6677629: PhaseIterGVN::subsume_node() should call hash_delete() and add_users_to_worklist() Summary: Use replace_node() method instead of subsume_node(). Reviewed-by: jrose, never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp Changeset: 76efbe666d6c Author: kvn Date: 2010-06-29 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/76efbe666d6c 6964774: Adjust optimization flags setting Summary: Adjust performance flags settings. Reviewed-by: never, phh ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: fcbb92a1ab3b Author: jrose Date: 2010-06-29 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fcbb92a1ab3b Merge ! src/share/vm/runtime/arguments.cpp Changeset: 726b40449bd2 Author: zgu Date: 2010-06-22 09:46 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/726b40449bd2 6939019: Source code adjustments for parfait compilation of hotspot Summary: Minor source code adjustments for parfait compilation, since it uses different compiler vs. JDK Reviewed-by: never, kamg ! src/os/solaris/vm/osThread_solaris.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp Changeset: 3e351982aac7 Author: zgu Date: 2010-06-22 10:03 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3e351982aac7 Merge Changeset: 1a11430e0326 Author: jcoomes Date: 2010-06-24 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1a11430e0326 6888573: class data sharing does not always disable large pages Reviewed-by: phh ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c5f1ea9e15e8 Author: coleenp Date: 2010-06-28 12:03 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c5f1ea9e15e8 Merge ! src/share/vm/runtime/arguments.cpp Changeset: a00567c82f02 Author: coleenp Date: 2010-06-30 11:52 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a00567c82f02 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 871d2aa321f7 Author: trims Date: 2010-07-02 01:36 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/871d2aa321f7 Merge Changeset: 7cc68a696c62 Author: trims Date: 2010-07-02 01:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7cc68a696c62 6966252: Bump the HS19 build number to 04 Summary: Update the HS19 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 56cc7e01da2f Author: trims Date: 2010-07-09 00:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/56cc7e01da2f Added tag hs19-b03 for changeset ad1977f08c4d ! .hgtags Changeset: 1dbaff4aa23a Author: trims Date: 2010-07-09 00:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1dbaff4aa23a Merge Changeset: 65b0c03b165d Author: never Date: 2010-07-02 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/65b0c03b165d 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1 Reviewed-by: kvn, dcubed ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp Changeset: 60a14ad85270 Author: kvn Date: 2010-07-02 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/60a14ad85270 6966411: escape.cpp:450 assert(base->Opcode() == Op_ConP Summary: Execute IGVN optimization before and after Escape Analysis Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: a693e51ac197 Author: never Date: 2010-07-07 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a693e51ac197 Merge Changeset: cf647374e044 Author: trims Date: 2010-07-09 00:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cf647374e044 Merge Changeset: a2b581345549 Author: trims Date: 2010-07-15 19:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a2b581345549 Merge ! .hgtags Changeset: b2a00dd3117c Author: jcoomes Date: 2010-07-01 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b2a00dd3117c 6957084: simplify TaskQueue overflow handling Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9ee05c8ab82f Author: ysr Date: 2010-07-12 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9ee05c8ab82f Merge Changeset: bfc89697cccb Author: acorn Date: 2010-07-02 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bfc89697cccb 6964164: MonitorInUseLists leak of contended objects Summary: fix MonitorInUseLists memory leak and MonitorBound now works Reviewed-by: chrisphi, dice ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5087ecc10458 Author: acorn Date: 2010-07-07 14:12 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5087ecc10458 Merge Changeset: 0e7d2a08b605 Author: mchung Date: 2010-07-07 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e7d2a08b605 6967423: Hotspot support for modules image Summary: Add hotspot support for modules image Reviewed-by: acorn ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp Changeset: 1e7ec26380bd Author: apangin Date: 2010-07-14 17:52 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1e7ec26380bd Merge Changeset: 2a47bd84841f Author: never Date: 2010-07-08 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2a47bd84841f 6965184: possible races in make_not_entrant_or_zombie Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp - src/share/vm/runtime/vtune.hpp Changeset: 3941674cc7fa Author: never Date: 2010-07-12 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3941674cc7fa 6958668: repeated uncommon trapping for new of klass which is being initialized Reviewed-by: kvn, jrose ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8d5934a77f10 Author: never Date: 2010-07-12 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8d5934a77f10 6968385: malformed xml in sweeper logging Reviewed-by: kvn ! src/share/vm/runtime/sweeper.cpp Changeset: 079980c86f33 Author: kvn Date: 2010-07-14 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/079980c86f33 6968646: JVM crashes with SIGFPE during startup Summary: Check that cpuid returns valid values for processor topology (not zeros). Reviewed-by: never, twisti ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 8099e71601df Author: kvn Date: 2010-07-14 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8099e71601df 6968368: SIGSEGV in the BCEscapeAnalyzer::copy_dependencies Summary: Use GrowableArray and VectorSet allocated in ciEnv arena. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core Changeset: a528509c992b Author: never Date: 2010-07-15 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a528509c992b 6968336: VM crash guarantee(!nm->is_zombie()) failed: cannot lock a zombie method Reviewed-by: twisti ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp Changeset: 61fdaf88f57f Author: never Date: 2010-07-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/61fdaf88f57f Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: e55900b5c1b8 Author: trims Date: 2010-07-15 19:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e55900b5c1b8 Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp - src/share/vm/runtime/vtune.hpp Changeset: c5cadf1a0771 Author: trims Date: 2010-07-20 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c5cadf1a0771 Merge ! .hgtags Changeset: cb4250ef73b2 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cb4250ef73b2 Added tag jdk7-b102 for changeset c5cadf1a0771 ! .hgtags From lana.steuck at oracle.com Fri Jul 30 06:31:48 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 06:31:48 +0000 Subject: hg: jdk7/tl/jaxp: 7 new changesets Message-ID: <20100730063148.B0C1447D9A@hg.openjdk.java.net> Changeset: 478835e100cd Author: lana Date: 2010-06-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/478835e100cd Merge Changeset: d524be5ef62e Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d524be5ef62e Merge Changeset: 17f62a566a20 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/17f62a566a20 Added tag jdk7-b100 for changeset d524be5ef62e ! .hgtags Changeset: c9bd73f6d584 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c9bd73f6d584 Added tag jdk7-b101 for changeset 17f62a566a20 ! .hgtags Changeset: 70c8a34e2eb6 Author: lana Date: 2010-07-12 19:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/70c8a34e2eb6 Merge Changeset: 15573625af97 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/15573625af97 Merge Changeset: b7722e878864 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/b7722e878864 Added tag jdk7-b102 for changeset 15573625af97 ! .hgtags From lana.steuck at oracle.com Fri Jul 30 06:31:53 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 06:31:53 +0000 Subject: hg: jdk7/tl/jaxws: 7 new changesets Message-ID: <20100730063153.8225747D9B@hg.openjdk.java.net> Changeset: db63f482182d Author: lana Date: 2010-06-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/db63f482182d Merge Changeset: bd26d0ce0c3c Author: lana Date: 2010-06-29 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/bd26d0ce0c3c Merge Changeset: b55ce2744900 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/b55ce2744900 Added tag jdk7-b100 for changeset bd26d0ce0c3c ! .hgtags Changeset: d1525c38428a Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d1525c38428a Added tag jdk7-b101 for changeset b55ce2744900 ! .hgtags Changeset: 2b7a1ec9562e Author: lana Date: 2010-07-12 19:37 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/2b7a1ec9562e Merge Changeset: d8580443d181 Author: lana Date: 2010-07-20 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d8580443d181 Merge Changeset: 267386d6b923 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/267386d6b923 Added tag jdk7-b102 for changeset d8580443d181 ! .hgtags From lana.steuck at oracle.com Fri Jul 30 06:35:09 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 06:35:09 +0000 Subject: hg: jdk7/tl/jdk: 58 new changesets Message-ID: <20100730064427.EA6BE47D9C@hg.openjdk.java.net> Changeset: 4d55419ce99e Author: andrew Date: 2010-06-08 17:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d55419ce99e 6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c Summary: Avoid use of deprecated libpng macro (removed in some 1.4.x releases) Reviewed-by: prr ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: 2574d999704a Author: igor Date: 2010-06-10 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2574d999704a 6952043: Incorrect JNI calls in fontpath.c Reviewed-by: jgodinez, prr ! src/windows/native/sun/font/fontpath.c Changeset: ae887ea4c772 Author: lana Date: 2010-06-10 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae887ea4c772 Merge - make/com/sun/inputmethods/Makefile - make/com/sun/inputmethods/indicim/Makefile - make/com/sun/inputmethods/thaiim/Makefile - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/indicim/DevanagariTables.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethod.java - src/share/classes/com/sun/inputmethods/internal/indicim/IndicInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/indicim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_de.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_es.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_fr.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_it.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ja.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_ko.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_sv.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_CN.properties - src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames_zh_TW.properties - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethod.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodDescriptor.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiInputMethodImpl.java - src/share/classes/com/sun/inputmethods/internal/thaiim/ThaiRules.java - src/share/classes/com/sun/inputmethods/internal/thaiim/java.awt.im.spi.InputMethodDescriptor - src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties - src/share/classes/javax/swing/text/html/parser/html32.bdtd - src/share/classes/sun/security/tools/PolicyTool.java Changeset: 8b55669c7b7a Author: neugens Date: 2010-06-16 20:46 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b55669c7b7a 6961732: FontMetrics.getLeading() may be negative in freetype-based OpenJDK builds. Summary: Fix premature integer roundings to preserve correct height, width and descent values for fonts Reviewed-by: prr ! src/share/native/sun/font/freetypeScaler.c Changeset: 83c7768292d7 Author: prr Date: 2010-06-18 11:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83c7768292d7 6961633: gui applications cause a jvm crash on windows Reviewed-by: ceisserer, bae ! make/sun/pisces/Makefile ! src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine + src/solaris/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine Changeset: 31d25fccdf1c Author: lana Date: 2010-06-21 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31d25fccdf1c Merge Changeset: c02096d7b70e Author: anthony Date: 2010-06-16 11:26 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c02096d7b70e 6959787: java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html failed on 7b94 Summary: Add a delay to the test to make sure the filename filters are called. Reviewed-by: dcherepanov, art ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java Changeset: fa06ad055c43 Author: coffeys Date: 2010-06-16 16:15 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa06ad055c43 6860491: WRAP_TIME_MILLIS incorrectly set Summary: Alter WRAP_TIME_MILLIS to be unsigned Reviewed-by: yan ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 8722b75c9ccd Author: anthony Date: 2010-06-18 17:09 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8722b75c9ccd 6959165: JVM crash during execution FileDialogBufferOverflowTest.html Summary: Add proper synchronization Reviewed-by: art, dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 05eb107d6891 Author: anthony Date: 2010-06-18 17:13 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05eb107d6891 6961754: JCK tests CvsEventTest0001 and CvsEventTest0002 fail under FF 3.5 on OEL 5 Summary: Check the return value of XlibUtil.translateCoordinates() for null Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: ae16c200341a Author: lana Date: 2010-06-21 22:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae16c200341a Merge Changeset: ad5f65797249 Author: rupashka Date: 2010-06-02 11:59 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ad5f65797249 6857057: api/javax_swing/text/GlyphView/index.html#Methods test fails Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java + test/javax/swing/text/WrappedPlainView/6857057/StubBranchElement.java + test/javax/swing/text/WrappedPlainView/6857057/StubLeafElement.java + test/javax/swing/text/WrappedPlainView/6857057/bug6857057.java Changeset: dc14ee238fe3 Author: rupashka Date: 2010-06-02 12:53 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc14ee238fe3 6636983: Japanese text does not display correctly in a JEditorPane Reviewed-by: peterz ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/text/DefaultStyledDocument/6636983/bug6636983.java Changeset: d1c875d94263 Author: lana Date: 2010-06-10 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d1c875d94263 Merge - src/share/classes/sun/security/tools/PolicyTool.java Changeset: 7a3d8fc0d2cd Author: malenkov Date: 2010-06-15 17:39 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7a3d8fc0d2cd 5066685: BorderFactory lacks SoftBevelBorder support Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java Changeset: cf13f6389bdd Author: alexp Date: 2010-06-15 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf13f6389bdd 6788484: NPE in DefaultTableCellHeaderRenderer.getColumnSortOrder() with null table Reviewed-by: rupashka ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java + test/javax/swing/JTable/6788484/bug6788484.java Changeset: 5e4969391538 Author: alexp Date: 2010-06-15 19:10 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e4969391538 6735259: NPE at WindowsComboBoxUI$XPComboBoxButton.getState(WindowsComboBoxUI.java:408) Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java Changeset: cd565c554dc6 Author: alexp Date: 2010-06-15 21:28 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd565c554dc6 6771547: SynthParser throws StringIndexOutOfBoundsException parsing custom ColorTypes Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/javax/swing/plaf/synth/6771547/SynthTest.java + test/javax/swing/plaf/synth/6771547/synthconfig.xml Changeset: 4d93c409ce87 Author: alexp Date: 2010-06-15 21:32 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d93c409ce87 6739756: JToolBar leaves space for non-visible items under Nimbus L&F Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java + test/javax/swing/plaf/synth/SynthToolBarUI/6739756/bug6739756.java Changeset: aaa62c1f221e Author: lana Date: 2010-06-21 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aaa62c1f221e Merge Changeset: 5438223734aa Author: lana Date: 2010-06-21 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5438223734aa Merge Changeset: 10a6319c9c15 Author: lana Date: 2010-06-29 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10a6319c9c15 Merge Changeset: 861213cb02c3 Author: prr Date: 2010-06-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/861213cb02c3 6964882: 32 bit JDK does not build on 64 bit Windows platforms Reviewed-by: ohair, valeriep ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: 511ddf6938ea Author: mikejwre Date: 2010-06-30 18:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/511ddf6938ea Merge Changeset: 820b4e843d51 Author: ohair Date: 2010-07-07 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/820b4e843d51 6967036: Need to fix links with // in Javadoc comments Reviewed-by: mchung ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/sasl/CramMD5Client.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/ExternalClient.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/nio/charset/package.html ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/sun/awt/image/PNGImageDecoder.java Changeset: 93c4e6d14010 Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/93c4e6d14010 Added tag jdk7-b100 for changeset 820b4e843d51 ! .hgtags Changeset: d58354a69011 Author: bpatel Date: 2010-07-14 15:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d58354a69011 6955341: Oracle rebranding changes for man pages Reviewed-by: darcy ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: 6c4450bbad6d Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c4450bbad6d Added tag jdk7-b101 for changeset d58354a69011 ! .hgtags Changeset: c801686d91f4 Author: prr Date: 2010-06-29 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c801686d91f4 6943487: NPE in makeMultiCharsetString while printing on linux Reviewed-by: igor, jgodinez ! src/share/classes/sun/awt/PlatformFont.java ! src/share/classes/sun/java2d/HeadlessGraphicsEnvironment.java Changeset: 4da6837dd085 Author: lana Date: 2010-06-30 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4da6837dd085 Merge Changeset: ab55cb957830 Author: igor Date: 2010-07-06 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ab55cb957830 6967050: JDK build issues with cygwin/vc2010 Reviewed-by: prr, ohair ! make/common/shared/Defs-windows.gmk ! make/mkdemo/Makefile Changeset: e03065fc64e7 Author: igor Date: 2010-07-12 13:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e03065fc64e7 6959998: Return of SurfaceData_InitOps point not checked in all cases (parfait found these) Reviewed-by: prr Contributed-by: ohair ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp Changeset: 2ad69cb576b4 Author: igor Date: 2010-07-12 15:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ad69cb576b4 6968373: FontUtilities static initializer throws AccessControlException Reviewed-by: prr ! src/share/classes/sun/font/FontUtilities.java ! test/java/awt/FontClass/FontPrivilege.java Changeset: 4a639bcd3361 Author: lana Date: 2010-07-12 19:32 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a639bcd3361 Merge Changeset: f5145c7119c2 Author: yan Date: 2010-06-24 11:50 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f5145c7119c2 6957166: With XAWT, set arguments properly creating a MouseWheelEvent. Summary: swap some parameters to allow bigger values for click count. Reviewed-by: dav ! src/solaris/classes/sun/awt/X11/XWindow.java Changeset: bccf2a4ee318 Author: art Date: 2010-07-06 17:59 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bccf2a4ee318 6424157: java.awt.EventQueue push/pop might cause threading issues Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java ! test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java + test/java/awt/EventDispatchThread/PreserveDispathThread/PreserveDispatchThread.java ! test/java/awt/EventQueue/PushPopDeadlock2/PushPopTest.java Changeset: 21b17c64df74 Author: dcherepanov Date: 2010-07-06 18:23 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21b17c64df74 6966643: GTK FileDialog hangs when user manually closes it Reviewed-by: art ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: 9950dc616615 Author: dcherepanov Date: 2010-07-07 14:20 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9950dc616615 6959174: Need to introduce sun.awt.disableGtkFileDialogs system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 48aa2a1edd2b Author: lana Date: 2010-07-08 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48aa2a1edd2b Merge Changeset: 2d8f060dd1c5 Author: lana Date: 2010-07-12 19:33 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2d8f060dd1c5 Merge Changeset: 69ddf06e616a Author: malenkov Date: 2010-06-22 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69ddf06e616a 6707234: Method returned by Introspector.internalFindMethod not necessarily most specific Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test6707234.java Changeset: 5af3b0430bbe Author: peterz Date: 2010-06-22 14:36 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5af3b0430bbe 6959260: javax/swing/JLabel/6501991/bug6501991.java failed on build 1.7.0-ea-b96 Reviewed-by: rupashka ! src/share/classes/sun/swing/SwingUtilities2.java ! test/ProblemList.txt ! test/com/sun/java/swing/plaf/gtk/Test6635110.java Changeset: dea63f6dda7a Author: alexp Date: 2010-06-22 19:38 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dea63f6dda7a 6777378: NullPointerException in XPDefaultRenderer.paint() Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java + test/javax/swing/JTable/6777378/bug6777378.java Changeset: a05e047c5b98 Author: alexp Date: 2010-06-22 20:36 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a05e047c5b98 6684401: JTree isExpanded should not call itself recursively Reviewed-by: rupashka ! src/share/classes/javax/swing/JTree.java Changeset: f1bafc4f249d Author: peterz Date: 2010-06-29 14:42 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1bafc4f249d 6963870: NPE in CompoundBorder.getInsets() Reviewed-by: alexp Contributed-by: jon.vanalten at redhat.com ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java + test/com/sun/java/swing/plaf/gtk/Test6963870.java Changeset: c0e785f055a7 Author: lana Date: 2010-06-30 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c0e785f055a7 Merge ! test/ProblemList.txt Changeset: d062afbe2107 Author: malenkov Date: 2010-07-01 18:09 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d062afbe2107 4129681: Cannot get a title border to display its label as disabled Reviewed-by: alexp, rupashka ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test4129681.html + test/javax/swing/border/Test4129681.java + test/javax/swing/border/Test4760089.html + test/javax/swing/border/Test4760089.java Changeset: 46306a419ba3 Author: malenkov Date: 2010-07-01 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/46306a419ba3 6959266: test javax/swing/JInternalFrame/6725409/bug6725409.java should be modified Reviewed-by: alexp ! test/javax/swing/JInternalFrame/6725409/bug6725409.java Changeset: e94a94d176f9 Author: alexp Date: 2010-07-02 19:28 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e94a94d176f9 6711682: JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java + test/javax/swing/AbstractButton/6711682/bug6711682.java Changeset: 46d5aef470a3 Author: alexp Date: 2010-07-02 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/46d5aef470a3 6937415: Some components return undocumented default values under Nimbus LaF Reviewed-by: peterz ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf Changeset: e12c92d2dc11 Author: rupashka Date: 2010-07-08 19:09 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e12c92d2dc11 6520101: FileChooser will cause OutOfMemory when application will run long time Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java + test/javax/swing/JFileChooser/6520101/bug6520101.java Changeset: d0bcc9aa5a7a Author: malenkov Date: 2010-07-09 19:42 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d0bcc9aa5a7a 6894597: test/closed/javax/swing/JPopupMenu/6495920/bug6495920.java fails Reviewed-by: alexp, peterz + test/javax/swing/JPopupMenu/6495920/bug6495920.java Changeset: 3dc686ecb4cd Author: malenkov Date: 2010-07-09 22:07 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3dc686ecb4cd 6963811: Deadlock-prone locking changes in Introspector Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/InstanceFinder.java ! src/share/classes/com/sun/beans/finder/PersistenceDelegateFinder.java ! src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + test/java/beans/Introspector/Test6963811.java + test/java/beans/PropertyEditor/Test6963811.java + test/java/beans/XMLEncoder/Test6963811.java Changeset: a93a7ed5018c Author: lana Date: 2010-07-12 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a93a7ed5018c Merge Changeset: c5a436f053aa Author: lana Date: 2010-07-12 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c5a436f053aa Merge ! test/ProblemList.txt - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 13029a61b16b Author: lana Date: 2010-07-20 22:21 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/13029a61b16b Merge - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 6488b70a23cc Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6488b70a23cc Added tag jdk7-b102 for changeset 13029a61b16b ! .hgtags Changeset: 48e6f4807e5f Author: lana Date: 2010-07-29 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/48e6f4807e5f Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! test/ProblemList.txt From lana.steuck at oracle.com Fri Jul 30 07:00:21 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 30 Jul 2010 07:00:21 +0000 Subject: hg: jdk7/tl/langtools: 8 new changesets Message-ID: <20100730070034.DE75947D9E@hg.openjdk.java.net> Changeset: 4cca8d7ce6c1 Author: lana Date: 2010-06-21 22:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4cca8d7ce6c1 Merge Changeset: d1d7595fa824 Author: lana Date: 2010-06-29 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d1d7595fa824 Merge ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 20a8fe72ee7b Author: mikejwre Date: 2010-07-09 19:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/20a8fe72ee7b Added tag jdk7-b100 for changeset d1d7595fa824 ! .hgtags Changeset: f87f1f3e23e1 Author: mikejwre Date: 2010-07-15 20:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f87f1f3e23e1 Added tag jdk7-b101 for changeset 20a8fe72ee7b ! .hgtags Changeset: eaab979c8b36 Author: lana Date: 2010-07-12 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/eaab979c8b36 Merge Changeset: ff9c0a0bf7ed Author: lana Date: 2010-07-20 22:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ff9c0a0bf7ed Merge Changeset: bd85271c580c Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bd85271c580c Added tag jdk7-b102 for changeset ff9c0a0bf7ed ! .hgtags Changeset: 077eb94c912d Author: lana Date: 2010-07-29 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/077eb94c912d Merge From David.Holmes at oracle.com Fri Jul 30 12:26:11 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 30 Jul 2010 22:26:11 +1000 Subject: hotpot run two many bytecodes when startup In-Reply-To: References: Message-ID: <4C52C4E3.1020307@oracle.com> Hi, Try comparing the list of classes that gets loaded. This is a library issue not a VM issue (so I bcc'ed hotspot-dev). The folks on core-libs-dev (cc'ed) will have a better idea on the startup process for the class libraries. David Holmes Yongqiang Yang said the following on 07/30/10 18:08: > > hi, > > I am porting openjdk6 to MIPS. When i finished, I only typed > command "java", but the hotspot ran 1,650,000 bytecodes. jdk1.5 run > only about 240,000 bytecodes. > > What probably will get rise to this scenario? > -- > Best Wishes > Yongqiang Yang > From Alan.Bateman at oracle.com Fri Jul 30 13:13:46 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Jul 2010 14:13:46 +0100 Subject: hotpot run two many bytecodes when startup In-Reply-To: <4C52C4E3.1020307@oracle.com> References: <4C52C4E3.1020307@oracle.com> Message-ID: <4C52D00A.409@oracle.com> David Holmes wrote: > Hi, > > Try comparing the list of classes that gets loaded. This is a library > issue not a VM issue (so I bcc'ed hotspot-dev). The folks on > core-libs-dev (cc'ed) will have a better idea on the startup process > for the class libraries. > > David Holmes As David suggests, then running with -verbose will let you see the list of classes that are loaded. Their static initializers might give you an idea on the code that is running. There are lots of tools that you could use to investigate it further. For something really quick, then look at the simple method tracer in demo/lib/jvmti/mtrace. -Alan. From mandy.chung at oracle.com Fri Jul 30 18:24:00 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Jul 2010 11:24:00 -0700 Subject: jvm load too many classes In-Reply-To: References: Message-ID: <4C5318C0.1050006@oracle.com> Yongqiang Yang wrote: > hi, > > I just type command "java" under openjdk1.6, then the jvm will > load 308 classes, including > java/launcher/LauncherHelp, > java/util/ResourceBundle, > java/util/Currency, > java/util/Locale, > java/net/URL > > > When I use jdk1.5, the jvm just load about 180 classes, not > including the classes above. > > > Could someone figure out something wrong? New features and bug fixes in a new release could lead to more classes get loaded at startup. We have done some work to lazily load classes if appropriate (see CR 6798873: Reduce the number of classes loaded and class dependencies). Mandy From opinali at gmail.com Fri Jul 30 18:41:59 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Fri, 30 Jul 2010 15:41:59 -0300 Subject: jvm load too many classes In-Reply-To: <4C5318C0.1050006@oracle.com> References: <4C5318C0.1050006@oracle.com> Message-ID: I wonder if these numbers have some variation per platform? For me (on Windows; 32-bit JDKs), the results of this test (java -verbose:class | grep Loaded | wc -l) are: 1.5.0_22: 239 1.6.0_21: 274 1.7.0-ea-b103: 403 The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a heavy regression... FWIW for such a simple test. For one thing, these core-boot classes all come off the CDS file so their classloading effort is relatively very small, and the delta will certainly be much smaller for even the smallest real-world app. A+ Osvaldo 2010/7/30 Mandy Chung : > Yongqiang Yang wrote: >> >> hi, >> >> ? ? I just type command "java" under openjdk1.6, then the jvm will load >> 308 classes, including ? ? ? ? ? ? java/launcher/LauncherHelp, >> ? ? ? ? ? ?java/util/ResourceBundle, >> ? ? ? ? ? ?java/util/Currency, >> ? ? ? ? ? ?java/util/Locale, >> ? ? ? ? ? ?java/net/URL >> >> ? ? ? ?When I use jdk1.5, the jvm just load about 180 classes, not >> including the classes above. >> >> ? ? ? ?Could someone figure out something wrong? > > New features and bug fixes in a new release could lead to more classes get > loaded at startup. ?We have done some work to lazily load classes if > appropriate (see CR 6798873: Reduce the number of classes loaded and class > dependencies). > > Mandy > > From iaroslavski at mail.ru Fri Jul 30 18:55:00 2010 From: iaroslavski at mail.ru (Vladimir Iaroslavski) Date: Fri, 30 Jul 2010 22:55:00 +0400 Subject: Question on sorting Message-ID: Hello, I have performance question in sorting. In an implementation of Dual-Pivot Quicksort 5 elements a[e1], a[e2], a[e3], a[e4], a[e5] where e1 = len/6, e2 = len/3, e3 = len/2, e4 = len*2/3, e5 = len*5/6, are sorted and then elements a[e2], a[e4] are taken as pivots. but if I take a[e1] and a[e3] as pivots, it works 2-3% faster on *random* inputs. I tried different sorting for these 5 elements: network, bubble, insertion - with a[e1] and a[e3] pivots it is faster than with a[e2] and a[e4]. If I sort these 5 elements in descending order, it works faster with a[e5] and a[e3] pivots. Do you have any idea why it happens? Thank you, Vladimir From mandy.chung at oracle.com Fri Jul 30 19:59:45 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Jul 2010 12:59:45 -0700 Subject: jvm load too many classes In-Reply-To: References: <4C5318C0.1050006@oracle.com> Message-ID: <4C532F31.5040207@oracle.com> Osvaldo Doederlein wrote: > I wonder if these numbers have some variation per platform? Yes, there are some platform-dependent classes and so some loaded classes are different on different platform. > For me (on > Windows; 32-bit JDKs), the results of this test (java -verbose:class | > grep Loaded | wc -l) are: > > 1.5.0_22: 239 > 1.6.0_21: 274 > 1.7.0-ea-b103: 403 > > I ran the helloworld. The number of loaded classes running different jdk versions are fairly close. What test case did you use? $ grep Loaded hw.verbose.jdk5u22 | wc -l 303 $ grep Loaded hw.verbose.jdk6u21 | wc -l 323 $ grep Loaded hw.verbose.jdk7 | wc -l 329 > The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a > heavy regression... FWIW for such a simple test. For one thing, these > core-boot classes all come off the CDS file so their classloading > effort is relatively very small, and the delta will certainly be much > smaller for even the smallest real-world app. > Right. -verbose:class prints out all loaded classes regardless of coming from CDS archive or not. The number of loaded classes is one metric to the startup while class loading time + clinit time are other important metrics. So these loaded classes has small impact to the startup time especially with CDS is enabled. Mandy > A+ > Osvaldo > > 2010/7/30 Mandy Chung : > >> Yongqiang Yang wrote: >> >>> hi, >>> >>> I just type command "java" under openjdk1.6, then the jvm will load >>> 308 classes, including java/launcher/LauncherHelp, >>> java/util/ResourceBundle, >>> java/util/Currency, >>> java/util/Locale, >>> java/net/URL >>> >>> When I use jdk1.5, the jvm just load about 180 classes, not >>> including the classes above. >>> >>> Could someone figure out something wrong? >>> >> New features and bug fixes in a new release could lead to more classes get >> loaded at startup. We have done some work to lazily load classes if >> appropriate (see CR 6798873: Reduce the number of classes loaded and class >> dependencies). >> >> Mandy >> >> >> From michael.x.mcmahon at oracle.com Fri Jul 30 17:17:18 2010 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Fri, 30 Jul 2010 17:17:18 +0000 Subject: hg: jdk7/tl/jdk: 6510892: com/sun/net/httpserver/bugs/B6361557.java fails Message-ID: <20100730171728.1DD8347DBB@hg.openjdk.java.net> Changeset: 4d72d0ec83f5 Author: michaelm Date: 2010-07-30 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d72d0ec83f5 6510892: com/sun/net/httpserver/bugs/B6361557.java fails Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6361557.java From David.Holmes at oracle.com Sat Jul 31 06:03:57 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 31 Jul 2010 16:03:57 +1000 Subject: jvm load too many classes In-Reply-To: References: <4C5318C0.1050006@oracle.com> <4C532F31.5040207@oracle.com> Message-ID: <4C53BCCD.1050500@oracle.com> Did you try the same test on a regular JDK platform? This is likely due to changes in the class libraries. Such a change might be very noticeable for a "no-op" test (ie not running any application class) but may not be so significant for an actual test case. For example, if you do "java Foo" (where there is no class Foo) in 1.5 you get a single println: Exception in thread "main" java.lang.NoClassDefFoundError: Foo whereas in 1.6 and JDK 7 you will get a stack dump from the exception: Exception in thread "main" java.lang.NoClassDefFoundError: Foo Caused by: java.lang.ClassNotFoundException: Foo at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: Foo. Program will exit. This might require loading many additional I/O and character set related classes. Just a hypothesis - I haven't checked it. David Holmes ------------ Yongqiang Yang said the following on 07/31/10 15:48: > I am porting openjdk1.6 to MIPS. I have finished, but opendk1.6 is four > times slower than jdk1.5 at startup. Two versions ran on the same > MIPS machine . > > During startup, openjdk1.6 runs 1,650,000 bytecodes while jdk1.5 runs > about 240,000 bytecodes. > > On Sat, Jul 31, 2010 at 3:59 AM, Mandy Chung > wrote: > > Osvaldo Doederlein wrote: > > I wonder if these numbers have some variation per platform? > > > Yes, there are some platform-dependent classes and so some loaded > classes are different on different platform. > > > For me (on > Windows; 32-bit JDKs), the results of this test (java > -verbose:class | > grep Loaded | wc -l) are: > > 1.5.0_22: 239 > 1.6.0_21: 274 > 1.7.0-ea-b103: 403 > > > > I ran the helloworld. The number of loaded classes running different jdk > versions are fairly close. What test case did you use? > > $ grep Loaded hw.verbose.jdk5u22 | wc -l > 303 > > $ grep Loaded hw.verbose.jdk6u21 | wc -l > 323 > > $ grep Loaded hw.verbose.jdk7 | wc -l > 329 > > > > The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to > be a > heavy regression... FWIW for such a simple test. For one thing, > these > core-boot classes all come off the CDS file so their classloading > effort is relatively very small, and the delta will certainly be > much > smaller for even the smallest real-world app. > > > Right. -verbose:class prints out all loaded classes regardless of > coming from CDS archive or not. The number of loaded classes is one > metric to the startup while class loading time + clinit time are > other important metrics. So these loaded classes has small impact > to the startup time especially with CDS is enabled. > > Mandy > > > A+ > Osvaldo > > 2010/7/30 Mandy Chung >: > > > Yongqiang Yang wrote: > > > hi, > > I just type command "java" under openjdk1.6, then the > jvm will load > 308 classes, including > java/launcher/LauncherHelp, > java/util/ResourceBundle, > java/util/Currency, > java/util/Locale, > java/net/URL > > When I use jdk1.5, the jvm just load about 180 > classes, not > including the classes above. > > Could someone figure out something wrong? > > > New features and bug fixes in a new release could lead to > more classes get > loaded at startup. We have done some work to lazily load > classes if > appropriate (see CR 6798873: Reduce the number of classes > loaded and class > dependencies). > > Mandy > > > > > > > > > -- > Best Wishes > Yongqiang Yang > From xiaoqiangnk at gmail.com Fri Jul 30 13:01:30 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Fri, 30 Jul 2010 21:01:30 +0800 Subject: jvm load too many classes Message-ID: hi, I just type command "java" under openjdk1.6, then the jvm will load 308 classes, including java/launcher/LauncherHelp, java/util/ResourceBundle, java/util/Currency, java/util/Locale, java/net/URL When I use jdk1.5, the jvm just load about 180 classes, not including the classes above. Could someone figure out something wrong? Thank you! -- Best Wishes Yongqiang Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoqiangnk at gmail.com Sat Jul 31 05:48:20 2010 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Sat, 31 Jul 2010 13:48:20 +0800 Subject: jvm load too many classes In-Reply-To: <4C532F31.5040207@oracle.com> References: <4C5318C0.1050006@oracle.com> <4C532F31.5040207@oracle.com> Message-ID: I am porting openjdk1.6 to MIPS. I have finished, but opendk1.6 is four times slower than jdk1.5 at startup. Two versions ran on the same MIPS machine . During startup, openjdk1.6 runs 1,650,000 bytecodes while jdk1.5 runs about 240,000 bytecodes. On Sat, Jul 31, 2010 at 3:59 AM, Mandy Chung wrote: > Osvaldo Doederlein wrote: > >> I wonder if these numbers have some variation per platform? >> > > Yes, there are some platform-dependent classes and so some loaded > classes are different on different platform. > > > For me (on >> Windows; 32-bit JDKs), the results of this test (java -verbose:class | >> grep Loaded | wc -l) are: >> >> 1.5.0_22: 239 >> 1.6.0_21: 274 >> 1.7.0-ea-b103: 403 >> >> >> > I ran the helloworld. The number of loaded classes running different jdk > versions are fairly close. What test case did you use? > > $ grep Loaded hw.verbose.jdk5u22 | wc -l > 303 > > $ grep Loaded hw.verbose.jdk6u21 | wc -l > 323 > > $ grep Loaded hw.verbose.jdk7 | wc -l > 329 > > > > The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a >> heavy regression... FWIW for such a simple test. For one thing, these >> core-boot classes all come off the CDS file so their classloading >> effort is relatively very small, and the delta will certainly be much >> smaller for even the smallest real-world app. >> >> > Right. -verbose:class prints out all loaded classes regardless of coming > from CDS archive or not. The number of loaded classes is one > metric to the startup while class loading time + clinit time are other > important metrics. So these loaded classes has small impact > to the startup time especially with CDS is enabled. > > Mandy > > > A+ >> Osvaldo >> >> 2010/7/30 Mandy Chung : >> >> >>> Yongqiang Yang wrote: >>> >>> >>>> hi, >>>> >>>> I just type command "java" under openjdk1.6, then the jvm will load >>>> 308 classes, including java/launcher/LauncherHelp, >>>> java/util/ResourceBundle, >>>> java/util/Currency, >>>> java/util/Locale, >>>> java/net/URL >>>> >>>> When I use jdk1.5, the jvm just load about 180 classes, not >>>> including the classes above. >>>> >>>> Could someone figure out something wrong? >>>> >>>> >>> New features and bug fixes in a new release could lead to more classes >>> get >>> loaded at startup. We have done some work to lazily load classes if >>> appropriate (see CR 6798873: Reduce the number of classes loaded and >>> class >>> dependencies). >>> >>> Mandy >>> >>> >>> >>> >> > -- Best Wishes Yongqiang Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sat Jul 31 20:31:39 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 31 Jul 2010 22:31:39 +0200 Subject: jvm load too many classes In-Reply-To: <4C532F31.5040207@oracle.com> References: <4C5318C0.1050006@oracle.com> <4C532F31.5040207@oracle.com> Message-ID: <4C54882B.8070808@univ-mlv.fr> Le 30/07/2010 21:59, Mandy Chung a ?crit : > Osvaldo Doederlein wrote: >> I wonder if these numbers have some variation per platform? > > Yes, there are some platform-dependent classes and so some loaded > classes are different on different platform. > >> For me (on >> Windows; 32-bit JDKs), the results of this test (java -verbose:class | >> grep Loaded | wc -l) are: >> >> 1.5.0_22: 239 >> 1.6.0_21: 274 >> 1.7.0-ea-b103: 403 >> > I ran the helloworld. The number of loaded classes running different jdk > versions are fairly close. What test case did you use? > > $ grep Loaded hw.verbose.jdk5u22 | wc -l > 303 > > $ grep Loaded hw.verbose.jdk6u21 | wc -l > 323 > > $ grep Loaded hw.verbose.jdk7 | wc -l > 329 There is a big diff (at least on linux) if you just try to print the help of the VM, i.e pass no argument. jdk1.6.0_21: 274 classes jdk1.7.0b103: 364 classes I join the diff. Some classes of java.text.*, java.util.ResourceBundle* and some classes related to locale and currency are loaded eagerly. R?mi > > >> The diff from 1.5 to 1.6 is not bad, but JDK7 seems right now to be a >> heavy regression... FWIW for such a simple test. For one thing, these >> core-boot classes all come off the CDS file so their classloading >> effort is relatively very small, and the delta will certainly be much >> smaller for even the smallest real-world app. > Right. -verbose:class prints out all loaded classes regardless of > coming from CDS archive or not. The number of loaded classes is one > metric to the startup while class loading time + clinit time are other > important metrics. So these loaded classes has small impact > to the startup time especially with CDS is enabled. > > Mandy > >> A+ >> Osvaldo >> >> 2010/7/30 Mandy Chung : >>> Yongqiang Yang wrote: >>>> hi, >>>> >>>> I just type command "java" under openjdk1.6, then the jvm will >>>> load >>>> 308 classes, including java/launcher/LauncherHelp, >>>> java/util/ResourceBundle, >>>> java/util/Currency, >>>> java/util/Locale, >>>> java/net/URL >>>> >>>> When I use jdk1.5, the jvm just load about 180 classes, not >>>> including the classes above. >>>> >>>> Could someone figure out something wrong? >>> New features and bug fixes in a new release could lead to more >>> classes get >>> loaded at startup. We have done some work to lazily load classes if >>> appropriate (see CR 6798873: Reduce the number of classes loaded and >>> class >>> dependencies). >>> >>> Mandy >>> >>> > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk.diff URL: