From Ulf.Zibis at gmx.de Mon Sep 1 10:19:55 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 01 Sep 2008 19:19:55 +0200 Subject: Enhance footprint for array initialization Message-ID: <48BC243B.7050503@gmx.de> I my code I have following array initialization: (from: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/sun_io_CharacterEncoding_using_String[][]/src/sun/io/CharacterEncoding.java?rev=&view=markup) private static final String[][] extendedAliasMappings = { {"8859_1", "ISO8859_1"}, {"iso_8859-1:1987", "ISO8859_1"}, {"iso-ir-100", "ISO8859_1"}, {"iso_8859-1", "ISO8859_1"}, // + 475 more pairs ... } In the class file the following block is repeated 475 times: (from: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/sun_io_CharacterEncoding_using_String%5B%5D%5B%5D/docs/javap.out/javap%20CharacterEncoding(String%5B%5D%5B%5D).out?rev=&view=markup) 874: dup 875: iconst_0 876: iconst_2 877: anewarray #10; //class java/lang/String 880: dup 881: iconst_0 882: ldc #40; //String 8859_1 884: aastore 885: dup 886: iconst_1 887: ldc #41; //String ISO8859_1 889: aastore 890: aastore IMHO it would be better, to initialize the String[][] by a loop, instead inlining those bytecodes 475 times. This would considerably decrease the footprint of the class file. Is there any chance, we could have this in the future? Regards, -Ulf From Ulf.Zibis at gmx.de Mon Sep 1 10:24:46 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 01 Sep 2008 19:24:46 +0200 Subject: Enhance footprint for array initialization In-Reply-To: <48BC243B.7050503@gmx.de> References: <48BC243B.7050503@gmx.de> Message-ID: <48BC255E.20400@gmx.de> corrected the 1st link: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/sun_io_CharacterEncoding_using_String%5B%5D%5B%5D/src/sun/io/CharacterEncoding.java?rev=&view=markup) -Ulf From Thomas.Rodriguez at Sun.COM Tue Sep 2 08:32:31 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 02 Sep 2008 08:32:31 -0700 Subject: Enhance footprint for array initialization In-Reply-To: <48BC243B.7050503@gmx.de> References: <48BC243B.7050503@gmx.de> Message-ID: <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> I think you're on the wrong list. This is a javac code generation issue. I think you want compiler-dev at openjdk.java.net. tom On Sep 1, 2008, at 10:19 AM, Ulf Zibis wrote: > I my code I have following array initialization: > (from: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/sun_io_CharacterEncoding_using_String > [][]/src/sun/io/CharacterEncoding.java?rev=&view=markup) > > private static final String[][] extendedAliasMappings = { > {"8859_1", "ISO8859_1"}, > {"iso_8859-1:1987", "ISO8859_1"}, > {"iso-ir-100", "ISO8859_1"}, > {"iso_8859-1", "ISO8859_1"}, > // + 475 more pairs ... > } > > In the class file the following block is repeated 475 times: > (from: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/sun_io_CharacterEncoding_using_String%5B%5D%5B%5D/docs/javap.out/javap%20CharacterEncoding(String%5B%5D%5B%5D).out?rev=&view=markup) > > 874: dup > 875: iconst_0 > 876: iconst_2 > 877: anewarray #10; //class java/lang/String > 880: dup > 881: iconst_0 > 882: ldc #40; //String 8859_1 > 884: aastore > 885: dup > 886: iconst_1 > 887: ldc #41; //String ISO8859_1 > 889: aastore > 890: aastore > > IMHO it would be better, to initialize the String[][] by a loop, > instead inlining those bytecodes 475 times. This would considerably > decrease the footprint of the class file. > > Is there any chance, we could have this in the future? > > Regards, > > -Ulf > > From chuck.rasbold at sun.com Tue Sep 2 10:13:43 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Tue, 02 Sep 2008 17:13:43 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20080902171401.3852DD081@hg.openjdk.java.net> Changeset: fa4d1d240383 Author: never Date: 2008-08-26 15:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fa4d1d240383 6741642: bad enum definition in ciTypeFlow.hpp Reviewed-by: rasbold, martin Contributed-by: doko at ubuntu.com ! src/share/vm/ci/ciTypeFlow.hpp Changeset: dc7f315e41f7 Author: never Date: 2008-08-27 00:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dc7f315e41f7 5108146: Merge i486 and amd64 cpu directories 6459804: Want client (c1) compiler for x86_64 (amd64) for faster start-up Reviewed-by: kvn + make/solaris/makefiles/reorder_COMPILER1_amd64 ! make/solaris/makefiles/reorder_COMPILER1_i486 ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp + src/cpu/x86/vm/assembler_x86.cpp + src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/assembler_x86.inline.hpp - src/cpu/x86/vm/assembler_x86_32.cpp - src/cpu/x86/vm/assembler_x86_32.hpp - src/cpu/x86/vm/assembler_x86_32.inline.hpp - src/cpu/x86/vm/assembler_x86_64.cpp - src/cpu/x86/vm/assembler_x86_64.hpp - src/cpu/x86/vm/assembler_x86_64.inline.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Defs_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/dump_x86_32.cpp ! src/cpu/x86/vm/dump_x86_64.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86_32.cpp ! src/cpu/x86/vm/vm_version_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp + src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad + src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: ab075d07f1ba Author: kvn Date: 2008-08-27 09:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ab075d07f1ba 6736417: Fastdebug C2 crashes in StoreBNode::Ideal Summary: The result of step_through_mergemem() and remove_dead_region() is not checked in some cases. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp Changeset: af945ba2e739 Author: kvn Date: 2008-08-27 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/af945ba2e739 6741738: TypePtr::add_offset() set incorrect offset when the add overflows Summary: Set offset to OffsetBot when the add overflows in TypePtr::add_offset() Reviewed-by: jrose, never ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6741738/Tester.java Changeset: 892493c3d862 Author: kvn Date: 2008-08-27 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/892493c3d862 6732732: CTW with EA: assert(n != 0L,"Bad immediate dominator info.") Summary: Missing edge to a call's return value in EA Connection Graph. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 756b58154237 Author: rasbold Date: 2008-08-28 10:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/756b58154237 6611837: block frequency is zero Summary: insert_goto_at should set frequency for newly created blocks Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/gcm.cpp Changeset: eaf496ad4a14 Author: never Date: 2008-08-28 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eaf496ad4a14 6732698: crash with dead code from compressed oops in gcm Reviewed-by: rasbold ! src/share/vm/opto/matcher.cpp Changeset: cf6f0e32e518 Author: rasbold Date: 2008-09-02 06:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cf6f0e32e518 Merge - src/cpu/x86/vm/assembler_x86_32.cpp - src/cpu/x86/vm/assembler_x86_32.hpp - src/cpu/x86/vm/assembler_x86_32.inline.hpp - src/cpu/x86/vm/assembler_x86_64.cpp - src/cpu/x86/vm/assembler_x86_64.hpp - src/cpu/x86/vm/assembler_x86_64.inline.hpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp From charles.nutter at sun.com Tue Sep 2 11:50:07 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 02 Sep 2008 13:50:07 -0500 Subject: NewRatio: to twiddle or not to twiddle Message-ID: <48BD8ADF.6070302@sun.com> I've ben playing with JRuby on various benchmarks recently and found that several object-intensive scripts run better if I set NewRatio=1. Ruby, even more than Java, tends to generate lots and lots of objects, especially considering that there's no unboxed primitive numeric types (and no fixnums on the JVM...ahem ahem). So my general theory is that: 1. A NewRatio of 1 allows all those extra transient objects to get collected more quickly. 2. Too small a "new" generation causes transient objects to get shoved into older generations, potentially snowballing and forcing more comprehensive GC runs as time goes on. I'm curious whether this theory sounds reasonable, whether there's a better way I can adapt hotspot to the memory demands of a dynamic language like Ruby, and what other implications there are in setting NewRatio to 1. Thoughts? (And please let me know if there's a better list to post this sort of question to) - Charlie From Paul.Hohensee at Sun.COM Tue Sep 2 12:25:55 2008 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 02 Sep 2008 15:25:55 -0400 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BD8ADF.6070302@sun.com> References: <48BD8ADF.6070302@sun.com> Message-ID: <48BD9343.6000407@sun.com> You probably want hotspot-gc-use at openjdk.java.net. A NewRatio of 1 means that half the heap is young gen. The default for the server vm is 2 (1/3 the heap is young gen) and for the client vm it's 12 on x86 and 8 on sparc. I.e., much smaller young gen for client. 1. A NewRatio of 1 doesn't allow transient objects to get collected more quickly, it allows them time to die in the young gen and thus not get collected at all. The bigger the young gen, the longer the interval between collections, and the more time for transient objects to die. 2. Is correct. You can increase the amount of time transient objects have to die by increasing MaxTenuringThreshold. It can have values between 0 and 15, and is the number of times an object must survive a young gen collection before being promoted to the old gen. The survivor spaces in the young gen must be large enough to contain everything that's live in the young gen, else the excess gets promoted before its time. So check out lower values of SurvivorRatio as well: lower values increase the size of the survivor spaces. Paul Charles Oliver Nutter wrote: > I've ben playing with JRuby on various benchmarks recently and found > that several object-intensive scripts run better if I set NewRatio=1. > Ruby, even more than Java, tends to generate lots and lots of objects, > especially considering that there's no unboxed primitive numeric types > (and no fixnums on the JVM...ahem ahem). So my general theory is that: > > 1. A NewRatio of 1 allows all those extra transient objects to get > collected more quickly. > 2. Too small a "new" generation causes transient objects to get shoved > into older generations, potentially snowballing and forcing more > comprehensive GC runs as time goes on. > > I'm curious whether this theory sounds reasonable, whether there's a > better way I can adapt hotspot to the memory demands of a dynamic > language like Ruby, and what other implications there are in setting > NewRatio to 1. > > Thoughts? > > (And please let me know if there's a better list to post this sort of > question to) > > - Charlie From Thomas.Rodriguez at Sun.COM Tue Sep 2 12:52:23 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 02 Sep 2008 12:52:23 -0700 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BD8ADF.6070302@sun.com> References: <48BD8ADF.6070302@sun.com> Message-ID: <7382901D-C06C-4D42-9330-E5B054EC0F26@sun.com> Which collector are you using? -client defaults to the serial collector which isn't adaptive at all. -server will use the parallel collector which tries to resize the new generation to improve collector performance. If you are running with -client try adding -XX: +UseParallelGC. I often see much better performance with -client just from this change. tom On Sep 2, 2008, at 11:50 AM, Charles Oliver Nutter wrote: > I've ben playing with JRuby on various benchmarks recently and found > that several object-intensive scripts run better if I set > NewRatio=1. Ruby, even more than Java, tends to generate lots and > lots of objects, especially considering that there's no unboxed > primitive numeric types (and no fixnums on the JVM...ahem ahem). So > my general theory is that: > > 1. A NewRatio of 1 allows all those extra transient objects to get > collected more quickly. > 2. Too small a "new" generation causes transient objects to get > shoved into older generations, potentially snowballing and forcing > more comprehensive GC runs as time goes on. > > I'm curious whether this theory sounds reasonable, whether there's a > better way I can adapt hotspot to the memory demands of a dynamic > language like Ruby, and what other implications there are in setting > NewRatio to 1. > > Thoughts? > > (And please let me know if there's a better list to post this sort > of question to) > > - Charlie From charles.nutter at sun.com Tue Sep 2 12:58:14 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 02 Sep 2008 14:58:14 -0500 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <7382901D-C06C-4D42-9330-E5B054EC0F26@sun.com> References: <48BD8ADF.6070302@sun.com> <7382901D-C06C-4D42-9330-E5B054EC0F26@sun.com> Message-ID: <48BD9AD6.1000207@sun.com> I'm interested in performance characteristics on all collectors, really. There's a dearth of information and research on how best to twiddle JVM settings for dynlangs, and I think it's high time we changed that. For the most part I'm talking about server performance, since that's what we always recommend people use for fast execution. But the down side of server is slower startup/warmup, and JRuby in particular is trying to fit into a command-line niche where slow startup is unacceptable. So for the most part command-line JRuby forced -client by default and makes no other changes to GC settings. This thread and others like it (like one I'm starting on jvm-l now) will probably change that. Also, on a side note, is there a good way we could detect that our -XX options aren't going to kill startup on a non-hotspot VM? Love the nonstandard options...hate the difficulty of knowing when we can use them. Tom Rodriguez wrote: > Which collector are you using? -client defaults to the serial collector > which isn't adaptive at all. -server will use the parallel collector > which tries to resize the new generation to improve collector > performance. If you are running with -client try adding > -XX:+UseParallelGC. I often see much better performance with -client > just from this change. > > tom > > On Sep 2, 2008, at 11:50 AM, Charles Oliver Nutter wrote: > >> I've ben playing with JRuby on various benchmarks recently and found >> that several object-intensive scripts run better if I set NewRatio=1. >> Ruby, even more than Java, tends to generate lots and lots of objects, >> especially considering that there's no unboxed primitive numeric types >> (and no fixnums on the JVM...ahem ahem). So my general theory is that: >> >> 1. A NewRatio of 1 allows all those extra transient objects to get >> collected more quickly. >> 2. Too small a "new" generation causes transient objects to get shoved >> into older generations, potentially snowballing and forcing more >> comprehensive GC runs as time goes on. >> >> I'm curious whether this theory sounds reasonable, whether there's a >> better way I can adapt hotspot to the memory demands of a dynamic >> language like Ruby, and what other implications there are in setting >> NewRatio to 1. >> >> Thoughts? >> >> (And please let me know if there's a better list to post this sort of >> question to) >> >> - Charlie > From charles.nutter at sun.com Tue Sep 2 13:08:45 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 02 Sep 2008 15:08:45 -0500 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BD9343.6000407@sun.com> References: <48BD8ADF.6070302@sun.com> <48BD9343.6000407@sun.com> Message-ID: <48BD9D4D.6090401@sun.com> Paul Hohensee wrote: > You probably want hotspot-gc-use at openjdk.java.net. I forwarded your email on to hotspot-gc-use and will reply there. Thanks! I think this is a good start. - Charlie From Peter.Kessler at Sun.COM Tue Sep 2 13:09:29 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 02 Sep 2008 13:09:29 -0700 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BD8ADF.6070302@sun.com> References: <48BD8ADF.6070302@sun.com> Message-ID: <48BD9D79.9060709@Sun.COM> Why limit yourself to NewRatio? The best you can get that way is half the heap for the young generation. If you really want to a big young generation (to give your temporary objects time to die without even being looked at by the collector), use -Xmn (or -XX:NewSize= and -XX:MaxNewSize=) to set it directly. Figure out what your live data size is and use that as the base size for the old generation. Then figure out what kinds of pauses the young generation collections impose, and how much they promote, then amortize the eventual old generation collection time over as many young generation collections as you can give space to in the old generation. Then make your total heap (-Xmx) as big as you can afford to get as big a young generation as that will allow. ... peter Charles Oliver Nutter wrote: > I've ben playing with JRuby on various benchmarks recently and found > that several object-intensive scripts run better if I set NewRatio=1. > Ruby, even more than Java, tends to generate lots and lots of objects, > especially considering that there's no unboxed primitive numeric types > (and no fixnums on the JVM...ahem ahem). So my general theory is that: > > 1. A NewRatio of 1 allows all those extra transient objects to get > collected more quickly. > 2. Too small a "new" generation causes transient objects to get shoved > into older generations, potentially snowballing and forcing more > comprehensive GC runs as time goes on. > > I'm curious whether this theory sounds reasonable, whether there's a > better way I can adapt hotspot to the memory demands of a dynamic > language like Ruby, and what other implications there are in setting > NewRatio to 1. > > Thoughts? > > (And please let me know if there's a better list to post this sort of > question to) > > - Charlie From daniel.daugherty at sun.com Tue Sep 2 13:19:42 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Tue, 02 Sep 2008 20:19:42 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20080902201951.13CB1D10F@hg.openjdk.java.net> Changeset: 25c3145237c6 Author: poonam Date: 2008-08-27 22:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/25c3145237c6 6731958: Include all the SA classes into sa-jdi.jar Summary: sa-jdi.jar bundled with JDK should include all the SA classes. Reviewed-by: swamyv ! agent/make/build-pkglist ! make/linux/makefiles/sa.make ! make/sa.files ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make Changeset: 9223f5bb0bf7 Author: poonam Date: 2008-08-28 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9223f5bb0bf7 Merge Changeset: a10808f5a4b5 Author: dcubed Date: 2008-09-02 08:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a10808f5a4b5 Merge From charles.nutter at sun.com Tue Sep 2 13:20:23 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 02 Sep 2008 15:20:23 -0500 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BD9D79.9060709@Sun.COM> References: <48BD8ADF.6070302@sun.com> <48BD9D79.9060709@Sun.COM> Message-ID: <48BDA007.6010200@sun.com> Cross-posting to hotspot-gc-use... I guess a certain portion of the challenge for language impls like JRuby is similar to the challenge you all face as JVM implementers: finding typical applications, typical loads, and appropriate defaults when our heads are usually buried two or three levels of abstraction beneath such applications. -Xmn is a good one I had forgotten about, and answers my question about how to increase NewRatio beyond 1. I guess there's really two tasks I'm looking into right now: 1. Discovering appropriate flags to tweak and "more appropriate" defaults dynlangs might want to try 2. Exploring real-world dynlang applications and loads to refine those better/best-guess defaults I'd say this round of emails is focused mostly on 1, since 2 is going to vary more across languages. And I think we can only start to explore 2 iff we know 1. So -Xmn goes on the list alongside NewRatio. Perhaps a brief illustration of the adaptive capabilities of the other collectors would be useful here? Obviously for server applications we'd hope HotSpot "does the right thing" for us already. Then perhaps we can learn from that (and please, teach me how to learn, including better tools and switches I can use to get the necessary GC metrics) and apply what we've learned to command-line/client runs (which will be more transient but not asimilar to the server runs in a language like Ruby). - Charlie Peter B. Kessler wrote: > Why limit yourself to NewRatio? The best you can get that way is half > the heap for the young generation. If you really want to a big young > generation (to give your temporary objects time to die without even > being looked at by the collector), use -Xmn (or -XX:NewSize= and > -XX:MaxNewSize=) to set it directly. Figure out what your live data > size is and use that as the base size for the old generation. Then > figure out what kinds of pauses the young generation collections impose, > and how much they promote, then amortize the eventual old generation > collection time over as many young generation collections as you can > give space to in the old generation. Then make your total heap (-Xmx) > as big as you can afford to get as big a young generation as that will > allow. > > ... peter > > Charles Oliver Nutter wrote: >> I've ben playing with JRuby on various benchmarks recently and found >> that several object-intensive scripts run better if I set NewRatio=1. >> Ruby, even more than Java, tends to generate lots and lots of objects, >> especially considering that there's no unboxed primitive numeric types >> (and no fixnums on the JVM...ahem ahem). So my general theory is that: >> >> 1. A NewRatio of 1 allows all those extra transient objects to get >> collected more quickly. >> 2. Too small a "new" generation causes transient objects to get shoved >> into older generations, potentially snowballing and forcing more >> comprehensive GC runs as time goes on. >> >> I'm curious whether this theory sounds reasonable, whether there's a >> better way I can adapt hotspot to the memory demands of a dynamic >> language like Ruby, and what other implications there are in setting >> NewRatio to 1. >> >> Thoughts? >> >> (And please let me know if there's a better list to post this sort of >> question to) >> >> - Charlie > From charles.nutter at sun.com Tue Sep 2 14:11:42 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 02 Sep 2008 16:11:42 -0500 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BDA6A4.2040007@javaperformancetuning.com> References: <48BD8ADF.6070302@sun.com> <48BD9D79.9060709@Sun.COM> <48BDA007.6010200@sun.com> <48BDA6A4.2040007@javaperformancetuning.com> Message-ID: <48BDAC0E.40305@sun.com> kirk wrote: > Hi Charles, > > Peter, awesome explination. I use hpjmeter right now to do very gross > analysis on gc logs. It doesn't tolerate all the Sun non-standard > non-standard switches (-XX and as apposed to the standard non-standard > switches -X) ;-) I've also signed up with Tony to work in gchisto, a > tool that should be more tolerant to Sun gc logs (is there anyway we can > settle on a standard format???) though that tool is still very limited. > Eventually it should get rolled into visualvm but that is a future. If not a standard format, at least a version-frozen format with a header, eh? I'll have to look into hpjmeter. At the moment I think half our "problems" on JRuby come from lack of experience with the right tools to gain visibility into the JVM. Oh, and lack of resources; two guys does not a language implementation team make. > What I'm finding is that techniques that focus more on evacuation seem > to work better than those that focus on collection compaction. This is > one of the reasons I'm very interested in seeing G1 released into the > wild. I believe that G1 will mix very well with dynamic languages > because it primary logic is on evacuation. With G1, I don't believe it > will matter if old fills up with transient objects that maybe should > have died in young. In fact I'd bet money that G1 will excel under these > conditions because old spaces will be evacuated based on who has the > lowest live ratios. The biggest draw back that I can see will be copying > costs. Even so, expect a win. If it's true that G1 (what is G1?) wouldn't care about transient objects getting promoted, I'd be interested in that as well. Overall, though, I think the exercise of exploring memory usage patterns to reduce such promotions will be very important, since there's going to be a lot of users on less helpful JVM versions, hotspot or otherwise. - Charlie From charles.nutter at sun.com Tue Sep 2 14:26:56 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 02 Sep 2008 16:26:56 -0500 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BDAC0E.40305@sun.com> References: <48BD8ADF.6070302@sun.com> <48BD9D79.9060709@Sun.COM> <48BDA007.6010200@sun.com> <48BDA6A4.2040007@javaperformancetuning.com> <48BDAC0E.40305@sun.com> Message-ID: <48BDAFA0.2040900@sun.com> Charles Oliver Nutter wrote: > If it's true that G1 (what is G1?) wouldn't care about transient objects Never mind this question...I found that G1 is the Garbage First collector. I'll read the paper. - Charlie From kirk.pepperdine at gmail.com Tue Sep 2 13:48:36 2008 From: kirk.pepperdine at gmail.com (kirk) Date: Tue, 02 Sep 2008 22:48:36 +0200 Subject: NewRatio: to twiddle or not to twiddle In-Reply-To: <48BDA007.6010200@sun.com> References: <48BD8ADF.6070302@sun.com> <48BD9D79.9060709@Sun.COM> <48BDA007.6010200@sun.com> Message-ID: <48BDA6A4.2040007@javaperformancetuning.com> Hi Charles, Peter, awesome explination. I use hpjmeter right now to do very gross analysis on gc logs. It doesn't tolerate all the Sun non-standard non-standard switches (-XX and as apposed to the standard non-standard switches -X) ;-) I've also signed up with Tony to work in gchisto, a tool that should be more tolerant to Sun gc logs (is there anyway we can settle on a standard format???) though that tool is still very limited. Eventually it should get rolled into visualvm but that is a future. What I'm finding is that techniques that focus more on evacuation seem to work better than those that focus on collection compaction. This is one of the reasons I'm very interested in seeing G1 released into the wild. I believe that G1 will mix very well with dynamic languages because it primary logic is on evacuation. With G1, I don't believe it will matter if old fills up with transient objects that maybe should have died in young. In fact I'd bet money that G1 will excel under these conditions because old spaces will be evacuated based on who has the lowest live ratios. The biggest draw back that I can see will be copying costs. Even so, expect a win. > > -Xmn is a good one I had forgotten about, and answers my question > about how to increase NewRatio beyond 1. use a combo of -Xmx and NewSize. That should pin things down. - Kirk > I guess there's really two tasks I'm looking into right now: > > 1. Discovering appropriate flags to tweak and "more appropriate" > defaults dynlangs might want to try > 2. Exploring real-world dynlang applications and loads to refine those > better/best-guess defaults > > I'd say this round of emails is focused mostly on 1, since 2 is going > to vary more across languages. And I think we can only start to > explore 2 iff we know 1. So -Xmn goes on the list alongside NewRatio. > > Perhaps a brief illustration of the adaptive capabilities of the other > collectors would be useful here? Obviously for server applications > we'd hope HotSpot "does the right thing" for us already. Then perhaps > we can learn from that (and please, teach me how to learn, including > better tools and switches I can use to get the necessary GC metrics) > and apply what we've learned to command-line/client runs (which will > be more transient but not asimilar to the server runs in a language > like Ruby). > > - Charlie > > Peter B. Kessler wrote: >> Why limit yourself to NewRatio? The best you can get that way is >> half the heap for the young generation. If you really want to a big >> young generation (to give your temporary objects time to die without >> even being looked at by the collector), use -Xmn (or -XX:NewSize= and >> -XX:MaxNewSize=) to set it directly. Figure out what your live data >> size is and use that as the base size for the old generation. Then >> figure out what kinds of pauses the young generation collections >> impose, and how much they promote, then amortize the eventual old >> generation collection time over as many young generation collections >> as you can give space to in the old generation. Then make your total >> heap (-Xmx) as big as you can afford to get as big a young generation >> as that will allow. >> >> ... peter >> >> Charles Oliver Nutter wrote: >>> I've ben playing with JRuby on various benchmarks recently and found >>> that several object-intensive scripts run better if I set >>> NewRatio=1. Ruby, even more than Java, tends to generate lots and >>> lots of objects, especially considering that there's no unboxed >>> primitive numeric types (and no fixnums on the JVM...ahem ahem). So >>> my general theory is that: >>> >>> 1. A NewRatio of 1 allows all those extra transient objects to get >>> collected more quickly. >>> 2. Too small a "new" generation causes transient objects to get >>> shoved into older generations, potentially snowballing and forcing >>> more comprehensive GC runs as time goes on. >>> >>> I'm curious whether this theory sounds reasonable, whether there's a >>> better way I can adapt hotspot to the memory demands of a dynamic >>> language like Ruby, and what other implications there are in setting >>> NewRatio to 1. >>> >>> Thoughts? >>> >>> (And please let me know if there's a better list to post this sort >>> of question to) >>> >>> - Charlie >> > > From Ulf.Zibis at gmx.de Wed Sep 3 02:54:29 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 03 Sep 2008 11:54:29 +0200 Subject: Enhance footprint for array initialization In-Reply-To: <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> References: <48BC243B.7050503@gmx.de> <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> Message-ID: <48BE5ED5.2000308@gmx.de> Am 02.09.2008 17:32, Tom Rodriguez schrieb: > I think you're on the wrong list. This is a javac code generation > issue. I think you want compiler-dev at openjdk.java.net. > > tom > Hi tom, >From the 1st view, you are right, javac list would be better, but knowledge about bytecode should exist in both lists, and I wanted to avoid to subscribe to an additional list. >From the 2nd view, my question is about if there is any reasonably way, a data table will be recognized in bytecode from the VM. If yes, the javac guys should be asked, to compile such tables to bytecode. If not, my post should be interpreted as an RFE to the VM guys to provide such a class file format. Especially this question is *not* about performance as you might have thought, it's about footprint of the class files. Performance here is not important, because as static initialisation this code is only executed once, so it isn't reasonable to Hotspot to optimize it first. Think about the charset.jar in JDK. Its about more than 6 MBytes, full with repeating bytecode just for initializing static encoding tables. It could be much smaller. I'm worried the amount of bytecode instructions, needed to initialize a static array. I first thought, there must be a new bytecode to define table date, which could look like: static {}; Code: 0: tabledef 950 // Start of table for 16-bit values, length 950, containing the pointers to the String constants 3: #39; //String 8859_1 5: #40; //String ISO8859_1 7: #115; //String iso_8859-1:1987 9: #40; //String ISO8859_1 11: // ... Yesterday I gave me 1 day, to study the VM Specification more deeper. So I came to the conclusion, that there is missing an array-type for the Constant Pool in the class file format. This would reduce the footprint of class files significantly, because the repeated codes to initialize long arrays could be omitted. More worse it looks for byte arrays, than for string arrays: private static final byte[] allBytes = { (byte)0x00, (byte)0x01, (byte)0x02, // ..... (byte)0xFF, (byte)0xFF } The bytecode will look like (256 times): 40: dup 41: bipush 8 43: bipush 8 45: bastore So the class file will need 6 times more footprint, than a simple "CONSTANT_array". Hopefully you now understand better the subject of my post, Regards, Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080903/6bfdc7e6/attachment.html From Thomas.Rodriguez at Sun.COM Wed Sep 3 09:01:17 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Sep 2008 09:01:17 -0700 Subject: Enhance footprint for array initialization In-Reply-To: <48BE5ED5.2000308@gmx.de> References: <48BC243B.7050503@gmx.de> <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> <48BE5ED5.2000308@gmx.de> Message-ID: Well, your original question was about the code generated by javac so that's why I suggested you ask on the javac list. They could possibly generate more efficient code for the example you gave and it wouldn't require any specification or JVM changes. As far as the general issue of array initialization, you're not the first to notice this. The idea of more efficient array initialization using the constant pool has been bandied about probably since 1.0 but it's always been pretty low on anyones radar. VM support for something like this wouldn't be hard but the JVM spec would have to be updated which would pretty much require a JSR. All the language and JVM specification work is in a different group. I don't know if there's a separate list for that but again the javac lists would probably get your into a more productive conversation about such a change. There's an old trick for making more compact array initialization by using Strings as data containers. Basically you encode your real data as a String and then at init time you get the char[] data out and transform it into whatever primitive array type you actually want. It's a slightly dubious solution and I'd be surprised if anyone was still using it. Is there any reason the initialization code in charset.jar couldn't just be written to be more efficient? tom On Sep 3, 2008, at 2:54 AM, Ulf Zibis wrote: > Am 02.09.2008 17:32, Tom Rodriguez schrieb: >> >> I think you're on the wrong list. This is a javac code generation >> issue. I think you want compiler-dev at openjdk.java.net. >> >> tom >> > Hi tom, > > >From the 1st view, you are right, javac list would be better, but > knowledge about bytecode should exist in both lists, and I wanted to > avoid to subscribe to an additional list. > >From the 2nd view, my question is about if there is any reasonably > way, a data table will be recognized in bytecode from the VM. If > yes, the javac guys should be asked, to compile such tables to > bytecode. If not, my post should be interpreted as an RFE to the VM > guys to provide such a class file format. > > Especially this question is *not* about performance as you might > have thought, it's about footprint of the class files. Performance > here is not important, because as static initialisation this code is > only executed once, so it isn't reasonable to Hotspot to optimize it > first. Think about the charset.jar in JDK. Its about more than 6 > MBytes, full with repeating bytecode just for initializing static > encoding tables. It could be much smaller. > > I'm worried the amount of bytecode instructions, needed to > initialize a static array. I first thought, there must be a new > bytecode to define table date, which could look like: > > static {}; > Code: > 0: tabledef 950 // Start of table for 16-bit values, > length 950, containing the pointers to the String constants > 3: #39; //String 8859_1 > 5: #40; //String ISO8859_1 > 7: #115; //String iso_8859-1:1987 > 9: #40; //String ISO8859_1 > 11: // ... > > Yesterday I gave me 1 day, to study the VM Specification more > deeper. So I came to the conclusion, that there is missing an array- > type for the Constant Pool > in the class file format. This would reduce the footprint of class > files significantly, because the repeated codes to initialize long > arrays could be omitted. > More worse it looks for byte arrays, than for string arrays: > > private static final byte[] allBytes = { > (byte)0x00, (byte)0x01, (byte)0x02, > // ..... > (byte)0xFF, (byte)0xFF > } > The bytecode will look like (256 times): > 40: dup > 41: bipush 8 > 43: bipush 8 > 45: bastore > > So the class file will need 6 times more footprint, than a simple > "CONSTANT_array". > > Hopefully you now understand better the subject of my post, > > Regards, > Ulf > > From thomas.rodriguez at sun.com Wed Sep 3 18:13:10 2008 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 04 Sep 2008 01:13:10 +0000 Subject: hg: jdk7/hotspot/hotspot: 6744422: incorrect handling of -1 in set_jump_destination Message-ID: <20080904011314.DD461D1CA@hg.openjdk.java.net> Changeset: 3a26e9e4be71 Author: never Date: 2008-09-03 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3a26e9e4be71 6744422: incorrect handling of -1 in set_jump_destination Reviewed-by: rasbold ! src/cpu/x86/vm/nativeInst_x86.hpp From martinrb at google.com Wed Sep 3 19:12:50 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 Sep 2008 19:12:50 -0700 Subject: Enhance footprint for array initialization In-Reply-To: <48BE5ED5.2000308@gmx.de> References: <48BC243B.7050503@gmx.de> <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> <48BE5ED5.2000308@gmx.de> Message-ID: <1ccfd1c10809031912x23b8fe6dxbc193c686ae51aca@mail.gmail.com> Ulf, you are quite correct that the class file format is suboptimal for storage of primitive arrays. But the class file format is one of the most difficult things to change. It clearly requires a JSR, for example. You don't want to expend that kind of effort. But for large amounts of data, you don't want to store it in a class file anyways. Define your own data format and put your data super-compactly in a non-class file in the JDK. Study the ICU implementation for possible inspiration. And discuss your efforts in this direction in core-libs-dev. Martin From Ulf.Zibis at gmx.de Thu Sep 4 03:17:52 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 04 Sep 2008 12:17:52 +0200 Subject: Enhance footprint for array initialization In-Reply-To: <1ccfd1c10809031912x23b8fe6dxbc193c686ae51aca@mail.gmail.com> References: <48BC243B.7050503@gmx.de> <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> <48BE5ED5.2000308@gmx.de> <1ccfd1c10809031912x23b8fe6dxbc193c686ae51aca@mail.gmail.com> Message-ID: <48BFB5D0.2080803@gmx.de> Martin, you bring it to the point in the end. Short and clear. About starting an JSR... I wonder that not somebody else had tried this in the past. For me, I'm afraid, that I don't have the power for it. Thanks for warning me. Am 04.09.2008 04:12, Martin Buchholz schrieb: > And discuss your efforts in this direction in core-libs-dev. > > Yes. from this point on it belongs to core-libs-dev. Ulf From Ulf.Zibis at gmx.de Thu Sep 4 03:49:39 2008 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 04 Sep 2008 12:49:39 +0200 Subject: Enhance footprint for array initialization In-Reply-To: <48BFB3B1.4040109@gmx.de> References: <48BC243B.7050503@gmx.de> <5B949BAF-FE81-4EC7-A772-C397E339E07D@sun.com> <48BE5ED5.2000308@gmx.de> <48BFB3B1.4040109@gmx.de> Message-ID: <48BFBD43.5070309@gmx.de> Am 04.09.2008 12:08, Ulf Zibis schrieb: > Am 03.09.2008 18:01, Tom Rodriguez schrieb: >> There's an old trick for making more compact array initialization by >> using Strings as data containers. Basically you encode your real >> data as a String and then at init time you get the char[] data out >> and transform it into whatever primitive array type you actually >> want. It's a slightly dubious solution and I'd be surprised if >> anyone was still using it. > Surprise, yes, most of the converters and coders in sun.io and > sun.nio.cs package use this technique. Example for decoding java chars > to byte data (simplified): > > String charToByteTable = { "\u0000\u0001\u0002 ..... "} > ... > byte outByte = (byte)charToByteTable.charAt(inChar); > >> >> Is there any reason the initialization code in charset.jar couldn't >> just be written to be more efficient? > This sentence I don't understand grammatically. Sorry, I'm no English > native speaker. Can you please write it in other words? > > Thanks for you effort, > > Ulf > > > From volker.simonis at gmail.com Thu Sep 4 07:03:22 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Sep 2008 16:03:22 +0200 Subject: HotSpot segfaults if given -XX options with an empty string argument (regression) Message-ID: Hi, I just realized that there's a regression in the argument parsing code of the HotSpot which leads to a segmentation fault if an -XX option with an empty string argument (e.g. -XX:SyncKnobs= or -XX:SyncKnobs="") is given on the command line. The regression must have appeared somewhere in HS 11, because Java 1.6.0_06 (which contains HS 10.0_b22) doesn't show the problem while both Java 1.6.0_10 (HS 11.0_b11) and Java 1.7.0-ea-b24 (HS 12.0_b01) as well as the latest OpenJDK snapshot (Rev. 292 with tag jdk7-b34) are affected. Attached you can find a patch against http://hg.openjdk.java.net/jdk7/jdk7/hotspot At the same time, the patch also fixes a minor flaw in globals.hpp where the default value of the 'PrintAssemblyOptions' option, which is of type 'ccstr', should really be "" instead of 'false'. Regards, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: hg.patch Type: text/x-patch Size: 2287 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080904/4f8abd61/attachment.bin From Chuck.Rasbold at Sun.COM Thu Sep 4 08:36:20 2008 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Thu, 04 Sep 2008 08:36:20 -0700 Subject: HotSpot segfaults if given -XX options with an empty string argument (regression) In-Reply-To: References: Message-ID: <48C00074.1060003@sun.com> Volker - I've opened bug 6744783 for this. -- Chuck On 09/04/08 07:03, Volker Simonis wrote: > Hi, > > I just realized that there's a regression in the argument parsing code > of the HotSpot which leads to a segmentation fault if an -XX option > with an empty string argument (e.g. -XX:SyncKnobs= or > -XX:SyncKnobs="") is given on the command line. > > The regression must have appeared somewhere in HS 11, because Java > 1.6.0_06 (which contains HS 10.0_b22) doesn't show the problem while > both Java 1.6.0_10 (HS 11.0_b11) and Java 1.7.0-ea-b24 (HS 12.0_b01) > as well as the latest OpenJDK snapshot (Rev. 292 with tag jdk7-b34) > are affected. > > Attached you can find a patch against > http://hg.openjdk.java.net/jdk7/jdk7/hotspot > > At the same time, the patch also fixes a minor flaw in globals.hpp > where the default value of the 'PrintAssemblyOptions' option, which is > of type 'ccstr', should really be "" instead of 'false'. > > Regards, > Volker > From volker.simonis at gmail.com Thu Sep 4 08:45:02 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Sep 2008 17:45:02 +0200 Subject: HotSpot segfaults if given -XX options with an empty string argument (regression) In-Reply-To: References: Message-ID: .. and I forgot to say: the actual crash happens in 'CommandLineFlags::ccstrAtPut()' where 'strlen()' is called with a NULL argument because 'value' is set to NULL in 'Arguments::parse_argument()' if it points to an empty string. The patch fixes this... On 9/4/08, Volker Simonis wrote: > Hi, > > I just realized that there's a regression in the argument parsing code > of the HotSpot which leads to a segmentation fault if an -XX option > with an empty string argument (e.g. -XX:SyncKnobs= or > -XX:SyncKnobs="") is given on the command line. > > The regression must have appeared somewhere in HS 11, because Java > 1.6.0_06 (which contains HS 10.0_b22) doesn't show the problem while > both Java 1.6.0_10 (HS 11.0_b11) and Java 1.7.0-ea-b24 (HS 12.0_b01) > as well as the latest OpenJDK snapshot (Rev. 292 with tag jdk7-b34) > are affected. > > Attached you can find a patch against > http://hg.openjdk.java.net/jdk7/jdk7/hotspot > > At the same time, the patch also fixes a minor flaw in globals.hpp > where the default value of the 'PrintAssemblyOptions' option, which is > of type 'ccstr', should really be "" instead of 'false'. > > Regards, > > Volker > > From Keith.McGuigan at Sun.COM Thu Sep 4 09:46:33 2008 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 04 Sep 2008 12:46:33 -0400 Subject: HotSpot segfaults if given -XX options with an empty string argument (regression) In-Reply-To: <48C00074.1060003@sun.com> References: <48C00074.1060003@sun.com> Message-ID: <48C010E9.7030003@sun.com> I'll shepherd this through hotspot-rt, unless anyone has any objections. -- - Keith Chuck Rasbold wrote: > Volker - > > I've opened bug 6744783 for this. > > -- Chuck > > On 09/04/08 07:03, Volker Simonis wrote: >> Hi, >> >> I just realized that there's a regression in the argument parsing code >> of the HotSpot which leads to a segmentation fault if an -XX option >> with an empty string argument (e.g. -XX:SyncKnobs= or >> -XX:SyncKnobs="") is given on the command line. >> >> The regression must have appeared somewhere in HS 11, because Java >> 1.6.0_06 (which contains HS 10.0_b22) doesn't show the problem while >> both Java 1.6.0_10 (HS 11.0_b11) and Java 1.7.0-ea-b24 (HS 12.0_b01) >> as well as the latest OpenJDK snapshot (Rev. 292 with tag jdk7-b34) >> are affected. >> >> Attached you can find a patch against >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot >> >> At the same time, the patch also fixes a minor flaw in globals.hpp >> where the default value of the 'PrintAssemblyOptions' option, which is >> of type 'ccstr', should really be "" instead of 'false'. >> >> Regards, >> Volker >> > From erik.trimble at sun.com Thu Sep 4 21:43:25 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 05 Sep 2008 04:43:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20080905044337.D732BD2BE@hg.openjdk.java.net> Changeset: 5251a9cd8eb8 Author: jcoomes Date: 2008-08-27 15:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5251a9cd8eb8 6742207: jdk7 32-bit windows build failed running pack200 Summary: 6730514 inadvertently disabled perm gen expansion; reenable Reviewed-by: ysr ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp Changeset: 5967ae2171f6 Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5967ae2171f6 Added tag jdk7-b34 for changeset 5251a9cd8eb8 ! .hgtags Changeset: 5c7c20a84e41 Author: trims Date: 2008-09-04 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5c7c20a84e41 6745064: Update Hotspot build number for HS14 Summary: Bump build number for hs14-b04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5fa96a5a7e76 Author: trims Date: 2008-09-04 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5fa96a5a7e76 Merge - src/cpu/x86/vm/assembler_x86_32.cpp - src/cpu/x86/vm/assembler_x86_32.hpp - src/cpu/x86/vm/assembler_x86_32.inline.hpp - src/cpu/x86/vm/assembler_x86_64.cpp - src/cpu/x86/vm/assembler_x86_64.hpp - src/cpu/x86/vm/assembler_x86_64.inline.hpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp From Keith.McGuigan at Sun.COM Fri Sep 5 13:57:24 2008 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Fri, 05 Sep 2008 16:57:24 -0400 Subject: what code in 5.0 does generate_native_wrapper replace? Message-ID: <48C19D34.70507@sun.com> In the 5.0-ish codebase, what code set up the arguments for native method calls? There's no generate_native_wrapper() there. Any pointers? -- - Keith From Thomas.Rodriguez at Sun.COM Fri Sep 5 14:10:38 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 05 Sep 2008 14:10:38 -0700 Subject: what code in 5.0 does generate_native_wrapper replace? In-Reply-To: <48C19D34.70507@sun.com> References: <48C19D34.70507@sun.com> Message-ID: <0A0ED8AE-DAC6-47AB-AE1B-F162DAD2615C@sun.com> C1 and C2 had their own separate code paths for generating native wrappers. C2 used ideal and C1 used hand written assembly the way that SharedRuntime does now. The C1 code would be in c1_LIRAssembler_.cpp. tom On Sep 5, 2008, at 1:57 PM, Keith McGuigan wrote: > In the 5.0-ish codebase, what code set up the arguments for native > method calls? There's no generate_native_wrapper() there. Any > pointers? > > -- > - Keith From charles.nutter at sun.com Mon Sep 8 01:16:29 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 08 Sep 2008 03:16:29 -0500 Subject: Saving the code cache between runs Message-ID: <48C4DF5D.60409@sun.com> I know this topic has come up before, so feel free to punt me to the archives or a FAQ or something, but is there any work being done or any planned work relating to saving compiler output between runs? I've heard descriptions of the complexity involved, but given the recent efforts to improve the startup/warmup time of the JVM, being able to "start hot" seems like it would be worth quite a bit of pain. Any pointers? - Charlie From yamauchi at google.com Fri Sep 5 13:20:53 2008 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Fri, 5 Sep 2008 13:20:53 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 Message-ID: Hi, I backported the change http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82 into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the AsyncGetCallTrace(). The change appears to have been first introduced in OpenJDK7 b27 (Hotspot v13-b01). It'd be great if this patch can be reviewed and applied to future OpenJDK6 builds. I understand that this may be a 'scary' patch considering the stable nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review and comment on this patch. Thanks, Hiroshi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: agct.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080905/1e5263f6/attachment.txt From roman.kennke at aicas.com Mon Sep 8 13:11:25 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Mon, 08 Sep 2008 22:11:25 +0200 Subject: [PATCH] Small build fix Message-ID: <1220904685.7112.30.camel@moonlight> The attached patch makes the compiler in Ubuntu (gcc 4.2.3) happy. Would be nice to have it committed. Cheers, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt Type: text/x-patch Size: 353 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080908/a3d9b104/attachment.bin From Thomas.Rodriguez at Sun.COM Mon Sep 8 13:55:04 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 08 Sep 2008 13:55:04 -0700 Subject: [PATCH] Small build fix In-Reply-To: <1220904685.7112.30.camel@moonlight> References: <1220904685.7112.30.camel@moonlight> Message-ID: <58B68582-13F6-40E0-97C2-A54C125FC4C5@sun.com> That was included as part of http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6ca61c728c2d . I think it finally trickled into a promoted build as part of b34. tom On Sep 8, 2008, at 1:11 PM, Roman Kennke wrote: > The attached patch makes the compiler in Ubuntu (gcc 4.2.3) happy. > Would > be nice to have it committed. > > Cheers, Roman > -- > Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org > aicas Allerton Interworks Computer Automated Systems GmbH > Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany > http://www.aicas.com * Tel: +49-721-663 968-48 > USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe > Gesch?ftsf?hrer: Dr. James J. Hunt > From roman.kennke at aicas.com Mon Sep 8 13:58:02 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Mon, 08 Sep 2008 22:58:02 +0200 Subject: [PATCH] Small build fix In-Reply-To: <58B68582-13F6-40E0-97C2-A54C125FC4C5@sun.com> References: <1220904685.7112.30.camel@moonlight> <58B68582-13F6-40E0-97C2-A54C125FC4C5@sun.com> Message-ID: <1220907482.7112.39.camel@moonlight> Hi Tom, > That was included as part of http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6ca61c728c2d > . I think it finally trickled into a promoted build as part of b34. Cool. It's not yet in the jdk7 repos. I need to get used to also check from the team repos for more current patches... /Roman > > tom > > On Sep 8, 2008, at 1:11 PM, Roman Kennke wrote: > > > The attached patch makes the compiler in Ubuntu (gcc 4.2.3) happy. > > Would > > be nice to have it committed. > > > > Cheers, Roman > > -- > > Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org > > aicas Allerton Interworks Computer Automated Systems GmbH > > Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany > > http://www.aicas.com * Tel: +49-721-663 968-48 > > USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe > > Gesch?ftsf?hrer: Dr. James J. Hunt > > > -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Daniel.Daugherty at Sun.COM Mon Sep 8 14:48:37 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Mon, 08 Sep 2008 15:48:37 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: References: Message-ID: <48C59DB5.5040406@sun.com> Can someone remind me which HSX version OpenJDK6-B11 is based on? Compiler team, Steve G. had talked about back porting this fix to earlier HSX releases (prior to HSX-13), but I don't believe that he got to that task or handed off to anyone else on the Compiler team prior to the unfortunate event at the end of June. I reviewed Steve's original changes from an AsyncGetCallTrace() point-of-view and I can review these change from the same POV, but one or more folks on the compiler team is going to have to look at these changes from the Compiler team POV... Dan Hiroshi Yamauchi wrote: > Hi, > > I backported the change > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82 > > into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the > AsyncGetCallTrace(). The change appears to have been first introduced > in OpenJDK7 b27 (Hotspot v13-b01). > > It'd be great if this patch can be reviewed and applied to future OpenJDK6 > builds. > > I understand that this may be a 'scary' patch considering the stable > nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review and > comment on this patch. > > Thanks, > Hiroshi > From Joe.Darcy at Sun.COM Mon Sep 8 14:55:46 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Mon, 08 Sep 2008 14:55:46 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C59DB5.5040406@sun.com> References: <48C59DB5.5040406@sun.com> Message-ID: <48C59F62.4040806@sun.com> Daniel D. Daugherty wrote: > Can someone remind me which HSX version OpenJDK6-B11 is based on? Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in the near future. -Joe > > Compiler team, Steve G. had talked about back porting this fix > to earlier HSX releases (prior to HSX-13), but I don't believe > that he got to that task or handed off to anyone else on the > Compiler team prior to the unfortunate event at the end of June. > > I reviewed Steve's original changes from an AsyncGetCallTrace() > point-of-view and I can review these change from the same POV, > but one or more folks on the compiler team is going to have to > look at these changes from the Compiler team POV... > > Dan > > > > Hiroshi Yamauchi wrote: >> Hi, >> >> I backported the change >> >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82 >> >> into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the >> AsyncGetCallTrace(). The change appears to have been first introduced >> in OpenJDK7 b27 (Hotspot v13-b01). >> >> It'd be great if this patch can be reviewed and applied to future >> OpenJDK6 >> builds. >> >> I understand that this may be a 'scary' patch considering the stable >> nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review >> and >> comment on this patch. >> >> Thanks, >> Hiroshi >> From Daniel.Daugherty at Sun.COM Tue Sep 9 06:20:32 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 09 Sep 2008 07:20:32 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <1220944059.3348.4.camel@dijkstra.wildebeest.org> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> Message-ID: <48C67820.6080109@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080909/e44f4b31/attachment.html From mark at klomp.org Tue Sep 9 07:06:09 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 09 Sep 2008 16:06:09 +0200 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C67820.6080109@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> Message-ID: <1220969169.3348.8.camel@dijkstra.wildebeest.org> Hi Daniel, On Tue, 2008-09-09 at 07:20 -0600, Daniel D. Daugherty wrote: > Mark Wielaard wrote: > > Are the HSX versions tagged in the mercurial repos somehow? > > In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and > > HS_BUILD_NUMBER, how do these numbers match up? > > The hotspot_version should reflect the specific HSX version > number and build of the snapshot used to create the repo. Thanks. What is "the snapshot" in this case? If I am interested in a specific HSX version, how would I find out when that version was checked into the repo? Is there a way to match the hotspot mercurial rev number to a HSX version number? Cheers, Mark From Daniel.Daugherty at Sun.COM Tue Sep 9 07:24:45 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Tue, 09 Sep 2008 08:24:45 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <1220969169.3348.8.camel@dijkstra.wildebeest.org> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <1220969169.3348.8.camel@dijkstra.wildebeest.org> Message-ID: <48C6872D.7030707@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080909/ae229d48/attachment.html From Joe.Darcy at Sun.COM Tue Sep 9 09:00:36 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 09 Sep 2008 09:00:36 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C67820.6080109@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> Message-ID: <48C69DA4.8080901@sun.com> Daniel D. Daugherty wrote: > Mark Wielaard wrote: >> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote: >> >>> Daniel D. Daugherty wrote: >>> >>>> Can someone remind me which HSX version OpenJDK6-B11 is based on? >>>> >>> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in >>> the near future. >>> >> >> Are the HSX versions tagged in the mercurial repos somehow? >> In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and >> HS_BUILD_NUMBER, how do these numbers match up? >> >> Thanks, >> >> Mark >> > > The hotspot_version should reflect the specific HSX version > number and build of the snapshot used to create the repo. I > don't know if the OpenJDK6 project is incrementing or > changing those values in any way. To date, we on OpenJDK 6 have not incremented the HSX version values. The listed version might be slightly off; we are basically using the same source as the HotSpot in 6u7, but with a few additional fixes. -Joe From mark at klomp.org Tue Sep 9 09:15:07 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 09 Sep 2008 18:15:07 +0200 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C6872D.7030707@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <1220969169.3348.8.camel@dijkstra.wildebeest.org> <48C6872D.7030707@sun.com> Message-ID: <1220976907.3348.17.camel@dijkstra.wildebeest.org> Hi Daniel, On Tue, 2008-09-09 at 08:24 -0600, Daniel D. Daugherty wrote: > Mark Wielaard wrote: > > If I am interested in a specific HSX version, how would I find out when > > that version was checked into the repo? > > I believe you'll be able to figure that out from the "hg log" > of the "make/hotspot_version" file. In theory, the folks who > pushed the updates the "make/hotspot_version" file will have > included some comment that indicates the change to the HSX > version number. That should give you the changeset ID for the > last change that comprises the specific HSX version. Thanks. I see hg log -v will give me the information I was looking for since HS_* numbers are updated in a specific commit. What does it mean for each of these, HS_MAJOR_VER, HS_MINOR_VER and HS_BUILD_NUMBER, to be incremented? Or is there no meaning attached and are they more or less random, date based, tags? > > Is there a way to match the > > hotspot mercurial rev number to a HSX version number? > > See above reply. I don't think we're tagging the repros with > the HSX version number, but perhaps we should. I know we tag > the JDK7 repos with the JDK7 build number, but I don't think > we tag the hotspot repos with the HSX version number. I think that would be beneficial, if there is some meaning attached to the specific numbers when they are increased. Then someone can make sure they pick a "stable" or "production" ready version from the hotspot (jdk7) repository to push into their project. That is really why I asked, to make sure that I know that when we push an hotspot version into icedtea (which comes with 2 different versions, depending on whether or not you build against zero/shark) it is something that is stable enough and something that the hotspot devs wouldn't feel uncomfortable with being in a bit wider use. Thanks, Mark From mark at klomp.org Tue Sep 9 00:07:39 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 09 Sep 2008 09:07:39 +0200 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C59F62.4040806@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> Message-ID: <1220944059.3348.4.camel@dijkstra.wildebeest.org> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote: > Daniel D. Daugherty wrote: > > Can someone remind me which HSX version OpenJDK6-B11 is based on? > > Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in > the near future. Are the HSX versions tagged in the mercurial repos somehow? In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and HS_BUILD_NUMBER, how do these numbers match up? Thanks, Mark From chuck.rasbold at sun.com Wed Sep 10 09:37:53 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Wed, 10 Sep 2008 16:37:53 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20080910163803.51000D7D0@hg.openjdk.java.net> Changeset: 60bc5071073f Author: never Date: 2008-09-02 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/60bc5071073f 6738933: assert with base pointers must match with compressed oops enabled Reviewed-by: kvn, rasbold ! src/share/vm/opto/loopopts.cpp Changeset: cdbee661c7da Author: rasbold Date: 2008-09-04 09:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cdbee661c7da Merge Changeset: 2b73d212b1fd Author: kvn Date: 2008-09-05 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2b73d212b1fd 6676462: JVM sometimes would suddenly consume significant amount of memory Summary: Add asserts with dead loop checks in AddNode::Ideal(). Reviewed-by: never ! src/share/vm/opto/addnode.cpp Changeset: 6e7305abe64c Author: never Date: 2008-09-09 12:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6e7305abe64c 6746320: Hotspot regression test for 6512111 fails in -Xmixed mode Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: f9847b70eccd Author: rasbold Date: 2008-09-10 06:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f9847b70eccd Merge From charles.nutter at sun.com Wed Sep 10 15:07:20 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 10 Sep 2008 17:07:20 -0500 Subject: Sensitivity of HotSpot to late-breaking news Message-ID: <48C84518.40005@sun.com> JRuby normally interprets all code on startup. This is partially for startup performance reasons, but also because a large percentage of Ruby code is either only used once or is generated at runtime. So we have a simple call-count threshold at which we will JIT compile Ruby code into Java bytecode. Currently, the threshold is 50 invocations. In this email I'm seeking to understand the effect of late-breaking changes on hotspot's profiled optimizations. Specifically, since JRuby's typical execution model means that basically *all* methods will be following the interpreted path for a while and then switch to a compiled path, how severely could that be damaging HotSpot's optimizations? We have seen, for example, microbenchmarks that run great for the first 50 iterations. After 50 iterations, the benchmark library itself starts to JIT, and performance takes a brief drop. But it never fully recovers, even though many (all) subsequent invocations do not further change the type profile at whatever location led to the deopt in the first place. Essentially it seems like we need a way to tell hotspot "forget all that, I'm really, truly switching to this new type forever and ever", allowing the same monomorphic optimizations to be applied to the new type. Is this possible with current HotSpot? Do you have recommendations for how best to avoid this effect (like using a boolean to switch from interpreted to compiled, rather than swapping implementations?). I'm concerned about it because I would also now like to start doing active replacement of code at runtime in response to JRuby-level profiling, and if replacing one implementation with another (possibly permanently) damages long-term performance it will certainly be less attractive. - Charlie From Daniel.Daugherty at Sun.COM Wed Sep 10 15:34:08 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 10 Sep 2008 16:34:08 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C69DA4.8080901@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> Message-ID: <48C84B60.7000806@sun.com> Joseph D. Darcy wrote: > Daniel D. Daugherty wrote: >> Mark Wielaard wrote: >>> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote: >>> >>>> Daniel D. Daugherty wrote: >>>> >>>>> Can someone remind me which HSX version OpenJDK6-B11 is based on? >>>>> >>>> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to >>>> HS11 in the near future. >>>> >>> >>> Are the HSX versions tagged in the mercurial repos somehow? >>> In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and >>> HS_BUILD_NUMBER, how do these numbers match up? >>> >>> Thanks, >>> >>> Mark >>> >> >> The hotspot_version should reflect the specific HSX version >> number and build of the snapshot used to create the repo. I >> don't know if the OpenJDK6 project is incrementing or >> changing those values in any way. > > To date, we on OpenJDK 6 have not incremented the HSX version values. > The listed version might be slightly off; we are basically using the > same source as the HotSpot in 6u7, but with a few additional fixes. > > -Joe It seems to me that we have a versioning problem here. If the HSX source in OpenJDK6 is not the same as the baseline HSX source, then the HSX version number should _not_ be the same. It might be appropriate to bump the minor version number and then reset the build number. Something to make the HSX version identity unique if the source code is indeed different. Joe, this needs to be discussed with the HotSpot P-Team. Dan From mark at klomp.org Wed Sep 10 15:41:22 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 11 Sep 2008 00:41:22 +0200 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C84B60.7000806@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> Message-ID: <1221086482.26700.10.camel@hermans.wildebeest.org> Hi Daniel, On Wed, 2008-09-10 at 16:34 -0600, Daniel D. Daugherty wrote: > It seems to me that we have a versioning problem here. If the > HSX source in OpenJDK6 is not the same as the baseline HSX source, > then the HSX version number should _not_ be the same. > > It might be appropriate to bump the minor version number and then > reset the build number. Something to make the HSX version identity > unique if the source code is indeed different. > > Joe, this needs to be discussed with the HotSpot P-Team. What is the HotSpot P-Team? Thanks, Mark From Daniel.Daugherty at Sun.COM Wed Sep 10 15:47:39 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 10 Sep 2008 16:47:39 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <1221086482.26700.10.camel@hermans.wildebeest.org> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> Message-ID: <48C84E8B.6030001@sun.com> P-Team stands for "Product Team" I think :-) Those are the Sun folks that make the business decisions about HotSpot Express. The HotSpot P-Team approved the current versioning system that is used for HotSpot Express releases so they need to be kept in the loop when there are issues with HSX version numbers. Dan Mark Wielaard wrote: > What is the HotSpot P-Team? > From mark at klomp.org Wed Sep 10 16:09:54 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 11 Sep 2008 01:09:54 +0200 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C84E8B.6030001@sun.com> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> Message-ID: <1221088194.26700.18.camel@hermans.wildebeest.org> Hi Daniel, On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote: > P-Team stands for "Product Team" I think :-) > > Those are the Sun folks that make the business decisions about > HotSpot Express. The HotSpot P-Team approved the current > versioning system that is used for HotSpot Express releases > so they need to be kept in the loop when there are issues > with HSX version numbers. Thanks. Which brings a followup question. What is "HotSpot Express"? The thing I am really after is making sure that the versions of hotspot that we ship with IcedTea in the various GNU/Linux distributions are good. We actually have two versions, one from openjdk6 with a couple of backports from the openjdk7 hotspot repo for crashes found with running various applications (like eclipse). And one older snapshot of the hotspot from openjdk7 that is used to base the zero/shark port on. It would be good if we coordinated on good known stable versions of hotspot whenever possible. Cheers, Mark From gnu_andrew at member.fsf.org Wed Sep 10 16:16:28 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 11 Sep 2008 00:16:28 +0100 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <1221088194.26700.18.camel@hermans.wildebeest.org> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> Message-ID: <17c6771e0809101616g4eeda5e9vee0017d06b0f138a@mail.gmail.com> 2008/9/11 Mark Wielaard : > Hi Daniel, > > On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote: >> P-Team stands for "Product Team" I think :-) >> >> Those are the Sun folks that make the business decisions about >> HotSpot Express. The HotSpot P-Team approved the current >> versioning system that is used for HotSpot Express releases >> so they need to be kept in the loop when there are issues >> with HSX version numbers. > > Thanks. Which brings a followup question. What is "HotSpot Express"? > > The thing I am really after is making sure that the versions of hotspot > that we ship with IcedTea in the various GNU/Linux distributions are > good. We actually have two versions, one from openjdk6 with a couple of > backports from the openjdk7 hotspot repo for crashes found with running > various applications (like eclipse). And one older snapshot of the > hotspot from openjdk7 that is used to base the zero/shark port on. It > would be good if we coordinated on good known stable versions of hotspot > whenever possible. > > Cheers, > > Mark > > We actually have 3 in total over the two IcedTea trees - the one in OpenJDK6 b11, the one used by the zero patch on IcedTea6 (snapshotted from b24 of OpenJDK7) and the current OpenJDK7 version in IcedTea. Scary :) -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Daniel.Daugherty at Sun.COM Wed Sep 10 17:39:40 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Wed, 10 Sep 2008 18:39:40 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <1221088194.26700.18.camel@hermans.wildebeest.org> References: <48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> Message-ID: <48C868CC.4050303@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080910/91b09eef/attachment.html From gnu_andrew at member.fsf.org Thu Sep 11 00:53:12 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 11 Sep 2008 08:53:12 +0100 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C868CC.4050303@sun.com> References: <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> Message-ID: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> 2008/9/11 Daniel D. Daugherty : > Mark Wielaard wrote: > > Hi Daniel, > > On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote: > > > P-Team stands for "Product Team" I think :-) > > Those are the Sun folks that make the business decisions about > HotSpot Express. The HotSpot P-Team approved the current > versioning system that is used for HotSpot Express releases > so they need to be kept in the loop when there are issues > with HSX version numbers. > > > Thanks. Which brings a followup question. What is "HotSpot Express"? > > > Just the name given to the idea of releasing VMs independently > of JDK/JRE releases. I'm sure someone else out there has a > better definition... :-) > I think an OpenJDK glossary is in order, if we don't already have one... ;) > > The thing I am really after is making sure that the versions of hotspot > that we ship with IcedTea in the various GNU/Linux distributions are > good. We actually have two versions, one from openjdk6 with a couple of > backports from the openjdk7 hotspot repo for crashes found with running > various applications (like eclipse). And one older snapshot of the > hotspot from openjdk7 that is used to base the zero/shark port on. It > would be good if we coordinated on good known stable versions of hotspot > whenever possible. > > > I'll leave this part of the question to someone with the > OpenJDK6 or OpenJDK7 projects. > > My interest in this whole thread is the AsyncGetCallTrace stuff. :-) > > Dan > > FWIW, I don't see any change to the HS_ version numbers in our patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. Given OpenJDK6 was derived from something like b20, I guess this is not that strange. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Daniel.Daugherty at Sun.COM Thu Sep 11 06:22:10 2008 From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty) Date: Thu, 11 Sep 2008 07:22:10 -0600 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> References: <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> Message-ID: <48C91B82.4020502@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080911/e28b5ad1/attachment.html From gnu_andrew at member.fsf.org Thu Sep 11 07:31:17 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 11 Sep 2008 15:31:17 +0100 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C91B82.4020502@sun.com> References: <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> Message-ID: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> 2008/9/11 Daniel D. Daugherty : > Andrew John Hughes wrote: > > FWIW, I don't see any change to the HS_ version numbers in our > patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. > Given OpenJDK6 was derived from something like b20, I guess this is > not that strange. > > JDK7-B24 has the following values: > > HS_MAJOR_VER=12 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=01 > > Joe stated earlier in this thread that OpenJDK6 is based on > HSX-10 so its values should not be the same. For 1.6.0_07, > I see: > > HS_MAJOR_VER=10 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=23 > > Dan > > > Hmmm... Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 is not based on the same as this 1.6.0_07 thing you mention. I'll try and have a closer look later. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From karen.kinnear at sun.com Thu Sep 11 08:21:29 2008 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Thu, 11 Sep 2008 15:21:29 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20080911152139.345ABD8FD@hg.openjdk.java.net> Changeset: b33eef719520 Author: xlu Date: 2008-08-25 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b33eef719520 6740526: sun/management/HotspotThreadMBean/GetInternalThreads.java test failed Reviewed-by: dholmes, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 23c6240101a0 Author: apangin Date: 2008-08-31 15:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/23c6240101a0 Merge Changeset: 93befa083681 Author: coleenp Date: 2008-09-02 15:18 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/93befa083681 6741004: UseLargePages + UseCompressedOops breaks implicit null checking guard page Summary: Turn off c2 implicit null checking on windows and large pages specified. Reviewed-by: jrose, xlu ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 24fc405437c9 Author: acorn Date: 2008-09-10 12:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/24fc405437c9 Merge - src/cpu/x86/vm/assembler_x86_32.cpp - src/cpu/x86/vm/assembler_x86_32.hpp - src/cpu/x86/vm/assembler_x86_32.inline.hpp - src/cpu/x86/vm/assembler_x86_64.cpp - src/cpu/x86/vm/assembler_x86_64.hpp - src/cpu/x86/vm/assembler_x86_64.inline.hpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp - src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp - src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp - src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp Changeset: 1eb509f14356 Author: acorn Date: 2008-09-11 09:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1eb509f14356 Merge From Kelly.Ohair at Sun.COM Thu Sep 11 09:23:06 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 11 Sep 2008 09:23:06 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> References: <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> Message-ID: <48C945EA.2050505@sun.com> A glossary like this: http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms ??? -kto Andrew John Hughes wrote: > 2008/9/11 Daniel D. Daugherty : >> Mark Wielaard wrote: >> >> Hi Daniel, >> >> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote: >> >> >> P-Team stands for "Product Team" I think :-) >> >> Those are the Sun folks that make the business decisions about >> HotSpot Express. The HotSpot P-Team approved the current >> versioning system that is used for HotSpot Express releases >> so they need to be kept in the loop when there are issues >> with HSX version numbers. >> >> >> Thanks. Which brings a followup question. What is "HotSpot Express"? >> >> >> Just the name given to the idea of releasing VMs independently >> of JDK/JRE releases. I'm sure someone else out there has a >> better definition... :-) >> > > I think an OpenJDK glossary is in order, if we don't already have one... ;) > >> The thing I am really after is making sure that the versions of hotspot >> that we ship with IcedTea in the various GNU/Linux distributions are >> good. We actually have two versions, one from openjdk6 with a couple of >> backports from the openjdk7 hotspot repo for crashes found with running >> various applications (like eclipse). And one older snapshot of the >> hotspot from openjdk7 that is used to base the zero/shark port on. It >> would be good if we coordinated on good known stable versions of hotspot >> whenever possible. >> >> >> I'll leave this part of the question to someone with the >> OpenJDK6 or OpenJDK7 projects. >> >> My interest in this whole thread is the AsyncGetCallTrace stuff. :-) >> >> Dan >> >> > > FWIW, I don't see any change to the HS_ version numbers in our > patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. > Given OpenJDK6 was derived from something like b20, I guess this is > not that strange. > > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Sep 11 09:23:02 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 11 Sep 2008 09:23:02 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> References: <48C59F62.4040806@sun.com> <1220944059.3348.4.camel@dijkstra.wildebeest.org> <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> Message-ID: <48C945E6.6090709@sun.com> Andrew John Hughes wrote: > 2008/9/11 Daniel D. Daugherty : >> Mark Wielaard wrote: >> >> Hi Daniel, >> >> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote: >> >> >> P-Team stands for "Product Team" I think :-) >> >> Those are the Sun folks that make the business decisions about >> HotSpot Express. The HotSpot P-Team approved the current >> versioning system that is used for HotSpot Express releases >> so they need to be kept in the loop when there are issues >> with HSX version numbers. >> >> >> Thanks. Which brings a followup question. What is "HotSpot Express"? >> >> >> Just the name given to the idea of releasing VMs independently >> of JDK/JRE releases. I'm sure someone else out there has a >> better definition... :-) >> > > I think an OpenJDK glossary is in order, if we don't already have one... ;) There is a a glossary as part of the OpenJDK Developers' guide: http://openjdk.java.net/guide/glossary.html However, it hasn't been updated in a while and it should be expanded to cover more terms. -Joe From gnu_andrew at member.fsf.org Thu Sep 11 14:36:51 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 11 Sep 2008 22:36:51 +0100 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C945EA.2050505@sun.com> References: <48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C945EA.2050505@sun.com> Message-ID: <17c6771e0809111436m3c914921x557a8611e5e5b2bf@mail.gmail.com> 2008/9/11 Kelly O'Hair : > A glossary like this: > > http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms > > ??? > > -kto > > Andrew John Hughes wrote: >> >> 2008/9/11 Daniel D. Daugherty : >>> >>> Mark Wielaard wrote: >>> >>> Hi Daniel, >>> >>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote: >>> >>> >>> P-Team stands for "Product Team" I think :-) >>> >>> Those are the Sun folks that make the business decisions about >>> HotSpot Express. The HotSpot P-Team approved the current >>> versioning system that is used for HotSpot Express releases >>> so they need to be kept in the loop when there are issues >>> with HSX version numbers. >>> >>> >>> Thanks. Which brings a followup question. What is "HotSpot Express"? >>> >>> >>> Just the name given to the idea of releasing VMs independently >>> of JDK/JRE releases. I'm sure someone else out there has a >>> better definition... :-) >>> >> >> I think an OpenJDK glossary is in order, if we don't already have one... >> ;) >> >>> The thing I am really after is making sure that the versions of hotspot >>> that we ship with IcedTea in the various GNU/Linux distributions are >>> good. We actually have two versions, one from openjdk6 with a couple of >>> backports from the openjdk7 hotspot repo for crashes found with running >>> various applications (like eclipse). And one older snapshot of the >>> hotspot from openjdk7 that is used to base the zero/shark port on. It >>> would be good if we coordinated on good known stable versions of hotspot >>> whenever possible. >>> >>> >>> I'll leave this part of the question to someone with the >>> OpenJDK6 or OpenJDK7 projects. >>> >>> My interest in this whole thread is the AsyncGetCallTrace stuff. :-) >>> >>> Dan >>> >>> >> >> FWIW, I don't see any change to the HS_ version numbers in our >> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >> Given OpenJDK6 was derived from something like b20, I guess this is >> not that strange. >> >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > Errr.... yes.. spot on. I've linked that from the IcedTea wiki now. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Thu Sep 11 15:10:08 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 11 Sep 2008 23:10:08 +0100 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> References: <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> Message-ID: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> 2008/9/11 Andrew John Hughes : > 2008/9/11 Daniel D. Daugherty : >> Andrew John Hughes wrote: >> >> FWIW, I don't see any change to the HS_ version numbers in our >> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >> Given OpenJDK6 was derived from something like b20, I guess this is >> not that strange. >> >> JDK7-B24 has the following values: >> >> HS_MAJOR_VER=12 >> HS_MINOR_VER=0 >> HS_BUILD_NUMBER=01 >> >> Joe stated earlier in this thread that OpenJDK6 is based on >> HSX-10 so its values should not be the same. For 1.6.0_07, >> I see: >> >> HS_MAJOR_VER=10 >> HS_MINOR_VER=0 >> HS_BUILD_NUMBER=23 >> >> Dan >> >> >> > > Hmmm... > Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 > is not based on the same as this 1.6.0_07 thing you mention. > I'll try and have a closer look later. > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > IcedTea6 contains: HS_MAJOR_VER=10 HS_MINOR_VER=0 HS_BUILD_NUMBER=19 IcedTea/b33 contains: HS_MAJOR_VER=14 HS_MINOR_VER=0 HS_BUILD_NUMBER=01 icedtea-hotspot-6b11-7b24.patch only updates the src code and not make/hotspot_version so it's actually worryingly building a different version of HotSpot from the one it thinks it is. It will actually be 12-0-01 as you state, but will report 10-0-19. Overall, it would be better to always build against the most recent stable HotSpot tree if possible rather than the one provided by the build drop. Do we know what the most stable would be? -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Thu Sep 11 16:42:13 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 11 Sep 2008 16:42:13 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> References: <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> Message-ID: <48C9ACD5.7030102@sun.com> Andrew John Hughes wrote: > 2008/9/11 Andrew John Hughes : >> 2008/9/11 Daniel D. Daugherty : >>> Andrew John Hughes wrote: >>> >>> FWIW, I don't see any change to the HS_ version numbers in our >>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>> Given OpenJDK6 was derived from something like b20, I guess this is >>> not that strange. >>> >>> JDK7-B24 has the following values: >>> >>> HS_MAJOR_VER=12 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=01 >>> >>> Joe stated earlier in this thread that OpenJDK6 is based on >>> HSX-10 so its values should not be the same. For 1.6.0_07, >>> I see: >>> >>> HS_MAJOR_VER=10 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=23 >>> >>> Dan >>> >>> >>> >> Hmmm... >> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >> is not based on the same as this 1.6.0_07 thing you mention. >> I'll try and have a closer look later. >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > > IcedTea6 contains: > > HS_MAJOR_VER=10 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=19 > > IcedTea/b33 contains: > > HS_MAJOR_VER=14 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=01 > > icedtea-hotspot-6b11-7b24.patch only updates the src code and not > make/hotspot_version > so it's actually worryingly building a different version of HotSpot > from the one it thinks it is. > It will actually be 12-0-01 as you state, but will report 10-0-19. > > Overall, it would be better to always build against the most recent > stable HotSpot tree if possible > rather than the one provided by the build drop. Do we know what the > most stable would be? Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. The policy I've implemented, http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases, augmented with some other fixes for license corrections, gcc build issues, (and the occasional Eclipse crash). The HotSpot in the base OpenJDK 6 code base is very close to the HotSpot in the currently shipping 6 update release. -Joe From martinrb at google.com Thu Sep 11 16:44:07 2008 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Sep 2008 16:44:07 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> References: <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> Message-ID: <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com> [+doko, who might be interested in this discussion on jdk6-dev at openjdk.java.net] So...how come icedtea 6 (on Ubuntu Hardy) reports a hotspot version number that is not an actual hotspot version number? Should be "OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)" (martinrb at spraggett) ~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) (martinrb at spraggett) ~ $ dpkg -S /usr/lib/jvm/java-6-openjdk/bin/java openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/bin/java (martinrb at spraggett) ~ $ aptitude show openjdk-6-jre-headless Package: openjdk-6-jre-headless Version: 6b11-2ubuntu2 Maintainer: Ubuntu MOTU Developers ... Martin On Thu, Sep 11, 2008 at 15:10, Andrew John Hughes wrote: > 2008/9/11 Andrew John Hughes : >> 2008/9/11 Daniel D. Daugherty : >>> Andrew John Hughes wrote: >>> >>> FWIW, I don't see any change to the HS_ version numbers in our >>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>> Given OpenJDK6 was derived from something like b20, I guess this is >>> not that strange. >>> >>> JDK7-B24 has the following values: >>> >>> HS_MAJOR_VER=12 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=01 >>> >>> Joe stated earlier in this thread that OpenJDK6 is based on >>> HSX-10 so its values should not be the same. For 1.6.0_07, >>> I see: >>> >>> HS_MAJOR_VER=10 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=23 >>> >>> Dan >>> >>> >>> >> >> Hmmm... >> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >> is not based on the same as this 1.6.0_07 thing you mention. >> I'll try and have a closer look later. >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > > IcedTea6 contains: > > HS_MAJOR_VER=10 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=19 > > IcedTea/b33 contains: > > HS_MAJOR_VER=14 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=01 > > icedtea-hotspot-6b11-7b24.patch only updates the src code and not > make/hotspot_version > so it's actually worryingly building a different version of HotSpot > from the one it thinks it is. > It will actually be 12-0-01 as you state, but will report 10-0-19. > > Overall, it would be better to always build against the most recent > stable HotSpot tree if possible > rather than the one provided by the build drop. Do we know what the > most stable would be? > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > From Paul.Hohensee at Sun.COM Thu Sep 11 17:19:29 2008 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Thu, 11 Sep 2008 20:19:29 -0400 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> References: <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> Message-ID: <48C9B591.9020308@sun.com> The most stable version will vary. We'd like the openjdk version to be product-ready, but we haven't been able to do that yet. For now the most stable version is 6-open, which is hotspot 10 plus fixes. When 6u10 ships, our plan is to push the vm that comes with it (hotspot 11) into 6-open. Paul Andrew John Hughes wrote: > 2008/9/11 Andrew John Hughes : > >> 2008/9/11 Daniel D. Daugherty : >> >>> Andrew John Hughes wrote: >>> >>> FWIW, I don't see any change to the HS_ version numbers in our >>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>> Given OpenJDK6 was derived from something like b20, I guess this is >>> not that strange. >>> >>> JDK7-B24 has the following values: >>> >>> HS_MAJOR_VER=12 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=01 >>> >>> Joe stated earlier in this thread that OpenJDK6 is based on >>> HSX-10 so its values should not be the same. For 1.6.0_07, >>> I see: >>> >>> HS_MAJOR_VER=10 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=23 >>> >>> Dan >>> >>> >>> >>> >> Hmmm... >> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >> is not based on the same as this 1.6.0_07 thing you mention. >> I'll try and have a closer look later. >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > IcedTea6 contains: > > HS_MAJOR_VER=10 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=19 > > IcedTea/b33 contains: > > HS_MAJOR_VER=14 > HS_MINOR_VER=0 > HS_BUILD_NUMBER=01 > > icedtea-hotspot-6b11-7b24.patch only updates the src code and not > make/hotspot_version > so it's actually worryingly building a different version of HotSpot > from the one it thinks it is. > It will actually be 12-0-01 as you state, but will report 10-0-19. > > Overall, it would be better to always build against the most recent > stable HotSpot tree if possible > rather than the one provided by the build drop. Do we know what the > most stable would be? > From gnu_andrew at member.fsf.org Thu Sep 11 18:17:50 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 12 Sep 2008 02:17:50 +0100 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com> References: <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com> Message-ID: <17c6771e0809111817p14bca28sabc5b89844076e82@mail.gmail.com> 2008/9/12 Martin Buchholz : > [+doko, who might be interested in this discussion on jdk6-dev at openjdk.java.net] > > So...how come icedtea 6 (on Ubuntu Hardy) reports > a hotspot version number that is not an actual hotspot version number? > Should be "OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)" > > (martinrb at spraggett) ~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version > java version "1.6.0_0" > OpenJDK Runtime Environment (build 1.6.0_0-b11) > OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) > (martinrb at spraggett) ~ $ dpkg -S /usr/lib/jvm/java-6-openjdk/bin/java > openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/bin/java > (martinrb at spraggett) ~ $ aptitude show openjdk-6-jre-headless > Package: openjdk-6-jre-headless > Version: 6b11-2ubuntu2 > Maintainer: Ubuntu MOTU Developers > ... > > Martin > > On Thu, Sep 11, 2008 at 15:10, Andrew John Hughes > wrote: >> 2008/9/11 Andrew John Hughes : >>> 2008/9/11 Daniel D. Daugherty : >>>> Andrew John Hughes wrote: >>>> >>>> FWIW, I don't see any change to the HS_ version numbers in our >>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>> not that strange. >>>> >>>> JDK7-B24 has the following values: >>>> >>>> HS_MAJOR_VER=12 >>>> HS_MINOR_VER=0 >>>> HS_BUILD_NUMBER=01 >>>> >>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>> I see: >>>> >>>> HS_MAJOR_VER=10 >>>> HS_MINOR_VER=0 >>>> HS_BUILD_NUMBER=23 >>>> >>>> Dan >>>> >>>> >>>> >>> >>> Hmmm... >>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >>> is not based on the same as this 1.6.0_07 thing you mention. >>> I'll try and have a closer look later. >>> -- >>> Andrew :-) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> >> IcedTea6 contains: >> >> HS_MAJOR_VER=10 >> HS_MINOR_VER=0 >> HS_BUILD_NUMBER=19 >> >> IcedTea/b33 contains: >> >> HS_MAJOR_VER=14 >> HS_MINOR_VER=0 >> HS_BUILD_NUMBER=01 >> >> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >> make/hotspot_version >> so it's actually worryingly building a different version of HotSpot >> from the one it thinks it is. >> It will actually be 12-0-01 as you state, but will report 10-0-19. >> >> Overall, it would be better to always build against the most recent >> stable HotSpot tree if possible >> rather than the one provided by the build drop. Do we know what the >> most stable would be? >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > All IcedTea builds are like this: $ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) $ ~/builder/icedtea/openjdk/build/linux-amd64/bin/java -version java version "1.7.0_0" IcedTea Runtime Environment (build 1.7.0_0-b33) OpenJDK 64-Bit Server VM (build 1.7.0_0-b33, mixed mode) -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From john.coomes at sun.com Thu Sep 11 22:38:02 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Sep 2008 05:38:02 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20080912053802.A0BB1DAC6@hg.openjdk.java.net> Changeset: 46a989ab9329 Author: ohair Date: 2008-08-17 09:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/46a989ab9329 6737659: debug bundles are empty Summary: Build order issue with debug build, caused final debug bundle to be empty. Reviewed-by: tbell ! Makefile Changeset: 143c1abedb7d Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/143c1abedb7d Added tag jdk7-b34 for changeset 46a989ab9329 ! .hgtags Changeset: 4d52a6465eb0 Author: xdono Date: 2008-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4d52a6465eb0 Added tag jdk7-b35 for changeset 143c1abedb7d ! .hgtags From john.coomes at sun.com Thu Sep 11 22:38:55 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Sep 2008 05:38:55 +0000 Subject: hg: jdk7/hotspot/corba: 2 new changesets Message-ID: <20080912053857.43766DACB@hg.openjdk.java.net> Changeset: 3867c4d14a5b Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/3867c4d14a5b Added tag jdk7-b34 for changeset 0a812b9824e5 ! .hgtags Changeset: 545dffad4849 Author: xdono Date: 2008-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/545dffad4849 Added tag jdk7-b35 for changeset 3867c4d14a5b ! .hgtags From john.coomes at sun.com Thu Sep 11 22:41:32 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Sep 2008 05:41:32 +0000 Subject: hg: jdk7/hotspot/jaxp: 2 new changesets Message-ID: <20080912054135.EB8CDDAD4@hg.openjdk.java.net> Changeset: eac46d1eb7f0 Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/eac46d1eb7f0 Added tag jdk7-b34 for changeset 01facdf8cabd ! .hgtags Changeset: c84ca638db42 Author: xdono Date: 2008-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/c84ca638db42 Added tag jdk7-b35 for changeset eac46d1eb7f0 ! .hgtags From john.coomes at sun.com Thu Sep 11 22:42:28 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Sep 2008 05:42:28 +0000 Subject: hg: jdk7/hotspot/jaxws: 2 new changesets Message-ID: <20080912054231.E0AA8DADD@hg.openjdk.java.net> Changeset: b0f01c2508b6 Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/b0f01c2508b6 Added tag jdk7-b34 for changeset 7a9f629cd957 ! .hgtags Changeset: f60187f44a0d Author: xdono Date: 2008-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/f60187f44a0d Added tag jdk7-b35 for changeset b0f01c2508b6 ! .hgtags From john.coomes at sun.com Thu Sep 11 22:44:10 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Sep 2008 05:44:10 +0000 Subject: hg: jdk7/hotspot/jdk: 26 new changesets Message-ID: <20080912054918.B9282DAE4@hg.openjdk.java.net> Changeset: b010683123b3 Author: ohair Date: 2008-08-14 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b010683123b3 6674227: Missing LICENSE file during build Summary: Just a JPRT usage issue. The top level files (like LICENSE) are needed to create the jdk image (j2sdk-image directory). Reviewed-by: tbell ! make/jprt.properties Changeset: ac68bf5140b2 Author: ohair Date: 2008-08-14 20:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ac68bf5140b2 Merge - make/java/nio/spp.sh - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h Changeset: db4bd081eff2 Author: ksrini Date: 2008-08-19 07:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/db4bd081eff2 6614210: JPRT Windows 32bit msival2 build failure when building 'install' workspace Summary: suppresses wscript's modal dialog on error and no msi validation for jprt. Reviewed-by: ohair, jmelvin ! make/common/shared/Defs-windows.gmk Changeset: 434055a0716e Author: xdono Date: 2008-08-21 09:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/434055a0716e Merge Changeset: bf580c41f68f Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bf580c41f68f Added tag jdk7-b34 for changeset 434055a0716e ! .hgtags Changeset: cf403a69449a Author: jjh Date: 2008-08-15 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cf403a69449a 6737900: TEST: Some JDI regression tests timeout on slow machines Summary: Don't execute useless code, and split test into multiple @runs. Reviewed-by: tbell ! test/com/sun/jdi/ClassesByName2Test.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/sde/MangleStepTest.java Changeset: e093efae8c5f Author: ohair Date: 2008-08-17 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e093efae8c5f 6496269: Many warnings generated from com/sun/java/util/jar/pack/*.cpp when compiled on Linux Summary: Removal of compiler warnings and fixing of assert logic. Reviewed-by: jrose, ksrini, bristor ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/bytes.h ! src/share/native/com/sun/java/util/jar/pack/coding.cpp ! src/share/native/com/sun/java/util/jar/pack/coding.h ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/jni.cpp ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h ! src/share/native/com/sun/java/util/jar/pack/zip.cpp ! src/share/native/com/sun/java/util/jar/pack/zip.h Changeset: 092985e71d9e Author: tbell Date: 2008-08-18 09:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/092985e71d9e Merge Changeset: 17527939e5b1 Author: swamyv Date: 2008-08-18 15:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/17527939e5b1 6705893: javax.script tests should not require a js engine on OpenJDK Summary: Fixed the tests to pass with open JDK. Reviewed-by: darcy ! test/javax/script/E4XErrorTest.java + test/javax/script/Helper.java ! test/javax/script/JavaScriptScopeTest.java ! test/javax/script/NullUndefinedVarTest.java ! test/javax/script/PluggableContextTest.java ! test/javax/script/ProviderTest.java ! test/javax/script/RhinoExceptionTest.java ! test/javax/script/Test1.java ! test/javax/script/Test2.java ! test/javax/script/Test3.java ! test/javax/script/Test4.java ! test/javax/script/Test5.java ! test/javax/script/Test6.java ! test/javax/script/Test7.java ! test/javax/script/Test8.java ! test/javax/script/VersionTest.java + test/sun/tools/jrunscript/CheckEngine.java ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-DTest.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-cpTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh Changeset: b6f746b0ecc4 Author: swamyv Date: 2008-08-19 12:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b6f746b0ecc4 6736461: ThreadMXBean Locks.java fails intermittently. Summary: Fixed the test to wait for the right state before calling check thread information. Reviewed-by: jjh ! test/java/lang/management/ThreadMXBean/Locks.java Changeset: 1b114828900b Author: tbell Date: 2008-08-19 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1b114828900b Merge Changeset: 9f53e194687c Author: tbell Date: 2008-08-25 23:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9f53e194687c Merge Changeset: dc4067f914a2 Author: martin Date: 2008-08-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dc4067f914a2 6739302: Check that deserialization preserves EnumSet integrity Reviewed-by: dl, chegar Contributed-by: jjb at google.com ! src/share/classes/java/util/EnumSet.java + test/java/util/EnumSet/BogusEnumSet.java Changeset: 52fbd007f47b Author: swamyv Date: 2008-08-22 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/52fbd007f47b 6653883: jmap with no option should print mmap instead of heap information. Summary: Changed the default option of jmap to print mmap. Reviewed-by: jjh ! src/share/classes/sun/tools/jmap/JMap.java Changeset: 3a4370604bab Author: ohair Date: 2008-08-22 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3a4370604bab 6732421: Removed old javavm and Classic VM files from the jdk7 sources Reviewed-by: alanb ! make/common/Defs.gmk ! make/java/verify/Makefile ! make/netbeans/awt2d/README ! make/tools/GenerateCharacter/check_class.c.template ! src/share/back/debugDispatch.c ! src/share/back/error_messages.c ! src/share/back/inStream.c ! src/share/back/outStream.h ! src/share/instrument/InstrumentationImplNativeMethods.c ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvm.h - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h ! src/share/native/common/check_code.c ! src/share/native/common/check_format.c ! src/solaris/back/util_md.h ! src/solaris/instrument/FileSystemSupport_md.h ! src/solaris/javavm/export/jvm_md.h - src/solaris/javavm/include/typedefs_md.h ! src/solaris/native/common/gdefs_md.h ! src/solaris/native/common/jlong_md.h ! src/windows/back/util_md.h ! src/windows/hpi/src/socket_md.c ! src/windows/hpi/src/threads_md.c ! src/windows/instrument/FileSystemSupport_md.h ! src/windows/javavm/export/jvm_md.h - src/windows/javavm/include/typedefs_md.h ! src/windows/native/java/net/net_util_md.c Changeset: 3dcc69147ff9 Author: sherman Date: 2008-08-22 14:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3dcc69147ff9 4486841: UTF-8 decoder should adhere to corrigendum to Unicode 3.0.1 6636317: Optimize UTF-8 coder for ASCII input Summary: re-write the UTF-8 charset to obey the standard and improve the performance Reviewed-by: alanb ! src/share/classes/sun/nio/cs/UTF_8.java + test/sun/nio/cs/TestUTF8.java Changeset: a33cf5828b82 Author: sherman Date: 2008-08-22 22:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a33cf5828b82 6740702: Comment tag update Summary: tag update Reviewed-by: mr ! src/share/classes/sun/nio/cs/UTF_8.java Changeset: a4ff2fe5b5d9 Author: weijun Date: 2008-08-06 08:11 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a4ff2fe5b5d9 6731685: CertificateFactory.generateCertificates throws IOException on PKCS7 cert chain Reviewed-by: mullan ! src/share/classes/sun/security/util/DerIndefLenConverter.java + test/sun/security/util/DerValue/Indefinite.java Changeset: 97d08b2b4539 Author: chegar Date: 2008-08-06 07:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97d08b2b4539 6734171: java.net.NetworkInterface reports XCheck:jni warnings Summary: Removed leading "L" or trailing ";" from FindClass classname param Reviewed-by: alanb ! src/windows/native/java/net/NetworkInterface.c Changeset: 874f4db252e3 Author: wetmore Date: 2008-08-20 00:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/874f4db252e3 Merge Changeset: afcf04c535da Author: michaelm Date: 2008-08-21 10:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/afcf04c535da 6258215: Num of backlog in ServerSocket(int, int) should be mentioned more explicitly Summary: updated javadoc Reviewed-by: chegar ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java Changeset: f4289d75cd29 Author: jccollet Date: 2008-08-25 14:38 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f4289d75cd29 6717876: Make java.net.NetworkInterface.getIndex() public Summary: Make getIndex() and getByIndex() public. Required a name change in native code Reviewed-by: alanb, chegar, michaelm ! make/java/net/mapfile-vers ! src/share/classes/java/net/NetworkInterface.java ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/net_util_md.h + test/java/net/NetworkInterface/IndexTest.java Changeset: 872241636752 Author: wetmore Date: 2008-08-25 08:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/872241636752 Merge Changeset: c5f211538cad Author: tbell Date: 2008-08-25 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c5f211538cad Merge - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h Changeset: cf4894b78ceb Author: tbell Date: 2008-08-29 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cf4894b78ceb Merge Changeset: baae64ef16f6 Author: xdono Date: 2008-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/baae64ef16f6 Added tag jdk7-b35 for changeset cf4894b78ceb ! .hgtags From john.coomes at sun.com Thu Sep 11 22:53:34 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Sep 2008 05:53:34 +0000 Subject: hg: jdk7/hotspot/langtools: 4 new changesets Message-ID: <20080912055342.3E679DAE9@hg.openjdk.java.net> Changeset: 8889fb6c5af0 Author: xdono Date: 2008-08-28 11:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8889fb6c5af0 Added tag jdk7-b34 for changeset 4026dece07e8 ! .hgtags Changeset: 37551dc0f591 Author: mcimadamore Date: 2008-08-22 11:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/37551dc0f591 6733837: Recent work on javac diagnostic affected javac output Summary: Problems with diagnostic path and tab character in the source code Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/api/6733837/T6733837.java Changeset: 81f66dd906eb Author: tbell Date: 2008-08-29 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/81f66dd906eb Merge Changeset: ae2a1418f0c8 Author: xdono Date: 2008-09-11 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ae2a1418f0c8 Added tag jdk7-b35 for changeset 81f66dd906eb ! .hgtags From daniel.daugherty at sun.com Fri Sep 12 11:03:05 2008 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Fri, 12 Sep 2008 18:03:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20080912180309.076ACDB65@hg.openjdk.java.net> Changeset: 68e0443dfd9c Author: ohair Date: 2008-09-11 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/68e0443dfd9c 6745363: Add ability to run packtest to hotspot/test/makefile Reviewed-by: ksrini ! make/jprt.properties ! test/Makefile Changeset: 0ba3ec980ae5 Author: dcubed Date: 2008-09-12 07:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0ba3ec980ae5 Merge From Joe.Darcy at Sun.COM Fri Sep 12 11:37:18 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 12 Sep 2008 11:37:18 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48C9ACD5.7030102@sun.com> References: <48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com> <1221086482.26700.10.camel@hermans.wildebeest.org> <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> Message-ID: <48CAB6DE.8070806@sun.com> Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> 2008/9/11 Andrew John Hughes : >>> 2008/9/11 Daniel D. Daugherty : >>>> Andrew John Hughes wrote: >>>> >>>> FWIW, I don't see any change to the HS_ version numbers in our >>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>> not that strange. >>>> >>>> JDK7-B24 has the following values: >>>> >>>> HS_MAJOR_VER=12 >>>> HS_MINOR_VER=0 >>>> HS_BUILD_NUMBER=01 >>>> >>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>> I see: >>>> >>>> HS_MAJOR_VER=10 >>>> HS_MINOR_VER=0 >>>> HS_BUILD_NUMBER=23 >>>> >>>> Dan >>>> >>>> >>>> >>> Hmmm... >>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >>> is not based on the same as this 1.6.0_07 thing you mention. >>> I'll try and have a closer look later. >>> -- >>> Andrew :-) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> >> IcedTea6 contains: >> >> HS_MAJOR_VER=10 >> HS_MINOR_VER=0 >> HS_BUILD_NUMBER=19 >> >> IcedTea/b33 contains: >> >> HS_MAJOR_VER=14 >> HS_MINOR_VER=0 >> HS_BUILD_NUMBER=01 >> >> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >> make/hotspot_version >> so it's actually worryingly building a different version of HotSpot >> from the one it thinks it is. >> It will actually be 12-0-01 as you state, but will report 10-0-19. >> >> Overall, it would be better to always build against the most recent >> stable HotSpot tree if possible >> rather than the one provided by the build drop. Do we know what the >> most stable would be? > > Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. > The policy I've implemented, > http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, > > for the HotSpot in OpenJDK 6 is to track fixes in the 6 update > releases, augmented with some other fixes for license corrections, gcc > build issues, (and the occasional Eclipse crash). The HotSpot in the > base OpenJDK 6 code base is very close to the HotSpot in the currently > shipping 6 update release. ... and going forward we will have much closer coordination between the OpenJDK 6 and 6 update HotSpots since we'll be using the same source for both; so the version information should be updated consistently, etc. http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html -Joe From fw at deneb.enyo.de Sat Sep 13 01:27:19 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 13 Sep 2008 10:27:19 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4895EC16.6030406@ubuntu.com> (Matthias Klose's message of "Sun, 03 Aug 2008 19:34:14 +0200") References: <4895EC16.6030406@ubuntu.com> Message-ID: <8763p0mowo.fsf@mid.deneb.enyo.de> * Matthias Klose: > attached are three patches to build on architectures with a signed size_t > (s390-linux-gnu). > > - jdk-signed-size_t.diff, there's already a compat SSIZE_T macro in the code, > just use it. > > - hotspot-idx_t-signed-size_t.diff, the BitMap code assumes a unsigned > size_t. > > - hotspot-params-signed-size_t.diff, command line parameters of type > size_t currently are not supported. As a workaround, add casts. This > may be better addressed. So what has happened to this patch? From Joe.Darcy at Sun.COM Mon Sep 15 19:56:54 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 15 Sep 2008 19:56:54 -0700 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 In-Reply-To: References: <48B542EA.7040201@sun.com> Message-ID: <48CF2076.5060309@sun.com> Volker Simonis wrote: > Hi David, > > I don't think that the problems are related although they are similar. > In my case the problem is caused by the FPSW (on Windows, on Linux in > gdb it's "fstat") register which is the status word for the FPU > (formerly known as x87 and later as MMX) registers. > > The problem is that MSVC apperently doesn't support these registers > any more in the sense that it doesn't generate code which uses them. > This is probably also the reason why there "_clearfp()" function does > not clear FPSW register but only the more modern MXCSR register (which > is the status register for the XMM register set (also known as > SSE2/SSE3)). > > On the other hand, Microsoft is STILL using the old FPU registers in > their runtime functions (particularly in the "fmod()" function). And > this usage interfers with the usage of the old FPU registers by the > code generated from the HotSpot JIT compiler. I have no idea how the > ABI convention for the FPSW register are and if such conventions even > exist (I would be thankful for any pointer here). As Tom commented, > the code generated by the JIT is aware of this behaviour but other > C/library/JNI code may not. > IIRC, the ABI specification for x64 allows the x87 control word to *not* be saved/restored across context switches in 64-bit mode depending on the OS. Again IIRC, the Unix ABI for x64 *does* preserve the x87 control word in these cases but the Windows ABI does not. -Joe > Regards, > Volker > > On 8/27/08, David Holmes - Sun Microsystems wrote: > >> Hi Volker, >> >> I don't know if this is related, or just coincidental timing but a new bug >> report has just been filed: >> >> 6741940 Nonvolatile XMM registers not preserved across JNI calls >> >> "Calls to the JNI entry point "CallVoidMethod" [in test program] do not >> preserve the nonvolatile XMM registers, unless running with -Xint. This is >> in violation of the Windows 64-bit ABI: >> http://msdn.microsoft.com/en-us/library/ms794547.aspx" >> >> This won't show up on BugParade for a day or so. >> >> Regards, >> David Holmes >> >> Volker Simonis said the following on 08/26/08 05:19: >> >> >> >>> Hi, >>> >>> we had a strange problem wich lead to failures in the JCK test >>> Math2012. The problem only occured if some other JCK-Tests where >>> compiled and execuetd in a special order before the tests in >>> Math2012. >>> >>> I could finally track down the problem to the following simple test case: >>> >>> ==================================================== >>> public class Log10 { >>> >>> public static double log10(double d) { >>> return Math.log10(d); >>> } >>> >>> public static double drem2(double d) { >>> return d % 2; >>> } >>> >>> public static void main(String args[]) { >>> System.out.println("log10(0) = " + Math.log10(0.0d)); >>> System.out.println("log10(0) = " + log10(0.0d)); >>> System.out.println("drem2(4.0) = " + drem2(4.0d)); >>> } >>> } >>> ==================================================== >>> >>> which always fails on Windows/x86_64 (i.e. prints "NaN" for the result >>> of 4.0 % 2.0 which should be 0.0) if executed like this: >>> >>> java -Xcomp -Xbatch -XX:CompileCommand="compileonly Log10 >>> >> log10" >> >>> -XX:+PrintCompilation Log10 >>> >>> VM option 'CompileCommand=compileonly Log10 log10' >>> VM option '+PrintCompilation' >>> CompilerOracle: compileonly Log10.log10 >>> log10(0) = -Infinity >>> 1 b Log10::log10 (5 bytes) >>> log10(0) = -Infinity >>> drem2(4.0) = NaN >>> >>> Notice however that we are using a version of the Java 6 HotSpot >>> compiled with Visual Studio 2005. >>> >>> I couldn't reproduce the problem with >>> jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 however I >>> >> could verify >> >>> that the code generated by both, our JDK 6 and the latest jdk-7 is >>> virtually the same. The interesting part is the compiled version of >>> the method Log10.log10(): >>> >>> 000 pushq rbp >>> subq rsp, #16 # Create frame >>> nop # nop for patch_verified_entry >>> 006 fldlg2 #Log10 >>> fyl2x # Q=Log10*Log_2(x) >>> 024 addq rsp, 16 # Destroy frame >>> popq rbp >>> testl rax, [rip + #offset_to_poll_page] # Safepoint: poll >>> >> for GC >> >>> 02f ret >>> >>> The computation of Math.log10(0.0d) which correctly returns -Infinity >>> sets the "Zero Divide" flag in the FP status word as described in >>> >>> >> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf. >> >>> After this computation "SharedRuntime::drem()" is called for the >>> computation of the double reminder in the method "drem2()" of the >>> above example. "SharedRuntime::drem()" itself just delegates the >>> computation to the "fmod()" function (defined in ) of the >>> underlying platform. >>> >>> The presence of the "Zero Divide" flag in the FP status word seems to >>> be no problem for the "fmod()" which is used by the >>> jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 executable >>> >> (from >> >>> msvcr71.dll) and it is no problem on Linux/x86_64 either, but it IS >>> definitely a problem for the "fmod()" from the "msvcr80d.dll" which is >>> used in our MSVC 2005 build. >>> >>> I have two questions now: >>> >>> 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions >>> bits as they are in the FP status word? >>> 2. Can somebody confirm that the described behaviour of "fmod()" from >>> "msvcr80d.dll" as used by MSVC 2005 is buggy? (I couldn't find any bug >>> report and I also couldn't find reference if "fmod() should depend on >>> the FP status word or not.) >>> >>> It would also be nice if somebody who has recent OpenJDK built with >>> MSVC 2005 could confirm the above problem or if somebody could just >>> confirm or disprove the "fmod()" problem within different versions of >>> MSVC. Here's a small C-program which can be used to test if "fmod()" >>> is dependent on the FP status word: >>> >>> ====================== fmod.c ==================== >>> #include >>> #include >>> >>> extern void fpu_asm(); >>> >>> int main(int argc, char* argv[]) { >>> >>> double d = 0.0; >>> >>> printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); >>> >>> fpu_asm(); >>> >>> printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); >>> >>> } >>> ===================================================== >>> >>> ===================== fpu_asm.asm ==================== >>> PUBLIC fpu_asm >>> .CODE >>> ALIGN 8 >>> fpu_asm PROC >>> fldlg2 >>> fldz >>> fyl2x >>> ret >>> ALIGN 8 >>> fpu_asm ENDP >>> END >>> ====================================================== >>> >>> Compile and run with: >>> >>> ml64 /c fpu_asm.asm >>> cl fmod.c fpu_asm.obj >>> fmod.exe >>> fmod(4.0, 2.0) = 0.000000 >>> fmod(4.0, 2.0) = -1.#IND00 >>> >>> Regards, >>> Volker >>> >>> PS: the obvious solution of calling "_clearfp()" as defined in >>> just before a call to "fmod()" unfortunately doesn't work, >>> because "_clearfp()" (at least in MSVC 2005) only cleans the SSE >>> status register MXCSR. The only solution I see right now is using the >>> FCLEX assembler instruction, and because MSVC 2005 has no inline >>> assembler for x86_64 I'll probably have to write the whole assembler >>> function for the assembler instruction. Or does somebody have a >>> smarter solution? >>> >>> PPS: this is a nice example, how a compiler switch can get you a lot >>> of fun (isn't it Kelly:) ... >>> >>> From volker.simonis at gmail.com Tue Sep 16 01:46:47 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 16 Sep 2008 10:46:47 +0200 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 In-Reply-To: <48CF2076.5060309@sun.com> References: <48B542EA.7040201@sun.com> <48CF2076.5060309@sun.com> Message-ID: On 9/16/08, Joseph D. Darcy wrote: > Volker Simonis wrote: > > > Hi David, > > > > I don't think that the problems are related although they are similar. > > In my case the problem is caused by the FPSW (on Windows, on Linux in > > gdb it's "fstat") register which is the status word for the FPU > > (formerly known as x87 and later as MMX) registers. > > > > The problem is that MSVC apperently doesn't support these registers > > any more in the sense that it doesn't generate code which uses them. > > This is probably also the reason why there "_clearfp()" function does > > not clear FPSW register but only the more modern MXCSR register (which > > is the status register for the XMM register set (also known as > > SSE2/SSE3)). > > > > On the other hand, Microsoft is STILL using the old FPU registers in > > their runtime functions (particularly in the "fmod()" function). And > > this usage interfers with the usage of the old FPU registers by the > > code generated from the HotSpot JIT compiler. I have no idea how the > > ABI convention for the FPSW register are and if such conventions even > > exist (I would be thankful for any pointer here). As Tom commented, > > the code generated by the JIT is aware of this behaviour but other > > C/library/JNI code may not. > > > > > > IIRC, the ABI specification for x64 allows the x87 control word to *not* be > saved/restored across context switches in 64-bit mode depending on the OS. > Again IIRC, the Unix ABI for x64 *does* preserve the x87 control word in > these cases but the Windows ABI does not. > Hi Joe, I don't understand what do you mean by context switch - do you mean function call? My experiments show that on Windows, the control word is indeed not preserved across function calls. If I call "fmod()" a second time in the example from my previous mail, the second call returns the correct result because the first call cleared the "Zero Divide" flag in the control word. The question is only, if fmod() should be dependant on the control word at all or if it should not better clear it right after the invocation? By the way, I've checked my example with MSCV 2008 now and it fails as well. This means that if you're going to switch to MSVC 2008 (as discussed on the lists recently), you'll face this problem as well. I've fixed it, by introducing a new stub routine "clear_fp_exceptions()" in "stubRoutines_amd64.{cpp,hpp}" which simply executes WAIT and FNCLEX to clear the pending floating point exceptions. This stub is called in "sharedruntime.cpp" in SharedRuntime::drem() just before the call to ::fmod() if on Windows. If youre interested, I can post the patch to the list. Regards, Volker > -Joe > > > > > Regards, > > Volker > > > > On 8/27/08, David Holmes - Sun Microsystems wrote: > > > > > > > Hi Volker, > > > > > > I don't know if this is related, or just coincidental timing but a new > bug > > > report has just been filed: > > > > > > 6741940 Nonvolatile XMM registers not preserved across JNI calls > > > > > > "Calls to the JNI entry point "CallVoidMethod" [in test program] do not > > > preserve the nonvolatile XMM registers, unless running with -Xint. This > is > > > in violation of the Windows 64-bit ABI: > > > http://msdn.microsoft.com/en-us/library/ms794547.aspx" > > > > > > This won't show up on BugParade for a day or so. > > > > > > Regards, > > > David Holmes > > > > > > Volker Simonis said the following on 08/26/08 05:19: > > > > > > > > > > > > > > > > Hi, > > > > > > > > we had a strange problem wich lead to failures in the JCK test > > > > Math2012. The problem only occured if some other JCK-Tests where > > > > compiled and execuetd in a special order before the tests in > > > > Math2012. > > > > > > > > I could finally track down the problem to the following simple test > case: > > > > > > > > ==================================================== > > > > public class Log10 { > > > > > > > > public static double log10(double d) { > > > > return Math.log10(d); > > > > } > > > > > > > > public static double drem2(double d) { > > > > return d % 2; > > > > } > > > > > > > > public static void main(String args[]) { > > > > System.out.println("log10(0) = " + Math.log10(0.0d)); > > > > System.out.println("log10(0) = " + log10(0.0d)); > > > > System.out.println("drem2(4.0) = " + drem2(4.0d)); > > > > } > > > > } > > > > ==================================================== > > > > > > > > which always fails on Windows/x86_64 (i.e. prints "NaN" for the result > > > > of 4.0 % 2.0 which should be 0.0) if executed like this: > > > > > > > > java -Xcomp -Xbatch -XX:CompileCommand="compileonly > Log10 > > > > > > > > > > > log10" > > > > > > > > > > -XX:+PrintCompilation Log10 > > > > > > > > VM option 'CompileCommand=compileonly Log10 log10' > > > > VM option '+PrintCompilation' > > > > CompilerOracle: compileonly Log10.log10 > > > > log10(0) = -Infinity > > > > 1 b Log10::log10 (5 bytes) > > > > log10(0) = -Infinity > > > > drem2(4.0) = NaN > > > > > > > > Notice however that we are using a version of the Java 6 HotSpot > > > > compiled with Visual Studio 2005. > > > > > > > > I couldn't reproduce the problem with > > > > jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 > however I > > > > > > > > > > > could verify > > > > > > > > > > that the code generated by both, our JDK 6 and the latest jdk-7 is > > > > virtually the same. The interesting part is the compiled version of > > > > the method Log10.log10(): > > > > > > > > 000 pushq rbp > > > > subq rsp, #16 # Create frame > > > > nop # nop for patch_verified_entry > > > > 006 fldlg2 #Log10 > > > > fyl2x # Q=Log10*Log_2(x) > > > > 024 addq rsp, 16 # Destroy frame > > > > popq rbp > > > > testl rax, [rip + #offset_to_poll_page] # Safepoint: > poll > > > > > > > > > > > for GC > > > > > > > > > > 02f ret > > > > > > > > The computation of Math.log10(0.0d) which correctly returns -Infinity > > > > sets the "Zero Divide" flag in the FP status word as described in > > > > > > > > > > > > > > > > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf. > > > > > > > > > > After this computation "SharedRuntime::drem()" is called for the > > > > computation of the double reminder in the method "drem2()" of the > > > > above example. "SharedRuntime::drem()" itself just delegates the > > > > computation to the "fmod()" function (defined in ) of the > > > > underlying platform. > > > > > > > > The presence of the "Zero Divide" flag in the FP status word seems to > > > > be no problem for the "fmod()" which is used by the > > > > jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 > executable > > > > > > > > > > > (from > > > > > > > > > > msvcr71.dll) and it is no problem on Linux/x86_64 either, but it IS > > > > definitely a problem for the "fmod()" from the "msvcr80d.dll" which is > > > > used in our MSVC 2005 build. > > > > > > > > I have two questions now: > > > > > > > > 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions > > > > bits as they are in the FP status word? > > > > 2. Can somebody confirm that the described behaviour of "fmod()" from > > > > "msvcr80d.dll" as used by MSVC 2005 is buggy? (I couldn't find any bug > > > > report and I also couldn't find reference if "fmod() should depend on > > > > the FP status word or not.) > > > > > > > > It would also be nice if somebody who has recent OpenJDK built with > > > > MSVC 2005 could confirm the above problem or if somebody could just > > > > confirm or disprove the "fmod()" problem within different versions of > > > > MSVC. Here's a small C-program which can be used to test if "fmod()" > > > > is dependent on the FP status word: > > > > > > > > ====================== fmod.c ==================== > > > > #include > > > > #include > > > > > > > > extern void fpu_asm(); > > > > > > > > int main(int argc, char* argv[]) { > > > > > > > > double d = 0.0; > > > > > > > > printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); > > > > > > > > fpu_asm(); > > > > > > > > printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); > > > > > > > > } > > > > ===================================================== > > > > > > > > ===================== fpu_asm.asm ==================== > > > > PUBLIC fpu_asm > > > > .CODE > > > > ALIGN 8 > > > > fpu_asm PROC > > > > fldlg2 > > > > fldz > > > > fyl2x > > > > ret > > > > ALIGN 8 > > > > fpu_asm ENDP > > > > END > > > > > ====================================================== > > > > > > > > Compile and run with: > > > > > > > > ml64 /c fpu_asm.asm > > > > cl fmod.c fpu_asm.obj > > > > fmod.exe > > > > fmod(4.0, 2.0) = 0.000000 > > > > fmod(4.0, 2.0) = -1.#IND00 > > > > > > > > Regards, > > > > Volker > > > > > > > > PS: the obvious solution of calling "_clearfp()" as defined in > > > > just before a call to "fmod()" unfortunately doesn't work, > > > > because "_clearfp()" (at least in MSVC 2005) only cleans the SSE > > > > status register MXCSR. The only solution I see right now is using the > > > > FCLEX assembler instruction, and because MSVC 2005 has no inline > > > > assembler for x86_64 I'll probably have to write the whole assembler > > > > function for the assembler instruction. Or does somebody have a > > > > smarter solution? > > > > > > > > PPS: this is a nice example, how a compiler switch can get you a lot > > > > of fun (isn't it Kelly:) ... > > > > > > > > > > > > > > > > > > > From Joe.Darcy at Sun.COM Tue Sep 16 12:16:11 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 16 Sep 2008 12:16:11 -0700 Subject: Problems with double reminder on Windows/x86_64 and Visual Studio 2005 In-Reply-To: References: <48B542EA.7040201@sun.com> <48CF2076.5060309@sun.com> Message-ID: <48D005FB.8010104@sun.com> Volker Simonis wrote: > On 9/16/08, Joseph D. Darcy wrote: > >> Volker Simonis wrote: >> >> >>> Hi David, >>> >>> I don't think that the problems are related although they are similar. >>> In my case the problem is caused by the FPSW (on Windows, on Linux in >>> gdb it's "fstat") register which is the status word for the FPU >>> (formerly known as x87 and later as MMX) registers. >>> >>> The problem is that MSVC apperently doesn't support these registers >>> any more in the sense that it doesn't generate code which uses them. >>> This is probably also the reason why there "_clearfp()" function does >>> not clear FPSW register but only the more modern MXCSR register (which >>> is the status register for the XMM register set (also known as >>> SSE2/SSE3)). >>> >>> On the other hand, Microsoft is STILL using the old FPU registers in >>> their runtime functions (particularly in the "fmod()" function). And >>> this usage interfers with the usage of the old FPU registers by the >>> code generated from the HotSpot JIT compiler. I have no idea how the >>> ABI convention for the FPSW register are and if such conventions even >>> exist (I would be thankful for any pointer here). As Tom commented, >>> the code generated by the JIT is aware of this behaviour but other >>> C/library/JNI code may not. >>> >>> >>> >> IIRC, the ABI specification for x64 allows the x87 control word to *not* be >> saved/restored across context switches in 64-bit mode depending on the OS. >> Again IIRC, the Unix ABI for x64 *does* preserve the x87 control word in >> these cases but the Windows ABI does not. >> >> > > Hi Joe, > > I don't understand what do you mean by context switch - do you mean > function call? > I was thinking of OS context switches between processes, but it is certainly also possible that the function call register conventions changed too in the 64-bit ABI. -Joe > My experiments show that on Windows, the control word is indeed not > preserved across function calls. If I call "fmod()" a second time in > the example from my previous mail, the second call returns the correct > result because the first call cleared the "Zero Divide" flag in the > control word. > > The question is only, if fmod() should be dependant on the control > word at all or if it should not better clear it right after the > invocation? > > By the way, I've checked my example with MSCV 2008 now and it fails as > well. This means that if you're going to switch to MSVC 2008 (as > discussed on the lists recently), you'll face this problem as well. > I've fixed it, by introducing a new stub routine > "clear_fp_exceptions()" in "stubRoutines_amd64.{cpp,hpp}" which > simply executes WAIT and FNCLEX to clear the pending floating point > exceptions. This stub is called in "sharedruntime.cpp" in > SharedRuntime::drem() just before the call to ::fmod() if on Windows. > If youre interested, I can post the patch to the list. > > Regards, > Volker > > > >> -Joe >> >> >> >> >>> Regards, >>> Volker >>> >>> On 8/27/08, David Holmes - Sun Microsystems wrote: >>> >>> >>> >>>> Hi Volker, >>>> >>>> I don't know if this is related, or just coincidental timing but a new >>>> >> bug >> >>>> report has just been filed: >>>> >>>> 6741940 Nonvolatile XMM registers not preserved across JNI calls >>>> >>>> "Calls to the JNI entry point "CallVoidMethod" [in test program] do not >>>> preserve the nonvolatile XMM registers, unless running with -Xint. This >>>> >> is >> >>>> in violation of the Windows 64-bit ABI: >>>> http://msdn.microsoft.com/en-us/library/ms794547.aspx" >>>> >>>> This won't show up on BugParade for a day or so. >>>> >>>> Regards, >>>> David Holmes >>>> >>>> Volker Simonis said the following on 08/26/08 05:19: >>>> >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> we had a strange problem wich lead to failures in the JCK test >>>>> Math2012. The problem only occured if some other JCK-Tests where >>>>> compiled and execuetd in a special order before the tests in >>>>> Math2012. >>>>> >>>>> I could finally track down the problem to the following simple test >>>>> >> case: >> >>>>> ==================================================== >>>>> public class Log10 { >>>>> >>>>> public static double log10(double d) { >>>>> return Math.log10(d); >>>>> } >>>>> >>>>> public static double drem2(double d) { >>>>> return d % 2; >>>>> } >>>>> >>>>> public static void main(String args[]) { >>>>> System.out.println("log10(0) = " + Math.log10(0.0d)); >>>>> System.out.println("log10(0) = " + log10(0.0d)); >>>>> System.out.println("drem2(4.0) = " + drem2(4.0d)); >>>>> } >>>>> } >>>>> ==================================================== >>>>> >>>>> which always fails on Windows/x86_64 (i.e. prints "NaN" for the result >>>>> of 4.0 % 2.0 which should be 0.0) if executed like this: >>>>> >>>>> java -Xcomp -Xbatch -XX:CompileCommand="compileonly >>>>> >> Log10 >> >>>>> >>>> log10" >>>> >>>> >>>> >>>>> -XX:+PrintCompilation Log10 >>>>> >>>>> VM option 'CompileCommand=compileonly Log10 log10' >>>>> VM option '+PrintCompilation' >>>>> CompilerOracle: compileonly Log10.log10 >>>>> log10(0) = -Infinity >>>>> 1 b Log10::log10 (5 bytes) >>>>> log10(0) = -Infinity >>>>> drem2(4.0) = NaN >>>>> >>>>> Notice however that we are using a version of the Java 6 HotSpot >>>>> compiled with Visual Studio 2005. >>>>> >>>>> I couldn't reproduce the problem with >>>>> jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 >>>>> >> however I >> >>>>> >>>> could verify >>>> >>>> >>>> >>>>> that the code generated by both, our JDK 6 and the latest jdk-7 is >>>>> virtually the same. The interesting part is the compiled version of >>>>> the method Log10.log10(): >>>>> >>>>> 000 pushq rbp >>>>> subq rsp, #16 # Create frame >>>>> nop # nop for patch_verified_entry >>>>> 006 fldlg2 #Log10 >>>>> fyl2x # Q=Log10*Log_2(x) >>>>> 024 addq rsp, 16 # Destroy frame >>>>> popq rbp >>>>> testl rax, [rip + #offset_to_poll_page] # Safepoint: >>>>> >> poll >> >>>>> >>>> for GC >>>> >>>> >>>> >>>>> 02f ret >>>>> >>>>> The computation of Math.log10(0.0d) which correctly returns -Infinity >>>>> sets the "Zero Divide" flag in the FP status word as described in >>>>> >>>>> >>>>> >>>>> >> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26569.pdf. >> >>>> >>>>> After this computation "SharedRuntime::drem()" is called for the >>>>> computation of the double reminder in the method "drem2()" of the >>>>> above example. "SharedRuntime::drem()" itself just delegates the >>>>> computation to the "fmod()" function (defined in ) of the >>>>> underlying platform. >>>>> >>>>> The presence of the "Zero Divide" flag in the FP status word seems to >>>>> be no problem for the "fmod()" which is used by the >>>>> jdk-7-ea-bin-b32-windows-x64-debug-04_aug_2008 >>>>> >> executable >> >>>>> >>>> (from >>>> >>>> >>>> >>>>> msvcr71.dll) and it is no problem on Linux/x86_64 either, but it IS >>>>> definitely a problem for the "fmod()" from the "msvcr80d.dll" which is >>>>> used in our MSVC 2005 build. >>>>> >>>>> I have two questions now: >>>>> >>>>> 1. Is it ok that the intrinsic for Math.log10() leaves the exceptions >>>>> bits as they are in the FP status word? >>>>> 2. Can somebody confirm that the described behaviour of "fmod()" from >>>>> "msvcr80d.dll" as used by MSVC 2005 is buggy? (I couldn't find any bug >>>>> report and I also couldn't find reference if "fmod() should depend on >>>>> the FP status word or not.) >>>>> >>>>> It would also be nice if somebody who has recent OpenJDK built with >>>>> MSVC 2005 could confirm the above problem or if somebody could just >>>>> confirm or disprove the "fmod()" problem within different versions of >>>>> MSVC. Here's a small C-program which can be used to test if "fmod()" >>>>> is dependent on the FP status word: >>>>> >>>>> ====================== fmod.c ==================== >>>>> #include >>>>> #include >>>>> >>>>> extern void fpu_asm(); >>>>> >>>>> int main(int argc, char* argv[]) { >>>>> >>>>> double d = 0.0; >>>>> >>>>> printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); >>>>> >>>>> fpu_asm(); >>>>> >>>>> printf("fmod(4.0, 2.0) = %f\n", fmod(4.0, 2.0)); >>>>> >>>>> } >>>>> ===================================================== >>>>> >>>>> ===================== fpu_asm.asm ==================== >>>>> PUBLIC fpu_asm >>>>> .CODE >>>>> ALIGN 8 >>>>> fpu_asm PROC >>>>> fldlg2 >>>>> fldz >>>>> fyl2x >>>>> ret >>>>> ALIGN 8 >>>>> fpu_asm ENDP >>>>> END >>>>> >>>>> >> ====================================================== >> >>>>> Compile and run with: >>>>> >>>>> ml64 /c fpu_asm.asm >>>>> cl fmod.c fpu_asm.obj >>>>> fmod.exe >>>>> fmod(4.0, 2.0) = 0.000000 >>>>> fmod(4.0, 2.0) = -1.#IND00 >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> PS: the obvious solution of calling "_clearfp()" as defined in >>>>> just before a call to "fmod()" unfortunately doesn't work, >>>>> because "_clearfp()" (at least in MSVC 2005) only cleans the SSE >>>>> status register MXCSR. The only solution I see right now is using the >>>>> FCLEX assembler instruction, and because MSVC 2005 has no inline >>>>> assembler for x86_64 I'll probably have to write the whole assembler >>>>> function for the assembler instruction. Or does somebody have a >>>>> smarter solution? >>>>> >>>>> PPS: this is a nice example, how a compiler switch can get you a lot >>>>> of fun (isn't it Kelly:) ... >>>>> >>>>> >>>>> >>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20080916/2298d505/attachment.html From chuck.rasbold at sun.com Tue Sep 16 13:06:57 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Tue, 16 Sep 2008 20:06:57 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20080916200707.6C556DD1E@hg.openjdk.java.net> Changeset: 1c6e3bfb543a Author: kvn Date: 2008-09-10 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1c6e3bfb543a 6746892: Register Allocator does not process a data phi with one unique input correctly Summary: Always look for the existing phi for a processed live_range. Reviewed-by: rasbold ! src/share/vm/opto/reg_split.cpp Changeset: cecd8eb4e0ca Author: kvn Date: 2008-09-10 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cecd8eb4e0ca 6706829: Compressed Oops: add debug info for narrow oops Summary: Add support for narrow oops in debug info to avoid decoding. Reviewed-by: rasbold, never ! agent/src/share/classes/sun/jvm/hotspot/code/Location.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/code/location.cpp ! src/share/vm/code/location.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c792b641b8bd Author: kvn Date: 2008-09-10 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c792b641b8bd 6746907: Improve implicit null check generation Summary: add missing implicit null check cases. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp Changeset: 7484fa4b8825 Author: rasbold Date: 2008-09-15 09:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7484fa4b8825 Merge ! src/share/vm/opto/compile.cpp From yamauchi at google.com Wed Sep 17 16:50:41 2008 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 17 Sep 2008 16:50:41 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <48CAB6DE.8070806@sun.com> References: <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> Message-ID: Hi, Any comment about the patch itself? On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy wrote: > Joseph D. Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> 2008/9/11 Andrew John Hughes : >>>> >>>> 2008/9/11 Daniel D. Daugherty : >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>>> not that strange. >>>>> >>>>> JDK7-B24 has the following values: >>>>> >>>>> HS_MAJOR_VER=12 >>>>> HS_MINOR_VER=0 >>>>> HS_BUILD_NUMBER=01 >>>>> >>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>> I see: >>>>> >>>>> HS_MAJOR_VER=10 >>>>> HS_MINOR_VER=0 >>>>> HS_BUILD_NUMBER=23 >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>> Hmmm... >>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >>>> is not based on the same as this 1.6.0_07 thing you mention. >>>> I'll try and have a closer look later. >>>> -- >>>> Andrew :-) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>> >>> >>> IcedTea6 contains: >>> >>> HS_MAJOR_VER=10 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=19 >>> >>> IcedTea/b33 contains: >>> >>> HS_MAJOR_VER=14 >>> HS_MINOR_VER=0 >>> HS_BUILD_NUMBER=01 >>> >>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>> make/hotspot_version >>> so it's actually worryingly building a different version of HotSpot >>> from the one it thinks it is. >>> It will actually be 12-0-01 as you state, but will report 10-0-19. >>> >>> Overall, it would be better to always build against the most recent >>> stable HotSpot tree if possible >>> rather than the one provided by the build drop. Do we know what the >>> most stable would be? >> >> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. The >> policy I've implemented, >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, >> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases, >> augmented with some other fixes for license corrections, gcc build issues, >> (and the occasional Eclipse crash). The HotSpot in the base OpenJDK 6 code >> base is very close to the HotSpot in the currently shipping 6 update >> release. > > ... and going forward we will have much closer coordination between the > OpenJDK 6 and 6 update HotSpots since we'll be using the same source for > both; so the version information should be updated consistently, etc. > > http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html > > -Joe > From erik.trimble at sun.com Wed Sep 17 22:15:47 2008 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 18 Sep 2008 05:15:47 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20080918051556.46F31DE9B@hg.openjdk.java.net> Changeset: 51798f0e554f Author: xdono Date: 2008-09-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/51798f0e554f Added tag jdk7-b35 for changeset 5fa96a5a7e76 ! .hgtags Changeset: 75e0a5b79b1f Author: trims Date: 2008-09-17 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/75e0a5b79b1f Merge Changeset: e91159f921a5 Author: trims Date: 2008-09-17 18:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e91159f921a5 6749707: Update build number for HS14 B05 Summary: Bump the build number for hs14 b05 Reviewed-by: jcoomes ! make/hotspot_version From Thomas.Rodriguez at Sun.COM Wed Sep 24 12:08:26 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 24 Sep 2008 12:08:26 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: References: <48C84E8B.6030001@sun.com> <1221088194.26700.18.camel@hermans.wildebeest.org> <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> Message-ID: <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> As far as I can tell this looks like a faithful backport of the changes to hs10, which is good. The obvious complexity of the comparing the results is that hs10 which is what is currently in openjdk6 still have separate amd64 and i486 directory whereas hs11 and later have a merged x86 directory. I believe OpenJDK 6 is planning to move to hs11 which should make applying the original patch unchanged a little more straightforward. The original changes were motivated by a lot of direct testing of the VM under collector. Have you done any testing of these changes? tom On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote: > Hi, Any comment about the patch itself? > > On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy > wrote: >> Joseph D. Darcy wrote: >>> >>> Andrew John Hughes wrote: >>>> >>>> 2008/9/11 Andrew John Hughes : >>>>> >>>>> 2008/9/11 Daniel D. Daugherty : >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>>> Given OpenJDK6 was derived from something like b20, I guess >>>>>> this is >>>>>> not that strange. >>>>>> >>>>>> JDK7-B24 has the following values: >>>>>> >>>>>> HS_MAJOR_VER=12 >>>>>> HS_MINOR_VER=0 >>>>>> HS_BUILD_NUMBER=01 >>>>>> >>>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>>> I see: >>>>>> >>>>>> HS_MAJOR_VER=10 >>>>>> HS_MINOR_VER=0 >>>>>> HS_BUILD_NUMBER=23 >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>> Hmmm... >>>>> Then either Gary's HotSpot patch doesn't update that file or >>>>> OpenJDK6 >>>>> is not based on the same as this 1.6.0_07 thing you mention. >>>>> I'll try and have a closer look later. >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>> >>>> IcedTea6 contains: >>>> >>>> HS_MAJOR_VER=10 >>>> HS_MINOR_VER=0 >>>> HS_BUILD_NUMBER=19 >>>> >>>> IcedTea/b33 contains: >>>> >>>> HS_MAJOR_VER=14 >>>> HS_MINOR_VER=0 >>>> HS_BUILD_NUMBER=01 >>>> >>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>>> make/hotspot_version >>>> so it's actually worryingly building a different version of HotSpot >>>> from the one it thinks it is. >>>> It will actually be 12-0-01 as you state, but will report 10-0-19. >>>> >>>> Overall, it would be better to always build against the most recent >>>> stable HotSpot tree if possible >>>> rather than the one provided by the build drop. Do we know what >>>> the >>>> most stable would be? >>> >>> Generally, the HotSpot in the base OpenJDK 6 should be pretty >>> stable. The >>> policy I've implemented, >>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html >>> , >>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update >>> releases, >>> augmented with some other fixes for license corrections, gcc build >>> issues, >>> (and the occasional Eclipse crash). The HotSpot in the base >>> OpenJDK 6 code >>> base is very close to the HotSpot in the currently shipping 6 update >>> release. >> >> ... and going forward we will have much closer coordination between >> the >> OpenJDK 6 and 6 update HotSpots since we'll be using the same >> source for >> both; so the version information should be updated consistently, etc. >> >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html >> >> -Joe >> From Thomas.Rodriguez at Sun.COM Wed Sep 24 12:31:35 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 24 Sep 2008 12:31:35 -0700 Subject: review (XS) for 6744783 Message-ID: http://webrev.invokedynamic.info/never/6744783 From andrey.petrusenko at sun.com Wed Sep 24 14:53:49 2008 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Wed, 24 Sep 2008 21:53:49 +0000 Subject: hg: jdk7/hotspot/hotspot: 26 new changesets Message-ID: <20080924215439.CB809D1E2@hg.openjdk.java.net> Changeset: ebeb6490b814 Author: ysr Date: 2008-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ebeb6490b814 6722116: CMS: Incorrect overflow handling when using parallel concurrent marking Summary: Fixed CMSConcMarkingTask::reset() to store the restart address upon a marking stack overflow and to use it as the base, suitably aligned, for restarting the scan in CMSConcMarkingTask::do_scan_and_mark(). Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: d60e4e6d7f72 Author: ysr Date: 2008-08-27 10:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d60e4e6d7f72 Merge Changeset: 37f87013dfd8 Author: ysr Date: 2008-06-05 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/37f87013dfd8 6711316: Open source the Garbage-First garbage collector Summary: First mercurial integration of the code for the Garbage-First garbage collector. Reviewed-by: apetrusenko, iveresov, jmasa, sgoldman, tonyp, ysr ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/makedeps.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86_32.cpp ! src/cpu/x86/vm/assembler_x86_32.hpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/compiler/methodLiveness.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp + src/share/vm/gc_implementation/g1/collectionSetChooser.cpp + src/share/vm/gc_implementation/g1/collectionSetChooser.hpp + src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp + src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp + src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp + src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp + src/share/vm/gc_implementation/g1/concurrentMark.cpp + src/share/vm/gc_implementation/g1/concurrentMark.hpp + src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp + src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp + src/share/vm/gc_implementation/g1/concurrentMarkThread.inline.hpp + src/share/vm/gc_implementation/g1/concurrentZFThread.cpp + src/share/vm/gc_implementation/g1/concurrentZFThread.hpp + src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp + src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp + src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp + src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp + src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp + src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp + src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp + src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp + src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1MMUTracker.cpp + src/share/vm/gc_implementation/g1/g1MMUTracker.hpp + src/share/vm/gc_implementation/g1/g1MarkSweep.cpp + src/share/vm/gc_implementation/g1/g1MarkSweep.hpp + src/share/vm/gc_implementation/g1/g1OopClosures.hpp + src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp + src/share/vm/gc_implementation/g1/g1RemSet.cpp + src/share/vm/gc_implementation/g1/g1RemSet.hpp + src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp + src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp + src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp + src/share/vm/gc_implementation/g1/g1_globals.cpp + src/share/vm/gc_implementation/g1/g1_globals.hpp + src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp + src/share/vm/gc_implementation/g1/heapRegion.cpp + src/share/vm/gc_implementation/g1/heapRegion.hpp + src/share/vm/gc_implementation/g1/heapRegion.inline.hpp + src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp + src/share/vm/gc_implementation/g1/heapRegionSeq.cpp + src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp + src/share/vm/gc_implementation/g1/ptrQueue.cpp + src/share/vm/gc_implementation/g1/ptrQueue.hpp + src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp + src/share/vm/gc_implementation/g1/satbQueue.cpp + src/share/vm/gc_implementation/g1/satbQueue.hpp + src/share/vm/gc_implementation/g1/sparsePRT.cpp + src/share/vm/gc_implementation/g1/sparsePRT.hpp + src/share/vm/gc_implementation/g1/survRateGroup.cpp + src/share/vm/gc_implementation/g1/survRateGroup.hpp + src/share/vm/gc_implementation/g1/vm_operations_g1.cpp + src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep + src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp + src/share/vm/gc_implementation/shared/coTracker.cpp + src/share/vm/gc_implementation/shared/coTracker.hpp + src/share/vm/gc_implementation/shared/concurrentGCThread.cpp + src/share/vm/gc_implementation/shared/concurrentGCThread.hpp + src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp + src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/includeDB_jvmti ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/allocation.hpp + src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.hpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/markOop.inline.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/debug.cpp + src/share/vm/utilities/intHisto.cpp + src/share/vm/utilities/intHisto.hpp + src/share/vm/utilities/numberSeq.cpp + src/share/vm/utilities/numberSeq.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: afc1ce1efe66 Author: iveresov Date: 2008-06-11 05:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/afc1ce1efe66 6710665: G1: guarantee(_cm->out_of_regions() && _cm->region_stack_empty() && _task_queue->size() == 0, ...) Summary: Remove the incorrect assumptions from guarantee()s. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 6aae2f9d0294 Author: ysr Date: 2008-06-12 13:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6aae2f9d0294 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86_32.hpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/space.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 33e001c095fe Author: ysr Date: 2008-06-12 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/33e001c095fe Merge Changeset: bb254e57d2f4 Author: ysr Date: 2008-06-17 08:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bb254e57d2f4 Merge ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: 60fb9c4db4e6 Author: ysr Date: 2008-06-23 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/60fb9c4db4e6 6718086: CMS assert: _concurrent_iteration_safe_limit update missed Summary: Initialize the field correctly in ContiguousSpace's constructor and initialize() methods, using the latter for the survivor spaces upon initial construction or a subsequent resizing of the young generation. Add some missing Space sub-class constructors. Reviewed-by: apetrusenko ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp Changeset: 69fefd031e6c Author: ysr Date: 2008-06-24 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/69fefd031e6c Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 73278b62f36c Author: ysr Date: 2008-06-26 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/73278b62f36c 6718811: Mismerge of 6680469:macro.cpp Summary: Fixed the mismerge by deleting the lines that were inadvertently left in place. Reviewed-by: iveresov ! src/share/vm/opto/macro.cpp Changeset: d28aa69f0959 Author: ysr Date: 2008-06-30 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d28aa69f0959 6618726: Introduce -XX:+UnlockExperimentalVMOptions flag Summary: experimental() flags will protect features of an experimental nature that are not supported in the regular product build. Made UseG1GC an experimental flag. Reviewed-by: jmasa, kamg, coleenp ! src/share/vm/gc_implementation/g1/g1_globals.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/services/management.cpp Changeset: fab5f738c515 Author: ysr Date: 2008-07-01 11:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fab5f738c515 Merge ! src/share/vm/adlc/formssel.cpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/macro.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: e0c09f7ec5c4 Author: iveresov Date: 2008-07-03 03:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e0c09f7ec5c4 6702387: G1: assertion failure: assert(p == current_top || oop(p)->is_oop(),"p is not a block start") Summary: Do not coalesce dead and moved objects when removing self-forwarding pointers during the evacuation failure. Also fixed a issue in a BOT refinement code for TLABs. Reviewed-by: tonyp, jcoomes ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9bb2c10ac07b Author: iveresov Date: 2008-07-10 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9bb2c10ac07b 6723570: G1: assertion failure: p == current_top or oop(p)->is_oop(),"p is not a block start" (revisited!) Summary: Fixed the incorrect assigment to G1OffsetTableContigSpace::_gc_time_stamp. Also added a little more paranoia to operations on a global timestamp. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: c0f8f7790199 Author: iveresov Date: 2008-07-30 10:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c0f8f7790199 6652160: G1: assert(cur_used_bytes == _g1->recalculate_used(),"It should!") at g1CollectorPolicy.cpp:1425 Summary: In attempt_allocation_slow() wait for the concurrent cleanup to complete before modifying _summary_bytes_used. Reviewed-by: jmasa, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0edda524b58c Author: tonyp Date: 2008-08-06 11:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0edda524b58c 6722565: G1: assert !r->is_on_unclean_list() fires Summary: Under certain circumstances, two cleanup threads can claim and process the same region. Reviewed-by: apetrusenko, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! 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/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 1ee8caae33af Author: tonyp Date: 2008-08-21 23:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1ee8caae33af Merge - agent/src/share/lib/jlfgr-1_0.jar - agent/src/share/lib/maf-1_0.jar - make/linux/Queens.class ! make/linux/makefiles/top.make - make/solaris/Queens.class ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/makedeps.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86_32.cpp ! src/cpu/x86/vm/assembler_x86_32.hpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 2564c620fa42 Author: tonyp Date: 2008-08-21 23:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2564c620fa42 Merge ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/globals.hpp Changeset: 8651a65ac4b4 Author: iveresov Date: 2008-08-22 11:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8651a65ac4b4 6735416: G1: runThese javasoft.sqe.tests.lang.thrd011.thrd01101.thrd01101 fails 6622418: G1: assert(false,"Non-balanced monitor enter/exit!") fails Summary: The mark-sweep compact (which we use for full gc) wrapper did not save the mark words for biased locked objects. The fix is to trivially call the appropriate methods. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: d515536da189 Author: tonyp Date: 2008-08-26 00:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d515536da189 6740930: G1: compilation failure with latest gcc Summary: Include DB fix to resolve a compilation issue with the latest gcc. Reviewed-by: iveresov, ysr ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 5d254928c888 Author: ysr Date: 2008-08-27 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5d254928c888 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/runtime/thread.cpp Changeset: a4f9ef0c0375 Author: jmasa Date: 2008-09-04 14:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a4f9ef0c0375 6743059: Error in spaceDecorator.cpp "optimized" build. Summary: Changed the guard on the definition of the method value in HeapWord from ASSERT to not PRODUCT. Reviewed-by: iveresov, apetrusenko ! src/share/vm/utilities/globalDefinitions.hpp Changeset: f8199438385b Author: apetrusenko Date: 2008-09-17 16:49 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f8199438385b Merge ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/opto/macro.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 032ddb9432ad Author: apetrusenko Date: 2008-09-17 19:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/032ddb9432ad Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 919e7959392a Author: tonyp Date: 2008-09-22 09:56 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/919e7959392a 6742641: G1: NullPointerException during GCOld Summary: An update buffer is not processed correctly, which causes roots into the collection set not to be scanned and, hence, for the heap to be corrupted. The cause is that an object is accessed after it has been explicitly deleted, which causes a race. Reviewed-by: jcoomes, ysr ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp Changeset: 5f44674206d3 Author: apetrusenko Date: 2008-09-24 15:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5f44674206d3 Merge ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/runtime/vmStructs.cpp From yamauchi at google.com Thu Sep 25 11:32:29 2008 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Thu, 25 Sep 2008 11:32:29 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> References: <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> Message-ID: On Wed, Sep 24, 2008 at 12:08 PM, Tom Rodriguez wrote: > As far as I can tell this looks like a faithful backport of the changes to > hs10, which is good. The obvious complexity of the comparing the results is > that hs10 which is what is currently in openjdk6 still have separate amd64 > and i486 directory whereas hs11 and later have a merged x86 directory. I > believe OpenJDK 6 is planning to move to hs11 which should make applying the > original patch unchanged a little more straightforward. Right. > The original > changes were motivated by a lot of direct testing of the VM under collector. > Have you done any testing of these changes? I'm not sure what you mean by collector. But as far as I can tell AsyncGetCallTrace is a lot more stable and shows more stack frames with the patch. If Sun folks have tests for it, it'd be great if someone can run them against this patch. Thanks, Hiroshi > On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote: > >> Hi, Any comment about the patch itself? >> >> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy >> wrote: >>> >>> Joseph D. Darcy wrote: >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> 2008/9/11 Andrew John Hughes : >>>>>> >>>>>> 2008/9/11 Daniel D. Daugherty : >>>>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>>>>> not that strange. >>>>>>> >>>>>>> JDK7-B24 has the following values: >>>>>>> >>>>>>> HS_MAJOR_VER=12 >>>>>>> HS_MINOR_VER=0 >>>>>>> HS_BUILD_NUMBER=01 >>>>>>> >>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>>>> I see: >>>>>>> >>>>>>> HS_MAJOR_VER=10 >>>>>>> HS_MINOR_VER=0 >>>>>>> HS_BUILD_NUMBER=23 >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>> Hmmm... >>>>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6 >>>>>> is not based on the same as this 1.6.0_07 thing you mention. >>>>>> I'll try and have a closer look later. >>>>>> -- >>>>>> Andrew :-) >>>>>> >>>>>> Support Free Java! >>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>> http://www.gnu.org/software/classpath >>>>>> http://openjdk.java.net >>>>>> >>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>> >>>>> >>>>> IcedTea6 contains: >>>>> >>>>> HS_MAJOR_VER=10 >>>>> HS_MINOR_VER=0 >>>>> HS_BUILD_NUMBER=19 >>>>> >>>>> IcedTea/b33 contains: >>>>> >>>>> HS_MAJOR_VER=14 >>>>> HS_MINOR_VER=0 >>>>> HS_BUILD_NUMBER=01 >>>>> >>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>>>> make/hotspot_version >>>>> so it's actually worryingly building a different version of HotSpot >>>>> from the one it thinks it is. >>>>> It will actually be 12-0-01 as you state, but will report 10-0-19. >>>>> >>>>> Overall, it would be better to always build against the most recent >>>>> stable HotSpot tree if possible >>>>> rather than the one provided by the build drop. Do we know what the >>>>> most stable would be? >>>> >>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. >>>> The >>>> policy I've implemented, >>>> >>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, >>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases, >>>> augmented with some other fixes for license corrections, gcc build >>>> issues, >>>> (and the occasional Eclipse crash). The HotSpot in the base OpenJDK 6 >>>> code >>>> base is very close to the HotSpot in the currently shipping 6 update >>>> release. >>> >>> ... and going forward we will have much closer coordination between the >>> OpenJDK 6 and 6 update HotSpots since we'll be using the same source for >>> both; so the version information should be updated consistently, etc. >>> >>> >>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html >>> >>> -Joe >>> > > From Thomas.Rodriguez at Sun.COM Thu Sep 25 12:29:26 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 25 Sep 2008 12:29:26 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: References: <48C868CC.4050303@sun.com> <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com> <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> Message-ID: <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM> > I'm not sure what you mean by collector. But as far as I can tell > AsyncGetCallTrace > is a lot more stable and shows more stack frames with the patch. If > Sun folks > have tests for it, it'd be great if someone can run them against > this patch. I was only referring to testing it with a profiling tool and the SunStudio collector is the only one I know of that uses AsyncGetCallTrace. When you say "a lot more stable" do you mean it doesn't crash or it crashes less? tom > > Thanks, > Hiroshi > > >> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote: >> >>> Hi, Any comment about the patch itself? >>> >>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy >>> >>> wrote: >>>> >>>> Joseph D. Darcy wrote: >>>>> >>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2008/9/11 Andrew John Hughes : >>>>>>> >>>>>>> 2008/9/11 Daniel D. Daugherty : >>>>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>> >>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>>>>> Given OpenJDK6 was derived from something like b20, I guess >>>>>>>> this is >>>>>>>> not that strange. >>>>>>>> >>>>>>>> JDK7-B24 has the following values: >>>>>>>> >>>>>>>> HS_MAJOR_VER=12 >>>>>>>> HS_MINOR_VER=0 >>>>>>>> HS_BUILD_NUMBER=01 >>>>>>>> >>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>>>>> I see: >>>>>>>> >>>>>>>> HS_MAJOR_VER=10 >>>>>>>> HS_MINOR_VER=0 >>>>>>>> HS_BUILD_NUMBER=23 >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hmmm... >>>>>>> Then either Gary's HotSpot patch doesn't update that file or >>>>>>> OpenJDK6 >>>>>>> is not based on the same as this 1.6.0_07 thing you mention. >>>>>>> I'll try and have a closer look later. >>>>>>> -- >>>>>>> Andrew :-) >>>>>>> >>>>>>> Support Free Java! >>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>> http://www.gnu.org/software/classpath >>>>>>> http://openjdk.java.net >>>>>>> >>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>> >>>>>> >>>>>> IcedTea6 contains: >>>>>> >>>>>> HS_MAJOR_VER=10 >>>>>> HS_MINOR_VER=0 >>>>>> HS_BUILD_NUMBER=19 >>>>>> >>>>>> IcedTea/b33 contains: >>>>>> >>>>>> HS_MAJOR_VER=14 >>>>>> HS_MINOR_VER=0 >>>>>> HS_BUILD_NUMBER=01 >>>>>> >>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>>>>> make/hotspot_version >>>>>> so it's actually worryingly building a different version of >>>>>> HotSpot >>>>>> from the one it thinks it is. >>>>>> It will actually be 12-0-01 as you state, but will report >>>>>> 10-0-19. >>>>>> >>>>>> Overall, it would be better to always build against the most >>>>>> recent >>>>>> stable HotSpot tree if possible >>>>>> rather than the one provided by the build drop. Do we know >>>>>> what the >>>>>> most stable would be? >>>>> >>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty >>>>> stable. >>>>> The >>>>> policy I've implemented, >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html >>>>> , >>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update >>>>> releases, >>>>> augmented with some other fixes for license corrections, gcc build >>>>> issues, >>>>> (and the occasional Eclipse crash). The HotSpot in the base >>>>> OpenJDK 6 >>>>> code >>>>> base is very close to the HotSpot in the currently shipping 6 >>>>> update >>>>> release. >>>> >>>> ... and going forward we will have much closer coordination >>>> between the >>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same >>>> source for >>>> both; so the version information should be updated consistently, >>>> etc. >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html >>>> >>>> -Joe >>>> >> >> From john.coomes at sun.com Fri Sep 26 01:58:43 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Sep 2008 08:58:43 +0000 Subject: hg: jdk7/hotspot: 7 new changesets Message-ID: <20080926085844.0DFEED2F6@hg.openjdk.java.net> Changeset: 52148b82cfff Author: martin Date: 2008-09-08 17:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/52148b82cfff 6746055: Spelling error in README-builds.html Reviewed-by: ohair ! README-builds.html Changeset: f920f23af0d0 Author: tbell Date: 2008-09-12 14:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f920f23af0d0 Merge Changeset: e18ad724572f Author: ohair Date: 2008-09-09 15:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/e18ad724572f 6746424: Remove build dependency on findbugs and FINDBUGS_HOME Reviewed-by: tbell ! make/Defs-internal.gmk ! make/README.pre-components ! make/jprt.config Changeset: 2fed245641ed Author: ohair Date: 2008-09-11 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/2fed245641ed Merge Changeset: 1d9112b073d7 Author: ohair Date: 2008-09-17 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/1d9112b073d7 6724787: OpenJDK README-builds.html suggested changes 6746440: Add Fedora 9 & CentOS 5.2 instructions to OpenJDK Build README Reviewed-by: weijun, xdono ! README-builds.html Changeset: 4b4f5fea8d7d Author: xdono Date: 2008-09-17 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4b4f5fea8d7d Merge ! README-builds.html Changeset: b3eb1d558cd2 Author: xdono Date: 2008-09-25 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/b3eb1d558cd2 Added tag jdk7-b36 for changeset 4b4f5fea8d7d ! .hgtags From john.coomes at sun.com Fri Sep 26 01:59:46 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Sep 2008 08:59:46 +0000 Subject: hg: jdk7/hotspot/corba: 4 new changesets Message-ID: <20080926085950.CB481D2FB@hg.openjdk.java.net> Changeset: 0d92f2ecc8ff Author: ohair Date: 2008-09-09 15:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0d92f2ecc8ff 6746424: Remove build dependency on findbugs and FINDBUGS_HOME Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk ! make/jprt.config Changeset: 134c361ed49b Author: xdono Date: 2008-09-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/134c361ed49b Merge Changeset: 0723891eb8d1 Author: xdono Date: 2008-09-17 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/0723891eb8d1 Merge Changeset: d057050bdb27 Author: xdono Date: 2008-09-25 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/d057050bdb27 Added tag jdk7-b36 for changeset 0723891eb8d1 ! .hgtags From john.coomes at sun.com Fri Sep 26 02:02:57 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Sep 2008 09:02:57 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b36 for changeset c84ca638db42 Message-ID: <20080926090259.9559BD302@hg.openjdk.java.net> Changeset: af49591bc486 Author: xdono Date: 2008-09-25 12:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/af49591bc486 Added tag jdk7-b36 for changeset c84ca638db42 ! .hgtags From john.coomes at sun.com Fri Sep 26 02:04:03 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Sep 2008 09:04:03 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b36 for changeset f60187f44a0d Message-ID: <20080926090405.56C65D309@hg.openjdk.java.net> Changeset: a2a6f9edf761 Author: xdono Date: 2008-09-25 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/a2a6f9edf761 Added tag jdk7-b36 for changeset f60187f44a0d ! .hgtags From john.coomes at sun.com Fri Sep 26 02:07:13 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Sep 2008 09:07:13 +0000 Subject: hg: jdk7/hotspot/jdk: 53 new changesets Message-ID: <20080926091740.72980D30E@hg.openjdk.java.net> Changeset: 2a5377a6492e Author: alanb Date: 2008-08-26 09:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2a5377a6492e 6728542: (se) epoll based SelectorProvider should be portable to platforms other than x86 and x64 Reviewed-by: sherman ! make/java/nio/mapfile-linux ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c Changeset: ea45b0c72096 Author: alanb Date: 2008-08-26 10:21 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ea45b0c72096 6682020: (bf) Support monitoring of direct and mapped buffer usage Reviewed-by: mchung, iris ! make/java/java/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/nio/Bits.java + src/share/classes/java/nio/BufferPoolMXBean.java ! src/share/classes/java/nio/Direct-X-Buffer.java + src/share/classes/sun/misc/JavaNioAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java + test/java/nio/BufferPoolMXBean/Basic.java Changeset: 7afa7314d883 Author: emcmanus Date: 2008-08-27 11:03 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7afa7314d883 5041784: (reflect) generic signature methods needlessly return generic arrays Reviewed-by: darcy ! src/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java + test/java/lang/reflect/Generics/TestPlainArrayNotGeneric.java Changeset: 2c65a59dd48d Author: ksrini Date: 2008-08-26 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2c65a59dd48d 6685121: (launcher) make ReportErrorMessages accessible by other launcher subsystems Summary: provided error reporting interfaces to other java subsystems that the launcher uses. Reviewed-by: darcy ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/bin/java.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c Changeset: d6b41950987b Author: sherman Date: 2008-08-27 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d6b41950987b 4849617: (cs)Revise Charset spec to allow '+' in names Summary: Update the spec and code to accept '+' as a charset name character Reviewed-by: alanb ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/standard-charsets + test/sun/nio/cs/CheckICNE.java Changeset: 126760548921 Author: sherman Date: 2008-08-27 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/126760548921 Merge Changeset: 5d278726f0dc Author: chegar Date: 2008-08-29 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5d278726f0dc 6576763: Thread constructors throw undocumented NPE for null name Summary: update javadoc to specify NPE as well as fix minor bug in implementation. Reviewed-by: alanb ! src/share/classes/java/lang/Thread.java + test/java/lang/ThreadGroup/NullThreadName.java Changeset: dc604a6da888 Author: swamyv Date: 2008-08-29 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dc604a6da888 6614052: jhat fails to read heap dump > 2GB. Summary: Modified the jhat code to use long for unsigned int. This is a forward port of changes from Kevin Walls. Reviewed-by: jjh ! src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java Changeset: ad45ffa62646 Author: tbell Date: 2008-08-31 11:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ad45ffa62646 Merge Changeset: f9cf71f806eb Author: alanb Date: 2008-08-31 18:32 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f9cf71f806eb 6570619: (bf) DirectByteBuffer.get/put(byte[]) does not scale well Reviewed-by: iris ! make/java/java/mapfile-vers ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/native/java/nio/Bits.c Changeset: 343253d05123 Author: alanb Date: 2008-08-31 18:39 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/343253d05123 4640544: New I/O: Complete socket-channel functionality Reviewed-by: iris, sherman, chegar ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/mksample/nio/Makefile + make/mksample/nio/multicast/Makefile ! src/share/classes/java/net/NetworkInterface.java + src/share/classes/java/net/ProtocolFamily.java + src/share/classes/java/net/SocketOption.java + src/share/classes/java/net/StandardProtocolFamily.java + src/share/classes/java/net/StandardSocketOption.java ! src/share/classes/java/nio/channels/DatagramChannel.java + src/share/classes/java/nio/channels/MembershipKey.java + src/share/classes/java/nio/channels/MulticastChannel.java + src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/exceptions + src/share/classes/java/nio/channels/package-info.java - src/share/classes/java/nio/channels/package.html ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java + src/share/classes/sun/nio/ch/ExtendedSocketOption.java + src/share/classes/sun/nio/ch/MembershipKeyImpl.java + src/share/classes/sun/nio/ch/MembershipRegistry.java ! src/share/classes/sun/nio/ch/Net.java - src/share/classes/sun/nio/ch/OptionAdaptor.java + src/share/classes/sun/nio/ch/OptionKey.java ! src/share/classes/sun/nio/ch/SelectorProviderImpl.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h + src/share/native/sun/nio/ch/genSocketOptionRegistry.c + src/share/sample/nio/multicast/MulticastAddress.java + src/share/sample/nio/multicast/Reader.java + src/share/sample/nio/multicast/Sender.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/FileKey.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/solaris/native/sun/nio/ch/nio_util.h ! src/windows/native/java/net/net_util_md.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c + test/java/nio/channels/DatagramChannel/BasicMulticastTests.java + test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java + test/java/nio/channels/DatagramChannel/NetworkConfiguration.java + test/java/nio/channels/DatagramChannel/SocketOptionTests.java + test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java + test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/TestUtil.java + test/java/nio/channels/etc/NetworkChannelTests.java Changeset: 0a427d0e70a7 Author: emcmanus Date: 2008-09-01 17:11 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0a427d0e70a7 6731410: JMXServiceURL cannot use @ConstructorProperties for compatibility reasons Reviewed-by: dfuchs ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! test/javax/management/mxbean/JMXServiceURLTest.java Changeset: 1d1d66438d11 Author: emcmanus Date: 2008-09-02 14:14 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1d1d66438d11 6405862: Allow CompositeType to have zero items 6737133: Compilation failure of test/javax/management/eventService/LeaseManagerDeadlockTest.java 6737140: Javadoc of some throw clauses of MBeanServer and MBeanServerConnection is garbled 6737143: createMBean of MBeanServer should acquire 2 extra throw clauses present in MBeanServerConnection Reviewed-by: dfuchs ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! test/javax/management/eventService/LeaseManagerDeadlockTest.java Changeset: 00ea8fc81867 Author: emcmanus Date: 2008-09-03 14:31 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/00ea8fc81867 6744132: Spurious failures from test/javax/management/MBeanInfo/NotificationInfoTest.java Reviewed-by: dfuchs ! test/javax/management/MBeanInfo/NotificationInfoTest.java Changeset: 9145ff046bb4 Author: dfuchs Date: 2008-09-04 14:46 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9145ff046bb4 5072476: RFE: support cascaded (federated) MBean Servers 6299231: Add support for named MBean Servers Summary: New javax.management.namespace package. Reviewed-by: emcmanus ! make/docs/CORE_PKGS.gmk ! src/share/classes/com/sun/jmx/defaults/JmxProperties.java ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java + src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java + src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/MBeanServerInterceptor.java + src/share/classes/com/sun/jmx/interceptor/MBeanServerInterceptorSupport.java - src/share/classes/com/sun/jmx/interceptor/MBeanServerSupport.java + src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/SingleMBeanForwarder.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/mbeanserver/SunJmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java + src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java + src/share/classes/com/sun/jmx/namespace/HandlerInterceptor.java + src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java + src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java + src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java + src/share/classes/com/sun/jmx/namespace/RoutingConnectionProxy.java + src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java + src/share/classes/com/sun/jmx/namespace/RoutingProxy.java + src/share/classes/com/sun/jmx/namespace/RoutingServerProxy.java + src/share/classes/com/sun/jmx/namespace/package.html + src/share/classes/com/sun/jmx/namespace/serial/DefaultRewritingProcessor.java + src/share/classes/com/sun/jmx/namespace/serial/IdentityProcessor.java + src/share/classes/com/sun/jmx/namespace/serial/JMXNamespaceContext.java + src/share/classes/com/sun/jmx/namespace/serial/RewritingProcessor.java + src/share/classes/com/sun/jmx/namespace/serial/RoutingOnlyProcessor.java + src/share/classes/com/sun/jmx/namespace/serial/SerialRewritingProcessor.java + src/share/classes/com/sun/jmx/namespace/serial/package.html ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EventClientConnection.java ! src/share/classes/javax/management/InstanceNotFoundException.java ! src/share/classes/javax/management/MBeanPermission.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerDelegate.java ! src/share/classes/javax/management/MBeanServerFactory.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/EventClientDelegate.java + src/share/classes/javax/management/namespace/JMXDomain.java + src/share/classes/javax/management/namespace/JMXNamespace.java + src/share/classes/javax/management/namespace/JMXNamespaceMBean.java + src/share/classes/javax/management/namespace/JMXNamespacePermission.java + src/share/classes/javax/management/namespace/JMXNamespaceView.java + src/share/classes/javax/management/namespace/JMXNamespaces.java + src/share/classes/javax/management/namespace/JMXRemoteNamespace.java + src/share/classes/javax/management/namespace/JMXRemoteNamespaceMBean.java + src/share/classes/javax/management/namespace/MBeanServerConnectionWrapper.java + src/share/classes/javax/management/namespace/MBeanServerSupport.java + src/share/classes/javax/management/namespace/VirtualEventManager.java + src/share/classes/javax/management/namespace/package-info.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java + test/javax/management/MBeanServerFactory/NamedMBeanServerTest.java ! test/javax/management/ObjectName/ApplyWildcardTest.java + test/javax/management/namespace/DomainCreationTest.java + test/javax/management/namespace/EventWithNamespaceControlTest.java + test/javax/management/namespace/EventWithNamespaceTest.java + test/javax/management/namespace/ExportNamespaceTest.java + test/javax/management/namespace/JMXDomainTest.java + test/javax/management/namespace/JMXNamespaceSecurityTest.java + test/javax/management/namespace/JMXNamespaceTest.java + test/javax/management/namespace/JMXNamespaceViewTest.java + test/javax/management/namespace/JMXNamespacesTest.java + test/javax/management/namespace/JMXRemoteNamespaceTest.java + test/javax/management/namespace/JMXRemoteTargetNamespace.java + test/javax/management/namespace/LazyDomainTest.java + test/javax/management/namespace/MXBeanRefTest.java + test/javax/management/namespace/NamespaceController.java + test/javax/management/namespace/NamespaceControllerMBean.java + test/javax/management/namespace/NamespaceCreationTest.java + test/javax/management/namespace/NamespaceNotificationsTest.java + test/javax/management/namespace/NullDomainObjectNameTest.java + test/javax/management/namespace/NullObjectNameTest.java + test/javax/management/namespace/QueryNamesTest.java + test/javax/management/namespace/RemoveNotificationListenerTest.java + test/javax/management/namespace/RoutingServerProxyTest.java + test/javax/management/namespace/SerialParamProcessorTest.java + test/javax/management/namespace/SourceNamespaceTest.java + test/javax/management/namespace/VirtualMBeanNotifTest.java + test/javax/management/namespace/VirtualMBeanTest.java + test/javax/management/namespace/VirtualNamespaceQueryTest.java + test/javax/management/namespace/VirtualPropsTest.java + test/javax/management/namespace/Wombat.java + test/javax/management/namespace/WombatMBean.java + test/javax/management/namespace/namespace.policy Changeset: 71a5f3f55b9c Author: tbell Date: 2008-09-04 14:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/71a5f3f55b9c Merge - src/share/classes/com/sun/jmx/interceptor/MBeanServerSupport.java - src/share/classes/java/nio/channels/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions Changeset: 59aa6b578cf0 Author: bristor Date: 2008-09-08 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/59aa6b578cf0 6661861: Decrease memory use of Inflaters by ZipFile Summary: Fix allows release of native resources earlier than without fix Reviewed-by: alanb ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipFile.java Changeset: 334efd173b8f Author: bristor Date: 2008-09-08 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/334efd173b8f 6356642: extcheck.exe -verbose throws ArrayIndexOutOfBoundsException exception Summary: Fix causes printing of user-level error messages instead of throwing exceptions Reviewed-by: sherman ! src/share/classes/com/sun/tools/extcheck/ExtCheck.java ! src/share/classes/com/sun/tools/extcheck/Main.java + test/com/sun/tools/extcheck/TestExtcheckArgs.java + test/com/sun/tools/extcheck/TestExtcheckArgs.sh Changeset: 8484e830666e Author: tbell Date: 2008-09-12 14:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8484e830666e Merge Changeset: a23b7f4f8b3c Author: ohair Date: 2008-09-10 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a23b7f4f8b3c 6746421: Compare images logic needs to be more forgiving Reviewed-by: tbell ! make/common/shared/Defs.gmk Changeset: 395eb8a7846b Author: ohair Date: 2008-09-10 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/395eb8a7846b 6746424: Remove build dependency on findbugs and FINDBUGS_HOME Reviewed-by: tbell ! make/common/Sanity.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jprt.config Changeset: ec301c0956be Author: ohair Date: 2008-09-10 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ec301c0956be 6746430: Fix problems with getting 'ant -version' and the required setting of 'ANT_HOME' Reviewed-by: tbell ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 41bcf49eb3a1 Author: ohair Date: 2008-09-10 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/41bcf49eb3a1 6746409: Error: dl failure on line 689: Copies of libjvm.so need to have chcon (selinux) re-applied to them Reviewed-by: tbell ! make/common/Defs.gmk Changeset: c7ab37f5976d Author: ohair Date: 2008-09-11 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c7ab37f5976d 6746415: The include file stropts.h is not available in Fedora 9 (STREAMS Kernel Extension?) Reviewed-by: tbell ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h Changeset: da5513a6af53 Author: ohair Date: 2008-09-11 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/da5513a6af53 Merge ! make/common/Defs.gmk - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h Changeset: 16818689f727 Author: xdono Date: 2008-09-17 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/16818689f727 Merge - src/share/classes/com/sun/jmx/interceptor/MBeanServerSupport.java - src/share/classes/java/nio/channels/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions Changeset: 80a4ace80c31 Author: ant Date: 2008-06-04 12:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/80a4ace80c31 6280057: I have audited SystemTray and TrayIcon code Summary: small refactoring Reviewed-by: dcherepanov ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TrayIcon.java Changeset: adebdf3701a4 Author: ant Date: 2008-06-04 14:16 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/adebdf3701a4 6708322: test/closed/java/awt/Focus/TemporaryLostComponentDeadlock fails Summary: Introduced new package private object for synchronization purposes. It should replace "this" in some deadlock prone cases. Reviewed-by: anthony, art ! src/share/classes/java/awt/Component.java Changeset: 58a2ba2767be Author: yan Date: 2008-06-11 01:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/58a2ba2767be Merge - src/solaris/classes/sun/java2d/SurfaceManagerFactory.java - src/windows/classes/sun/java2d/SurfaceManagerFactory.java - test/javax/management/Introspector/LegacyIntrospectorTest.java Changeset: a9b5b5d105a8 Author: ant Date: 2008-06-17 13:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a9b5b5d105a8 4685768: A11y issue - Focus set to disabled component, can't Tab/Shift-Tab Summary: The restore-focus procedure should skip disabled components. Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Window.java + test/java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java + test/java/awt/Focus/RequestFocusToDisabledCompTest/RequestFocusToDisabledCompTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: d407360176c0 Author: dav Date: 2008-06-18 15:35 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d407360176c0 6616323: consider benefits of replacing a componen array with other collection from the awt.Container class Reviewed-by: uta, art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ScrollPane.java ! src/windows/native/sun/windows/awt_Container.cpp ! src/windows/native/sun/windows/awt_Container.h + test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java Changeset: 142e19f00424 Author: dav Date: 2008-06-18 19:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/142e19f00424 6716137: Fix 6691328 is broken Reviewed-by: dcherepanov, denis ! src/share/classes/java/awt/dnd/DragSourceContext.java Changeset: 321f5f269836 Author: dav Date: 2008-06-18 19:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/321f5f269836 Merge Changeset: 38e32b2db431 Author: yan Date: 2008-06-19 11:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/38e32b2db431 6706121: makefile: unnecessary Motif classes compilation in JDK7 Summary: removed 80 obsolete .c and .java files, temporary modified some more Reviewed-by: denis ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/awt/mawt.gmk ! make/sun/jawt/Makefile - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java ! src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c ! src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c ! src/solaris/native/sun/awt/awt_Robot.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c ! src/solaris/native/sun/awt/awt_p.h - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c ! src/solaris/native/sun/awt/initIDs.c ! src/solaris/native/sun/awt/multi_font.c Changeset: fae7c1f5ba78 Author: dav Date: 2008-06-19 16:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fae7c1f5ba78 6694792: Syntax error in java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_2.java Reviewed-by: yan ! test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_2.java Changeset: 9b66576b81f0 Author: ant Date: 2008-06-23 14:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9b66576b81f0 6682536: java\awt\FullScreen\NonfocusableFrameFullScreenTest\NonfocusableFrameFullScreenTest.java fails Summary: always-on-top property should be restored on exiting full-screen. Reviewed-by: tdv ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: 59e34bb65340 Author: anthony Date: 2008-06-23 16:03 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/59e34bb65340 6704896: FD_SET usage can cause stack corruption (sol) Summary: Using poll() instead of select() Reviewed-by: yan, denis ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: 4ccac6957211 Author: dcherepanov Date: 2008-06-26 14:23 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4ccac6957211 6581899: JTextField & JTextArea - Poor performance with JRE 1.5.0_08 Summary: acquire the first|last components only when the key is a traversal key Reviewed-by: ant ! src/share/classes/sun/awt/EmbeddedFrame.java Changeset: d2165ac39874 Author: dcherepanov Date: 2008-07-07 15:36 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d2165ac39874 6582346: javaw launcher does not display MessageBox after change to the resource files Summary: call InitCommonControlsEx to perform UI initialization Reviewed-by: art ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h Changeset: d635c9a971c9 Author: dav Date: 2008-07-07 16:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d635c9a971c9 6693974: Unify EventQueue$EventQueueItem and SunToolkit.$EventQueueItem classes Reviewed-by: volk, art ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 9a1b30777d9d Author: dav Date: 2008-07-07 16:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9a1b30777d9d Merge Changeset: 5a75640258ba Author: anthony Date: 2008-07-07 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5a75640258ba 6682046: Mixing code does not always recalculate shapes correctly when resizing components Summary: The valid property is now encapsulated in Component. Reviewed-by: art ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Label.java ! src/share/classes/java/awt/TextField.java Changeset: 3361b420a0a2 Author: anthony Date: 2008-07-07 17:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3361b420a0a2 6723018: Need to push the test for 6682046 Summary: Pushed the test Reviewed-by: art + test/java/awt/Mixing/Validating.java Changeset: 9c9f18a2cdef Author: dav Date: 2008-07-08 16:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9c9f18a2cdef 6723013: Incomplete push for 6693974 Reviewed-by: art + src/share/classes/sun/awt/EventQueueItem.java Changeset: 250129565224 Author: art Date: 2008-07-25 15:19 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/250129565224 6235443: REG:Overlapping a swing app with an AWT app causes flickering in the background swing app on Windows Summary: AWT text area no longer uses LockWindowUpdate Reviewed-by: uta, dcherepanov ! src/windows/native/sun/windows/awt_TextArea.cpp Changeset: 97d85ec01100 Author: yan Date: 2008-08-05 15:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/97d85ec01100 6454041: decimal separator munches the character standing at the right (sk keyboard) Summary: in a group of keysyms associated with a key, check for keypad-ness of more keysyms Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: f0043a2428f6 Author: yan Date: 2008-08-08 03:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f0043a2428f6 Merge - make/java/nio/spp.sh ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux - make/tools/winver/Makefile - make/tools/winver/bin/winver.exe - make/tools/winver/src/StdAfx.cpp - make/tools/winver/src/StdAfx.h - make/tools/winver/src/winver.cpp - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java - src/share/classes/javax/management/ToQueryString.java ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: 5e61b8180623 Author: art Date: 2008-08-12 12:00 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5e61b8180623 6735584: XNETProtocol:setStateHelper() produces bad _NET_WM_STATE messages Reviewed-by: yan ! src/solaris/classes/sun/awt/X11/XNETProtocol.java Changeset: 99658a8d42fa Author: art Date: 2008-08-14 12:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/99658a8d42fa 6708392: Provide internal API to create OverrideRedirect windows, XToolkit Summary: SunToolkit.setOverrideRedirect() method is introduced Reviewed-by: mlapshin, yan ! src/share/classes/javax/swing/Popup.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: e8301d67f7fa Author: dcherepanov Date: 2008-08-25 19:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8301d67f7fa 6737722: api/java_awt/TrayIcon/index.html#TrayIconHeadlessMode Summary: isSupported() should skip tray initialization in case of headless Reviewed-by: art, ant ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TrayIcon.java + test/java/awt/Toolkit/HeadlessTray/HeadlessTray.java Changeset: 9d5e52760d53 Author: lana Date: 2008-08-25 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9d5e52760d53 Merge - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c Changeset: 134fd1a656ea Author: lana Date: 2008-09-19 19:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/134fd1a656ea Merge - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c Changeset: 73b3e1a40bdf Author: xdono Date: 2008-09-25 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/73b3e1a40bdf Added tag jdk7-b36 for changeset 134fd1a656ea ! .hgtags From john.coomes at sun.com Fri Sep 26 02:24:08 2008 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Sep 2008 09:24:08 +0000 Subject: hg: jdk7/hotspot/langtools: 7 new changesets Message-ID: <20080926092421.13F6DD313@hg.openjdk.java.net> Changeset: e571266ae14f Author: jjg Date: 2008-08-26 14:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e571266ae14f 6508981: cleanup file separator handling in JavacFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/javax/tools/StandardLocation.java + test/tools/javac/6508981/TestInferBinaryName.java + test/tools/javac/6508981/p/A.java ! test/tools/javac/T6725036.java Changeset: 5e89c4ca637c Author: jjg Date: 2008-08-29 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5e89c4ca637c 6597471: unused imports in javax.tools.JavaCompiler 6597531: unused imports and unused private const. in com.sun.tools.javac.Server.java Reviewed-by: mcimadamore Contributed-by: davide.angelocola at gmail.com ! src/share/classes/com/sun/tools/javac/Server.java ! src/share/classes/com/sun/tools/javac/api/JavacScope.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/model/FilteredMemberList.java ! src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/Context.java Changeset: 7b59e34898ff Author: tbell Date: 2008-08-31 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7b59e34898ff Merge Changeset: ceaa6549687a Author: jjg Date: 2008-09-03 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ceaa6549687a 6743107: clean up use of static caches in file manager Reviewed-by: mcimadamore + src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java + src/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: 5a9b808557b6 Author: tbell Date: 2008-09-04 14:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/5a9b808557b6 Merge Changeset: 258af9b67b7c Author: tbell Date: 2008-09-12 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/258af9b67b7c Merge Changeset: 2c643f1be517 Author: xdono Date: 2008-09-25 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2c643f1be517 Added tag jdk7-b36 for changeset 258af9b67b7c ! .hgtags From yamauchi at google.com Fri Sep 26 13:55:50 2008 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Fri, 26 Sep 2008 13:55:50 -0700 Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6 In-Reply-To: <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM> References: <48C91B82.4020502@sun.com> <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com> <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com> <48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com> <0607D027-8ADD-438B-91FB-A4D0AECAD113@sun.com> <8637E22A-8145-4C06-9E31-E7952FFA5630@Sun.COM> Message-ID: With the patch, I haven't seen it crash in my experience. Hiroshi On Thu, Sep 25, 2008 at 12:29 PM, Tom Rodriguez wrote: >> I'm not sure what you mean by collector. But as far as I can tell >> AsyncGetCallTrace >> is a lot more stable and shows more stack frames with the patch. If Sun >> folks >> have tests for it, it'd be great if someone can run them against this >> patch. > > I was only referring to testing it with a profiling tool and the SunStudio > collector is the only one I know of that uses AsyncGetCallTrace. When you > say "a lot more stable" do you mean it doesn't crash or it crashes less? > > tom > >> >> Thanks, >> Hiroshi >> >> >>> On Sep 17, 2008, at 4:50 PM, Hiroshi Yamauchi wrote: >>> >>>> Hi, Any comment about the patch itself? >>>> >>>> On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy >>>> wrote: >>>>> >>>>> Joseph D. Darcy wrote: >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> 2008/9/11 Andrew John Hughes : >>>>>>>> >>>>>>>> 2008/9/11 Daniel D. Daugherty : >>>>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>> >>>>>>>>> FWIW, I don't see any change to the HS_ version numbers in our >>>>>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot. >>>>>>>>> Given OpenJDK6 was derived from something like b20, I guess this is >>>>>>>>> not that strange. >>>>>>>>> >>>>>>>>> JDK7-B24 has the following values: >>>>>>>>> >>>>>>>>> HS_MAJOR_VER=12 >>>>>>>>> HS_MINOR_VER=0 >>>>>>>>> HS_BUILD_NUMBER=01 >>>>>>>>> >>>>>>>>> Joe stated earlier in this thread that OpenJDK6 is based on >>>>>>>>> HSX-10 so its values should not be the same. For 1.6.0_07, >>>>>>>>> I see: >>>>>>>>> >>>>>>>>> HS_MAJOR_VER=10 >>>>>>>>> HS_MINOR_VER=0 >>>>>>>>> HS_BUILD_NUMBER=23 >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hmmm... >>>>>>>> Then either Gary's HotSpot patch doesn't update that file or >>>>>>>> OpenJDK6 >>>>>>>> is not based on the same as this 1.6.0_07 thing you mention. >>>>>>>> I'll try and have a closer look later. >>>>>>>> -- >>>>>>>> Andrew :-) >>>>>>>> >>>>>>>> Support Free Java! >>>>>>>> Contribute to GNU Classpath and the OpenJDK >>>>>>>> http://www.gnu.org/software/classpath >>>>>>>> http://openjdk.java.net >>>>>>>> >>>>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>>>>> >>>>>>> >>>>>>> IcedTea6 contains: >>>>>>> >>>>>>> HS_MAJOR_VER=10 >>>>>>> HS_MINOR_VER=0 >>>>>>> HS_BUILD_NUMBER=19 >>>>>>> >>>>>>> IcedTea/b33 contains: >>>>>>> >>>>>>> HS_MAJOR_VER=14 >>>>>>> HS_MINOR_VER=0 >>>>>>> HS_BUILD_NUMBER=01 >>>>>>> >>>>>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not >>>>>>> make/hotspot_version >>>>>>> so it's actually worryingly building a different version of HotSpot >>>>>>> from the one it thinks it is. >>>>>>> It will actually be 12-0-01 as you state, but will report 10-0-19. >>>>>>> >>>>>>> Overall, it would be better to always build against the most recent >>>>>>> stable HotSpot tree if possible >>>>>>> rather than the one provided by the build drop. Do we know what the >>>>>>> most stable would be? >>>>>> >>>>>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. >>>>>> The >>>>>> policy I've implemented, >>>>>> >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, >>>>>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update >>>>>> releases, >>>>>> augmented with some other fixes for license corrections, gcc build >>>>>> issues, >>>>>> (and the occasional Eclipse crash). The HotSpot in the base OpenJDK 6 >>>>>> code >>>>>> base is very close to the HotSpot in the currently shipping 6 update >>>>>> release. >>>>> >>>>> ... and going forward we will have much closer coordination between the >>>>> OpenJDK 6 and 6 update HotSpots since we'll be using the same source >>>>> for >>>>> both; so the version information should be updated consistently, etc. >>>>> >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html >>>>> >>>>> -Joe >>>>> >>> >>> > > From Xiaobin.Lu at Sun.COM Tue Sep 30 17:11:53 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 30 Sep 2008 17:11:53 -0700 Subject: compatibility issue regarding the active processor count Message-ID: <48E2C049.2060409@Sun.COM> Hi folks, I need your opinion about what we should do to solve the compatibility issue regarding the active processor count. Basically, the problem is on Solaris, if you create a processor set and then launch java process without binding to that processor set, the number of available processors to that java process is the total number of the online processors minus the number of processors in the processor set you created. Currently, we just report the total number of the online processors as the active processor count which is wrong. This makes the parallel garbage collector to behave in the wrong way (see bug 6749430 for details) and we need to fix it per request from CBOE. There may be a compatibility issue after we correct this wrong behavior when someone has already depended on this wrong return, which we think it might be rare. We definitely need to invent a new flag in order to address this and the question is whether we should keep the current behavior as default or not. Personally, I feel we should have that flag to fall back to the current wrong behavior, but I might be wrong. Thanks so much in advance for your opinion. -Xiaobin