From Vladimir.Kozlov at Sun.COM Mon Jan 5 12:04:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 05 Jan 2009 12:04:53 -0800 Subject: Request for reviews (XS): 6712157: Tests should not use JDK64BIT file to set -d64 option Message-ID: <496267E5.3010003@sun.com> http://webrev.invokedynamic.info/kvn/6712157/index.html Fixed 6712157: Tests should not use JDK64BIT file to set -d64 option Problem: Some HotSpot regression tests use a shell script which checks that JDK6BIT file exists in user home directory to run with -d64 option. First, it causes different problems during testing, for example, 32-bits and 64-bits testing can't be run on the same machine in parallel. Second, it is not needed for this test since run options (-d64) are appended to the test options. Solution: Move the test options from the script to the jtreg command specification in the .java file and remove the test script. Reviewed by: Fix verified (y/n): y Other testing: JPRT From Vladimir.Kozlov at Sun.COM Mon Jan 5 16:29:33 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 05 Jan 2009 16:29:33 -0800 Subject: Request for reviews (XS): 6790182: matcher.cpp:1375: assert(false,"bad AD file") Message-ID: <4962A5ED.5050501@sun.com> http://webrev.invokedynamic.info/kvn/6790182/index.html Fixed 6790182: matcher.cpp:1375: assert(false,"bad AD file") Problem: The problem is that a regD_low isn't considered a regD so it can't match a sub with regDs. Solution: Add a match rule for regD_low in regD definition to declare that a regD_low is also a regD. Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT From gbenson at redhat.com Tue Jan 6 05:17:24 2009 From: gbenson at redhat.com (Gary Benson) Date: Tue, 6 Jan 2009 13:17:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6778657: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined C++ behaviour In-Reply-To: <87fxk9s3yo.fsf@mid.deneb.enyo.de> References: <20081223020909.1ECFCDDC6@hg.openjdk.java.net> <87fxk9s3yo.fsf@mid.deneb.enyo.de> Message-ID: <20090106131724.GE3238@redhat.com> Florian Weimer wrote: > * vladimir kozlov: > > 6778657: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined C++ behaviour > > Summary: Replaces SharedRuntime::f2i et al with versions that should work > > This: > > JRT_LEAF(jlong, SharedRuntime::f2l(jfloat x)) > - if (g_isnan(x)) {return 0;} > - jlong lltmp = (jlong)x; > - if (lltmp != min_jlong) { > - return lltmp; > - } else { > - if (x < 0) { > - return min_jlong; > - } else { > - return max_jlong; > - } > - } > + if (g_isnan(x)) > + return 0; > + if (x >= (jfloat) max_jlong) > + return max_jlong; > + if (x <= (jfloat) min_jlong) > + return min_jlong; > + return (jlong) x; > JRT_END > > doesn't look right because > > (jfloat) max_jlong and (jfloat) min_jlong > > are not fully specified, either (they can be off by one, and so the > comparison could be false even if the subsequent cast is undefined). It's true that (jfloat) max_jlong cannot be represented exactly, but this doesn't matter here because the argument x is also a jfloat and so subject to the same limitation. (jfloat) max_jlong is 0x1p+63, and the predecessor of 0x1p+63 is 0x1.fffffep+62. If you check the return value of f2l across the boundary you get: Input Output 0x1.fffffep+62 0x7fffff8000000000 // return (jlong) x 0x1p+63 0x7fffffffffffffff // return max_jlong; There is no float between 0x1.fffffep+62 and 0x1p+63, so there's no input to f2l that can be off by one. This affects (jfloat) max_jint too, but the same logic applies. As exact powers of two, (jfloat) min_jlong and (jfloat) min_jint are exactly representable, so there's no problem there either. (Thanks to Andrew Haley for explaining some of this to me.) Cheers, Gary -- http://gbenson.net/ From Vladimir.Kozlov at Sun.COM Tue Jan 6 15:12:38 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 06 Jan 2009 15:12:38 -0800 Subject: Request for reviews (XXXS): 6570745: closed/compiler/4671460/CharArrTest.java fails on RHEL server 5 Message-ID: <4963E566.8050404@sun.com> http://webrev.invokedynamic.info/kvn/6570745/index.html Fixed 6570745: closed/compiler/4671460/CharArrTest.java fails on RHEL server 5 Problem: The test's shell script uses "tail +n" syntax which is not acceptable on new RHEL versions. Solution: Change "tail +n" to "tail -n". Reviewed by: Other testing: JPRT From Vladimir.Kozlov at Sun.COM Tue Jan 6 17:46:13 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 06 Jan 2009 17:46:13 -0800 Subject: Request for reviews (XS): 6561159: Regression test closed/compiler/6434117/TestNativeRevocation behaves unpredictably Message-ID: <49640965.6080507@sun.com> http://webrev.invokedynamic.info/kvn/6561159/index.html Fixed 6561159: Regression test closed/compiler/6434117/TestNativeRevocation behaves unpredictably Problem: A situation is possible where the test's queue in RevokerThread becomes rather populated when queue.remove(0) does not keep up with queue.add(t) since it have to shift all queue's elements, which leads to queue.remove(0) being very slow, and the whole test timing out as a result. Rapid production of Throwable's in the main thread under these conditions also frequently leads to OutOfMemoryException (with 64Mb default heap). Solution: Remove an element from the end of the queue to avoid elements shift which helps to keep the queue small. Also reduce BiasedLockingStartupDelay to 50ms to test bias revocation from the start (on modern cpus fixed test runs 2 sec). Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT From thomas.rodriguez at sun.com Tue Jan 6 19:51:50 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 07 Jan 2009 03:51:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7 new changesets Message-ID: <20090107035204.4449DD192@hg.openjdk.java.net> Changeset: ad8c8ca4ab0f Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ad8c8ca4ab0f 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/cpu/x86/vm/vm_version_x86_32.hpp ! src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/globals_linux.hpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.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/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: 5e5faba1ac11 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5e5faba1ac11 Added tag jdk7-b42 for changeset ad8c8ca4ab0f ! .hgtags Changeset: 569b3b226089 Author: trims Date: 2008-12-20 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/569b3b226089 Merge ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 26bc4770e671 Author: trims Date: 2008-12-20 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/26bc4770e671 Merge ! src/share/vm/runtime/javaCalls.cpp Changeset: fc6a5ae3fef5 Author: trims Date: 2008-12-20 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc6a5ae3fef5 6787832: Bump Hotspot build number to 08 Summary: Update the HS14 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3cd5c5b027b1 Author: trims Date: 2008-12-23 19:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cd5c5b027b1 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM Summary: fork Hotspot 15 - redo verisoning numbers Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1a767c61ad01 Author: never Date: 2009-01-06 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1a767c61ad01 Merge From vladimir.kozlov at sun.com Wed Jan 7 13:59:36 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 07 Jan 2009 21:59:36 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6782232: assert("CreateEx must be first instruction in block" ) Message-ID: <20090107215938.1A482D27A@hg.openjdk.java.net> Changeset: 96964ebdb154 Author: kvn Date: 2009-01-07 11:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/96964ebdb154 6782232: assert("CreateEx must be first instruction in block" ) Summary: Add the missing check for CreateEx. Add new notproduct flag VerifyRegisterAllocator. Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/reg_split.cpp From vladimir.kozlov at sun.com Wed Jan 7 16:46:45 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 08 Jan 2009 00:46:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6790182: matcher.cpp:1375: assert(false, "bad AD file") Message-ID: <20090108004647.2DA9CD288@hg.openjdk.java.net> Changeset: 6c4cda924d2e Author: kvn Date: 2009-01-07 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6c4cda924d2e 6790182: matcher.cpp:1375: assert(false,"bad AD file") Summary: Add a match rule for regD_low in regD definition. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad From Vladimir.Kozlov at Sun.COM Fri Jan 9 10:05:45 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 09 Jan 2009 10:05:45 -0800 Subject: Request for reviews (S): 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Message-ID: <496791F9.30306@sun.com> http://webrev.invokedynamic.info/kvn/6791852/index.html Fixed 6791852: assert(b->_nodes[insidx] == n,"got insidx set incorrectly") Problem: The code in PhaseChaitin::Split() in the part "Handle Crossing HRP Boundry" expects that new spillCopy nodes are inserted before the current node. After 6782232 fix it is not true if the current node is CreateEx. There should be now spill copies in an exception block for lrgs coming into it. Solution: Record the exception block as having high registers pressure to avoid the insertion of spill copies before CreateEx node. Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT From Thomas.Rodriguez at Sun.COM Fri Jan 9 13:42:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Jan 2009 13:42:37 -0800 Subject: review (S) for 6788347 Message-ID: <4F17CC9C-E2EC-4CC0-B9B1-75753A1DE53F@Sun.COM> http://webrev.invokedynamic.info/never/6788347/ From Thomas.Rodriguez at Sun.COM Fri Jan 9 13:54:55 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 Jan 2009 13:54:55 -0800 Subject: review (XS) for 6791132 Message-ID: http://webrev.invokedynamic.info/never/6791132 From rouhollah.gougol at students.sjsu.edu Sat Jan 10 01:13:41 2009 From: rouhollah.gougol at students.sjsu.edu (rouhollah.gougol at students.sjsu.edu) Date: Sat, 10 Jan 2009 01:13:41 -0800 Subject: Profiling Interpreter Message-ID: Hello, Would somebody kindly answer this question: Does the profiling of a method interpretation start from the begging of the method interpretation or it does later when the method is already invoked as many as CompileThreshold * InterpreterProfilePercentage/ 100 ? I believe profiling the interpretation is by default disable for x86_32bit platforms? Can you explain why and is it the same in the server mode and the Tiered mode? Sincerely, R. Gougol -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090110/11535957/attachment.html From rouhollah.gougol at students.sjsu.edu Sat Jan 10 22:44:36 2009 From: rouhollah.gougol at students.sjsu.edu (rouhollah.gougol at students.sjsu.edu) Date: Sat, 10 Jan 2009 22:44:36 -0800 Subject: counter carry Message-ID: Hello everybody, Would somebody explain to me what happens to the invocation can backward branch counters of a method after the JIT compilation of the method. Will the conters be reset and incremented again? Why Hotspot sets carry and states bits in the counter and where and how does it check these bits? Thanks in Advance, R. N. Gougol -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090110/79885a08/attachment.html From linuxhippy at gmail.com Mon Jan 12 04:57:15 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Mon, 12 Jan 2009 13:57:15 +0100 Subject: Interest in support for saturated casts? In-Reply-To: <4967C3F2.7020202@sun.com> References: <194f62550812221251w19d2c55aye53c19476275bbce@mail.gmail.com> <4967C3F2.7020202@sun.com> Message-ID: <194f62550901120457h373cd22awf16b6585607c7d4c@mail.gmail.com> Hi, Support for unsigned integer arithmetic sounds quite useful, I also have written some quirks to deal with unsigned data previously. Looking foreward to fix this code :) > Perhaps there could also be methods for saturating conversions, > Integer.toSaturatedShort(int) > The presence of such standard methods would make it easier for HotSpot to > intrinsify them on platforms with direct hardware support. Would be great if those methods could be added as part of that work :) Thanks, Clemens From mail at nmichael.de Tue Jan 13 03:45:49 2009 From: mail at nmichael.de (Nicolas Michael) Date: Tue, 13 Jan 2009 11:45:49 GMT Subject: Code Cache, Compilation & Inlining Message-ID: Hi, we're running Java 1.6.0_07 (Hotspot 10.0-b23) 32bit on SPARC Solaris (Client as well as Server VM). Our JVM options: -Xms1400M -Xmx2400M -XX:NewSize=512M -XX:MaxNewSize=512M -XX:SurvivorRatio=6 -XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+UseLWPSynchronization -XX:CMSInitiatingOccupancyFraction=90 -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=16 -XX:MinHeapFreeRatio=25 -XX:MaxHeapFreeRatio=40 -XX:PermSize=32m -XX:MaxPermSize=128m -XX:TargetSurvivorRatio=90 -XX:CompileThreshold=1500 -XX:+PrintCompilation -XX:+PrintInlining During the last weeks, I have spent some time looking closer at compilation and inlining, partly triggered by some "changing/degrading performance" we were observing in some scenarios. To trace compilation, I have switched to the 1.7.0-ea-fastdebug JVM (Hotspot 14.0-b07-fastdebug) and ran some tests. I have some questions about what I've noticed and hope to get some help here. 1. With the Server JVM, the code cache became full after 7827 compiles: "Java HotSpot(TM) Server VM warning: CodeCache is full. Compiler has been disabled" Setting -XX:ReservedCodeCacheSize to a large value got rid of this error and the JVM compiled 8809 methods in this run. My questions are: - How large is the code cache per default? - How can I monitor the current occupancy of the code cache? Neither jstat, jinfo nor a dump of all perfdata values seem to give any hint on this. - Can I see the code cache as a memory segment with pmap? Is it an "anon" segment? - Is there any limit for the code cache? In my tests where I increased it, I set it to 128m (which is much too large, I assume, but worked). 2. With the Server JVM and a large-enough code cache, I see some methods in the log being compiled, then being "made not entrant", being "made zombie" and then being compiled again, made not entrant, zombie, being compiled, ... Afaik, this "not entrant" and "zombie" stuff is some deoptimization, when the JIT thinks some of its original assumptions about those methods weren't good enough, right? Unfortunately, I can't find much info on the net about this. Could someone probably explain what those really mean and why this might happen? BTW, our CompileThreshold is set to 1500 also for the Server VM, and the process has been running for about half an hour or so. I didn't yet make any really long-running tests for hours or days with enabled +PrintCompilation, so I don't know whether this is an infinite loop of deoptimization and compilation or just happens "for some time". But still, even after half an hour I would not expect such a thing any more. 3. Now I'm referring to tests that I have done with the Client VM. I have noticed that not all methods are being compiled. A Sun Studio profile for a 1h run (after 30min warmup) is showing that 2.2% of the CPU time is due to Java methods being interpreted: Excl. Incl. Name User CPU User CPU 26363.141 26363.141 605.223 1049.764 Interpreter 587.311 587.311 java.lang.String.equals(java.lang.Object) ... I tried -XX:-DontCompileHugeMethods: This decreases the CPU time consumed by the Interpreter to 435.505 (Excl. User CPU) -- but still, some methods seem to be interpreted. We're running an application that's doing the same stuff all the time and doesn't have any change in behavior, so a CompileThreshold of 1500 should easily be reached quite fast. I remember tests for 2-Tiered together with Steve Goldman about 2 years ago when he told me something like our application is a huge application with lots of "lukewarm" methods. Anyway, is there a way to find out *which* methods are not being compiled and *why*? +PrintCompilation tells a lot of stuff about methods that are being compiled, but nothing about methods that Hotspot considers *not* being worth compiling ... ;-) 4. Also for the Client VM, same with inlining: We have a method (isTraceOn, to determine whether tracing is enabled or not) that's being called quite often. It's a small method, just 17 bytes: 499 xxx.xxx.xxx::isTraceOn (17 bytes) @ 0 xxx.xxx.xxx::isTraceOnInProcess (4 bytes) - @ 13 xxx.xxx.xxx::isTraceOnInternal (57 bytes) callee is too large I know from the Sun Studio profile which are the callers of isTraceOn. Those callers are getting compiled, e.g. the method traceSimple, but don't even consider to inline isTraceOn (I would expect to find something as "- @ xxx.xxx.xxx::isTraceOn" in the log with a note *why* Hotspot decided to not inline this method -- but it doesn't appear anywhere at all): 1330 xxx.xxx.xxx::traceSimple (91 bytes) ! - @ 29 xxx.xxx.xxx::prepareBuffer (196 bytes) callee is too large s @ 48 java.lang.StringBuffer::length (5 bytes) s @ 82 java.lang.StringBuffer::toString (17 bytes) - @ 13 java.lang.String:: (72 bytes) callee is too large What could be the reason that isTraceOn is not being inlined? BTW, I also tried to increase MaxInlineSize to 64 which didn't help. (Server VM does inline isTraceOn, but not the Client VM.) I can of course also provide full log files and everything... Thanks a lot, Nick. From Vladimir.Kozlov at Sun.COM Tue Jan 13 10:48:58 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 13 Jan 2009 10:48:58 -0800 Subject: Request for reviews (XS): 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") Message-ID: <496CE21A.8000503@sun.com> http://webrev.invokedynamic.info/kvn/6784930/index.html Fixed 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") Problem: The LRG's _area value 0. is used by RA to avoid additional splits of a spill copy which has one immediately following use. But _area value 0. could be also produced if a block has frequency 0. caused by a long chain of conditional branches with small probability P <= 0.1 so that a float value underflow. As result all LRGs in such blocks have the same high score 1e35 and RA can not make progress producing a lot of spill copies. Solution: Set minimum block frequency MIN_BLOCK_FREQUENCY 1.e-35f. Add the assert to check a block frequency. Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT From vladimir.kozlov at sun.com Tue Jan 13 13:36:24 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 13 Jan 2009 21:36:24 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6784930: server jvm fails with assert(!n->is_SpillCopy(), "") Message-ID: <20090113213626.A99FAD5D2@hg.openjdk.java.net> Changeset: 011517bbcd7b Author: kvn Date: 2009-01-13 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/011517bbcd7b 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") Summary: Set minimum block frequency MIN_BLOCK_FREQUENCY 1.e-35f. Reviewed-by: never, rasbold ! src/share/vm/opto/gcm.cpp From thomas.rodriguez at sun.com Tue Jan 13 14:06:31 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Tue, 13 Jan 2009 22:06:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090113220636.69C05D5DD@hg.openjdk.java.net> Changeset: 041fe019d769 Author: never Date: 2009-01-13 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/041fe019d769 6791132: bad control in autobox split code Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp Changeset: 78144dc3db03 Author: never Date: 2009-01-13 14:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/78144dc3db03 Merge From yamauchi at google.com Wed Jan 14 15:18:15 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 14 Jan 2009 15:18:15 -0800 Subject: Code Cache, Compilation & Inlining In-Reply-To: References: Message-ID: On Tue, Jan 13, 2009 at 3:45 AM, Nicolas Michael wrote: > Hi, > > we're running Java 1.6.0_07 (Hotspot 10.0-b23) 32bit on SPARC Solaris > (Client as well as Server VM). > > Our JVM options: > -Xms1400M -Xmx2400M -XX:NewSize=512M -XX:MaxNewSize=512M > -XX:SurvivorRatio=6 -XX:MaxTenuringThreshold=15 > -XX:+UseConcMarkSweepGC -XX:+UseLWPSynchronization > -XX:CMSInitiatingOccupancyFraction=90 > -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=16 > -XX:MinHeapFreeRatio=25 -XX:MaxHeapFreeRatio=40 -XX:PermSize=32m > -XX:MaxPermSize=128m -XX:TargetSurvivorRatio=90 > -XX:CompileThreshold=1500 -XX:+PrintCompilation -XX:+PrintInlining > > During the last weeks, I have spent some time looking closer at > compilation and inlining, partly triggered by some "changing/degrading > performance" we were observing in some scenarios. To trace compilation, > I have switched to the 1.7.0-ea-fastdebug JVM (Hotspot > 14.0-b07-fastdebug) and ran some tests. I have some questions about what > I've noticed and hope to get some help here. > > 1. > With the Server JVM, the code cache became full after 7827 compiles: > "Java HotSpot(TM) Server VM warning: CodeCache is full. Compiler has > been disabled" > Setting -XX:ReservedCodeCacheSize to a large value got rid of this error > and the JVM compiled 8809 methods in this run. > > My questions are: > - How large is the code cache per default? > - How can I monitor the current occupancy of the code cache? Neither > jstat, jinfo nor a dump of all perfdata values seem to give any hint on > this. I think one of the memory pools accessed via the MXBeans thing is the code cache. See http://java.sun.com/javase/6/docs/api/java/lang/management/ManagementFactory.html#getMemoryPoolMXBeans() > - Can I see the code cache as a memory segment with pmap? Is it an > "anon" segment? > - Is there any limit for the code cache? In my tests where I increased > it, I set it to 128m (which is much too large, I assume, but worked). > > 2. > With the Server JVM and a large-enough code cache, I see some methods in > the log being compiled, then being "made not entrant", being "made > zombie" and then being compiled again, made not entrant, zombie, being > compiled, ... Afaik, this "not entrant" and "zombie" stuff is some > deoptimization, when the JIT thinks some of its original assumptions > about those methods weren't good enough, right? Unfortunately, I can't > find much info on the net about this. Could someone probably explain > what those really mean and why this might happen? > > BTW, our CompileThreshold is set to 1500 also for the Server VM, and the > process has been running for about half an hour or so. I didn't yet make > any really long-running tests for hours or days with enabled > +PrintCompilation, so I don't know whether this is an infinite loop of > deoptimization and compilation or just happens "for some time". But > still, even after half an hour I would not expect such a thing any more. > > 3. > Now I'm referring to tests that I have done with the Client VM. > > I have noticed that not all methods are being compiled. A Sun Studio > profile for a 1h run (after 30min warmup) is showing that 2.2% of the > CPU time is due to Java methods being interpreted: > > Excl. Incl. Name > User CPU User CPU > 26363.141 26363.141 > 605.223 1049.764 Interpreter > 587.311 587.311 java.lang.String.equals(java.lang.Object) > ... > > I tried -XX:-DontCompileHugeMethods: This decreases the CPU time > consumed by the Interpreter to 435.505 (Excl. User CPU) -- but still, > some methods seem to be interpreted. We're running an application that's > doing the same stuff all the time and doesn't have any change in > behavior, so a CompileThreshold of 1500 should easily be reached quite > fast. I remember tests for 2-Tiered together with Steve Goldman about 2 > years ago when he told me something like our application is a huge > application with lots of "lukewarm" methods. Anyway, is there a way to > find out *which* methods are not being compiled and *why*? > +PrintCompilation tells a lot of stuff about methods that are being > compiled, but nothing about methods that Hotspot considers *not* being > worth compiling ... ;-) > > 4. > Also for the Client VM, same with inlining: We have a method (isTraceOn, > to determine whether tracing is enabled or not) that's being called > quite often. It's a small method, just 17 bytes: > > 499 xxx.xxx.xxx::isTraceOn (17 bytes) > @ 0 xxx.xxx.xxx::isTraceOnInProcess (4 bytes) > - @ 13 xxx.xxx.xxx::isTraceOnInternal (57 bytes) callee is > too large > > I know from the Sun Studio profile which are the callers of isTraceOn. > Those callers are getting compiled, e.g. the method traceSimple, but > don't even consider to inline isTraceOn (I would expect to find > something as "- @ xxx.xxx.xxx::isTraceOn" in the log with a note *why* > Hotspot decided to not inline this method -- but it doesn't appear > anywhere at all): > > 1330 xxx.xxx.xxx::traceSimple (91 bytes) > ! - @ 29 xxx.xxx.xxx::prepareBuffer (196 bytes) callee is too > large > s @ 48 java.lang.StringBuffer::length (5 bytes) > s @ 82 java.lang.StringBuffer::toString (17 bytes) > - @ 13 java.lang.String:: (72 bytes) callee is too > large > > What could be the reason that isTraceOn is not being inlined? BTW, I > also tried to increase MaxInlineSize to 64 which didn't help. (Server VM > does > inline isTraceOn, but not the Client VM.) > > I can of course also provide full log files and everything... > > Thanks a lot, > Nick. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090114/30054252/attachment.html From thomas.rodriguez at sun.com Wed Jan 14 16:36:02 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 15 Jan 2009 00:36:02 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6788347: C2Compiler crash 6u7 Message-ID: <20090115003606.1B946D7D4@hg.openjdk.java.net> Changeset: 35ae4dd6c27c Author: never Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/35ae4dd6c27c 6788347: C2Compiler crash 6u7 Reviewed-by: kvn ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp From Christian.Thalinger at Sun.COM Thu Jan 15 00:34:29 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Jan 2009 09:34:29 +0100 Subject: Request for reviews (XS): 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") In-Reply-To: <496CE21A.8000503@sun.com> References: <496CE21A.8000503@sun.com> Message-ID: <1232008469.1361.35.camel@localhost.localdomain> On Tue, 2009-01-13 at 10:48 -0800, Vladimir Kozlov wrote: > http://webrev.invokedynamic.info/kvn/6784930/index.html > > Fixed 6784930: server jvm fails with assert(!n->is_SpillCopy(),"") Damn, too late. There is a small typo in the assert message. I've already collected some typos and will add that one too. -- Christian From Christian.Thalinger at Sun.COM Thu Jan 15 01:27:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Jan 2009 10:27:57 +0100 Subject: Code Cache, Compilation & Inlining In-Reply-To: References: Message-ID: <1232011677.1361.62.camel@localhost.localdomain> On Tue, 2009-01-13 at 11:45 +0000, Nicolas Michael wrote: > My questions are: > - How large is the code cache per default? The reserved code cache size depends on the architecture and the compiler used. With a debug build you can use the -Xprintflags switch to get the default size: $ java -Xprintflags | grep CodeCacheSize uintx InitialCodeCacheSize = 2555904 {pd product} uintx ReservedCodeCacheSize = 50331648 {pd product} In this case (C2 on amd64) it's 48MB. > - Is there any limit for the code cache? In my tests where I increased > it, I set it to 128m (which is much too large, I assume, but worked). AFAICT no, there is not. You can set it as high as your architecture can address memory. -- Christian From Vladimir.Kozlov at Sun.COM Thu Jan 15 09:44:18 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 15 Jan 2009 09:44:18 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232032692.1361.74.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> Message-ID: <496F75F2.1070009@sun.com> The loop in match_into_reg() is simplified check for control nodes domination. You have to follow all merging paths above a region to check that they all dominate. And since it didn't reach m->in(0) we can not say that it dominates so we bailout. I wonder what are different control nodes. One is a loop head (region), I assume, and an other? And why AndI has control edge? AndI === 458 129 140 [[ 164 ]] Thanks, Vladimir Christian Thalinger wrote: > > On Tue, 2009-01-13 at 10:26 -0800, Vladimir Kozlov wrote: >> This code exists as far as history goes (1997), so no bugs or comments >> >> if( _shared[n->_idx] || // Shared; stop recursion >> // Also stop recursion if they have different Controls. >> // Slot 0 of constants is not really a Control. >> (control != n->in(0) && n->in(0) && !n->is_Con()) || >> // Finally, stop recursion if this a LoadNode and the root of >> // this tree is a StoreNode and the load & store have different >> // memories. >> ((mem!=(Node*)1) && n->is_Load() && n->in(LoadNode::Memory) != mem) ) { >> // Switch to a register-only opcode; this value must be in a register >> // and cannot be subsumed as part of a larger instruction. >> svec->DFA( n->ideal_reg(this), n ); > > Thank you Vladimir. As I currently do not understand all of that code I > can simple guess and try. > > I have to do two changes to get the loadUB matched for all cases in that > method: > > --- hotspot.35ae4dd6c27c/src/share/vm/opto/matcher.cpp 2009-01-15 16:12:29.748744167 +0100 > +++ /export/home/twisti/projects/openjdk/jdk7/hotspot-comp/hotspot/src/share/vm/opto/matcher.cpp 2009-01-15 16:12:24.732215699 +0100 > @@ -1252,7 +1252,8 @@ static bool match_into_reg( const Node * > uint j; > for( j=0; j if( x->is_Region() ) // Bail out at merge points > - return true; > + //return true; > + break; > x = x->in(0); > if( x == m->in(0) ) // Does 'control' post-dominate > break; // m->in(0)? If so, we can use it > @@ -1331,10 +1332,12 @@ Node *Matcher::Label_Root( const Node *n > // the current tree. If it finds any, that value is matched as a > // register operand. If not, then the normal matching is used. > if( match_into_reg(n, m, control, i, is_shared(m)) || > +#if 0 > // > // Stop recursion if this is LoadNode and the root of this tree is a > // StoreNode and the load & store have different memories. > ((mem!=(Node*)1) && m->is_Load() && m->in(MemNode::Memory) != mem) || > +#endif > // Can NOT include the match of a subtree when its memory state > // is used by any of the other subtrees > (input_mem == NodeSentinel) ) { > > Maybe the second patch is OK (but I'm not sure on that one too), but I > doubt the first one is correct. Can someone explain to me why we need > to bail out at merge points (as the comment states)? > > At least with these two changes I get the inner loop as follows: > > 130 B9: # B12 B10 <- B8 B10 Loop: B9-B10 inner stride: not constant main of N106 Freq: 10.9989 > 130 movslq R10, R11 # i2l > 133 movq R8, [rsp + #8] # spill > 138 movzbl RBX, [R8 + #24 + R10] # ubyte > 13e movw [R9 + #24 + R10 << #1], RBX # char/short > 144 movl RBP, R11 # spill > 147 addl RBP, #4 # int > 14a movslq R11, R11 # i2l > 14d movzbl R8, [R8 + #25 + R11] # ubyte > 153 movw [R9 + #26 + R11 << #1], R8 # char/short > 159 movq R10, [rsp + #8] # spill > 15e movzbl R10, [R10 + #27 + R11] # ubyte > 164 movq R8, [rsp + #8] # spill > 169 movzbl R8, [R8 + #26 + R11] # ubyte > 16f movw [R9 + #28 + R11 << #1], R8 # char/short > 175 movw [R9 + #30 + R11 << #1], R10 # char/short > 17b cmpl RBP, RCX > 17d jge,s B12 # loop end P=0.090918 C=97000.000000 > 17d > 17f B10: # B9 <- B9 Freq: 9.99894 > 17f movl R11, RBP # spill > 182 jmp,s B9 > > It's better than before but there's still optimization potential. > > -- Christian > From Christian.Thalinger at Sun.COM Thu Jan 15 10:00:20 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 15 Jan 2009 19:00:20 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <496F75F2.1070009@sun.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> Message-ID: <1232042420.1361.90.camel@localhost.localdomain> On Thu, 2009-01-15 at 09:44 -0800, Vladimir Kozlov wrote: > The loop in match_into_reg() is simplified check for > control nodes domination. You have to follow all > merging paths above a region to check that they all dominate. > And since it didn't reach m->in(0) we can not say that it dominates > so we bailout. > > I wonder what are different control nodes. One is a loop head (region), > I assume, and an other? And why AndI has control edge? > > AndI === 458 129 140 [[ 164 ]] Here are the nodes: 141 AndI === 458 129 140 [[ 164 ]] !orig=[377] !jvms: test::decode @ bci:4 test::bar @ bci:29 458 CountedLoop === 458 311 172 [[ 438 439 440 441 457 458 346 461 164 204 141 347 ]] inner stride: 4 main of N458 !orig=[359],[205],[184],[100] !jvms: test::bar @ bci:22 129 LoadB === 311 51 127 [[ 141 ]] @byte[int:>=0]:exact+any *, idx=4; #byte !jvms: test::bar @ bci:28 140 ConI === 0 [[ 141 217 268 347 439 441 ]] #int:255 164 StoreC === 458 346 162 141 [[ 295 461 ]] @char[int:>=0]:exact+any *, idx=5; Memory: @char[int:10]:NotNull:exact+any *, idx=5; !orig=[376] !jvms: test::bar @ bci:32 Did you know that AndI has a control edge from the node output above or from my previous posting? -- Christian From Vladimir.Kozlov at Sun.COM Thu Jan 15 10:51:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 15 Jan 2009 10:51:20 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232042420.1361.90.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> Message-ID: <496F85A8.3060609@sun.com> I looked on your previous post. Again there is no enough information. Is this graph produced after you changed something in C2? 311 is the loop's entry control so LoadB is placed outside the loop but AndI and StoreC is inside the loop. This makes no sense for this case. Christian, I would suggest to look on this loop before first unrolling/peeling. You may use visualizer to see how the graph evolves. Vladimir Christian Thalinger wrote: > On Thu, 2009-01-15 at 09:44 -0800, Vladimir Kozlov wrote: >> The loop in match_into_reg() is simplified check for >> control nodes domination. You have to follow all >> merging paths above a region to check that they all dominate. >> And since it didn't reach m->in(0) we can not say that it dominates >> so we bailout. >> >> I wonder what are different control nodes. One is a loop head (region), >> I assume, and an other? And why AndI has control edge? >> >> AndI === 458 129 140 [[ 164 ]] > > Here are the nodes: > > 141 AndI === 458 129 140 [[ 164 ]] !orig=[377] !jvms: test::decode @ bci:4 test::bar @ bci:29 > > 458 CountedLoop === 458 311 172 [[ 438 439 440 441 457 458 346 461 164 204 141 347 ]] inner stride: 4 main of N458 !orig=[359],[205],[184],[100] !jvms: test::bar @ bci:22 > 129 LoadB === 311 51 127 [[ 141 ]] @byte[int:>=0]:exact+any *, idx=4; #byte !jvms: test::bar @ bci:28 > 140 ConI === 0 [[ 141 217 268 347 439 441 ]] #int:255 > > 164 StoreC === 458 346 162 141 [[ 295 461 ]] @char[int:>=0]:exact+any *, idx=5; Memory: @char[int:10]:NotNull:exact+any *, idx=5; !orig=[376] !jvms: test::bar @ bci:32 > > Did you know that AndI has a control edge from the node output above or > from my previous posting? > > -- Christian > From John.Rose at Sun.COM Thu Jan 15 12:51:49 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 15 Jan 2009 12:51:49 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <496F85A8.3060609@sun.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> Message-ID: <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> The problem of delaying optimizations until the matcher is the optimizer (esp. loop opts) can push the graph into an unrecognizable shape. If control inputs are preventing the matcher's merge-up, perhaps they are fallout from loop opts or some other CFG change. Maybe we should bite the bullet and introduce an ideal node LoadUB for read-unsigned-8 (and maybe LoadUI for read-unsigned-32? -- we have LoadC for LoadUS; it could be renamed to LoadUS). If we rewrite LoadB/AndI pairs early to LoadUB, in Node::Ideal(), the optimization will be "in the bank" and later transformations cannot interfere with it. -- John On Jan 15, 2009, at 10:51 AM, Vladimir Kozlov wrote: > I looked on your previous post. > > Again there is no enough information. > Is this graph produced after you changed something in C2? > 311 is the loop's entry control so LoadB is placed > outside the loop but AndI and StoreC is inside the loop. > This makes no sense for this case. > > Christian, I would suggest to look on this loop before first > unrolling/peeling. > You may use visualizer to see how the graph evolves. From Vladimir.Kozlov at Sun.COM Thu Jan 15 16:39:43 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 15 Jan 2009 16:39:43 -0800 Subject: Request for reviews (XS): 6790209: server VM fails with assert(will_link,"_new: typeflow responsibility") Message-ID: <496FD74F.9070009@sun.com> http://webrev.invokedynamic.info/kvn/6790209/index.html Fixed 6790209: server VM fails with assert(will_link,"_new: typeflow responsibility") Problem: CI uses non-blocking system dictionary check by calling SystemDictionary::find() method which does not have the fix for reflection class loader (4474172) used by Interpreter to resolve a class in the method SystemDictionary::resolve_instance_class_or_null(). Solution: Add missing code. Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT, CTW, NSK testing (with -XX:CompileThreshold=2) From john.coomes at sun.com Fri Jan 16 00:13:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:13:50 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b43 for changeset 848e684279d2 Message-ID: <20090116081350.A8BB0DA51@hg.openjdk.java.net> Changeset: a395e3aac474 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/a395e3aac474 Added tag jdk7-b43 for changeset 848e684279d2 ! .hgtags From john.coomes at sun.com Fri Jan 16 00:15:56 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:15:56 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b43 for changeset 9cd740d48a48 Message-ID: <20090116081558.76653DA56@hg.openjdk.java.net> Changeset: 9803dac72540 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/9803dac72540 Added tag jdk7-b43 for changeset 9cd740d48a48 ! .hgtags From john.coomes at sun.com Fri Jan 16 00:20:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:20:14 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b43 for changeset 96fe28d4a913 Message-ID: <20090116082016.9F575DA5B@hg.openjdk.java.net> Changeset: b203df0741af Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/b203df0741af Added tag jdk7-b43 for changeset 96fe28d4a913 ! .hgtags From john.coomes at sun.com Fri Jan 16 00:22:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:22:25 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b43 for changeset 1ad2f51564db Message-ID: <20090116082227.56355DA60@hg.openjdk.java.net> Changeset: 344485a03674 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/344485a03674 Added tag jdk7-b43 for changeset 1ad2f51564db ! .hgtags From john.coomes at sun.com Fri Jan 16 00:27:18 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:27:18 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 53 new changesets Message-ID: <20090116083745.1D08DDA65@hg.openjdk.java.net> Changeset: 4e0e690373fc Author: wetmore Date: 2008-12-02 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4e0e690373fc 6778613: Update javax.crypto.Cipher.getMaxAllowedKeyLength to point to proper Appendix after doc reorg Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: a99a2d2f3249 Author: dfuchs Date: 2008-12-04 17:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a99a2d2f3249 6319823: new mbean register/unregister notification for groups of mbeans 6779698: Merge error caused duplicate example code in MBeanServerNotification Reviewed-by: emcmanus ! src/share/classes/javax/management/MBeanServerNotification.java Changeset: 87170fc5a587 Author: mchung Date: 2008-12-05 10:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/87170fc5a587 6764062: Revise usage of java.io.*.close Summary: Handle closing multiple open I/O streams in case close() throws IOException Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/servicetag/Util.java ! src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java Changeset: baa10242c544 Author: mchung Date: 2008-12-05 10:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/baa10242c544 6750389: The cpuManufactorer does not correctly recognized for Solaris 10 Summary: Fix the correct SMBIOS type (4) to obtain CPU manufacturer Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java Changeset: ea43ec07a878 Author: tbell Date: 2008-12-05 21:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ea43ec07a878 Merge Changeset: b4bf1806ee66 Author: emcmanus Date: 2008-12-09 12:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b4bf1806ee66 6774918: @NotificationInfo is ineffective on MBeans that cannot send notifications Reviewed-by: jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/NotificationInfo.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java Changeset: 95f828533592 Author: jfdenise Date: 2008-12-09 14:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/95f828533592 6501362: DescriptorSupport(String) could recognize "name=value" as well as XML format Reviewed-by: emcmanus ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java + test/javax/management/descriptor/DescriptorConstructorTest.java Changeset: 8d7117d71fc7 Author: jfdenise Date: 2008-12-09 15:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8d7117d71fc7 6250014: MBeanOperationInfo Descriptor field for exceptions Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java + test/javax/management/Introspector/ExceptionsDescriptorTest.java Changeset: f8c2f3b5c0ff Author: jfdenise Date: 2008-12-09 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f8c2f3b5c0ff 6675526: Define an Annotation to name registered MBeans Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java + src/share/classes/javax/management/ObjectNameTemplate.java + test/javax/management/Introspector/ObjectNameTemplateTest.java Changeset: ab4d12886aaf Author: jfdenise Date: 2008-12-09 16:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ab4d12886aaf 6450834: RFE: allow StandardMBean to call MBeanRegistration methods on its wrapped resource 6373143: MonitorNotification should have a public constructor Reviewed-by: emcmanus ! src/share/classes/javax/management/StandardMBean.java ! src/share/classes/javax/management/monitor/MonitorNotification.java + test/javax/management/monitor/InstantiateMonitorNotificationTest.java + test/javax/management/standardmbean/RegistrationTest.java Changeset: 3d822c99e3ab Author: jfdenise Date: 2008-12-09 16:26 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3d822c99e3ab 6287328: Add methods to StandardMBean to retrieve a method based on MBean{Attribute|Operation}Info Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/StandardMBean.java + test/javax/management/standardmbean/FindMethodTest.java Changeset: 6eec8be80bfe Author: sjiang Date: 2008-12-09 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6eec8be80bfe 6405891: MLet: could be improved to load a native lib Reviewed-by: emcmanus ! src/share/classes/javax/management/loading/MLet.java Changeset: 30239cf868b0 Author: sjiang Date: 2008-12-09 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/30239cf868b0 Merge Changeset: 0b1c7f982cc0 Author: emcmanus Date: 2008-12-09 18:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0b1c7f982cc0 6780803: Wrong parameter name in description of EventClient::addListeners() 6470295: Misleading exception message says context classloader when it isn't 6714954: Description of MBeanPermission checking in MBeanServer javadoc is inaccurate 6732037: Event Service spec needs more detail about Executor use 6740900: Specify that listeners invoked via SendNotification should not block 6778436: Typo in @NotificationInfos spec Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/javax/management/MBeanRegistration.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/FetchingEventRelay.java Changeset: 23738109351f Author: sjiang Date: 2008-12-09 18:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/23738109351f 6760712: Provide a connector server option that causes it not to prevent the VM from exiting Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java + test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java Changeset: 0dc9fc01e5d6 Author: sjiang Date: 2008-12-09 18:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0dc9fc01e5d6 Merge Changeset: 4951fee90769 Author: sjiang Date: 2008-12-09 19:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4951fee90769 6332907: Add ability for connector server to close individual connections Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/JMXConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java + test/javax/management/remote/mandatory/connectorServer/CloseConnectionTest.java Changeset: 61e73bc43e72 Author: dfuchs Date: 2008-12-09 20:20 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/61e73bc43e72 6768935: Clarify the behaviour of ObjectName pattern matching with regards to namespaces Reviewed-by: emcmanus ! 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/NamespaceDispatchInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.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/NamespaceInterceptor.java ! src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/namespace/JMXDomain.java ! src/share/classes/javax/management/namespace/JMXNamespacePermission.java ! src/share/classes/javax/management/namespace/JMXNamespaces.java ! src/share/classes/javax/management/namespace/package-info.java ! test/javax/management/namespace/LeadingSeparatorsTest.java ! test/javax/management/namespace/NullDomainObjectNameTest.java ! test/javax/management/namespace/NullObjectNameTest.java ! test/javax/management/namespace/QueryNamesTest.java Changeset: 7aa035fdd97d Author: sjiang Date: 2008-12-09 20:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7aa035fdd97d 6336980: NotificationBroadcasterSupport: to tell whether there are listeners and to do clear Reviewed-by: emcmanus ! src/share/classes/javax/management/NotificationBroadcasterSupport.java + test/javax/management/notification/SupportClearTest.java Changeset: 3f226f477d56 Author: sjiang Date: 2008-12-09 20:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3f226f477d56 Merge Changeset: c8db1ddbdba4 Author: emcmanus Date: 2008-12-10 11:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c8db1ddbdba4 6456269: Add a GenericMBeanException so clients don't have to have server's exception classes present Reviewed-by: jfdenise, dfuchs ! src/share/classes/javax/management/Descriptor.java + src/share/classes/javax/management/GenericMBeanException.java ! src/share/classes/javax/management/MBeanException.java + test/javax/management/interop/MBeanExceptionInteropTest.java + test/javax/management/openmbean/GenericMBeanExceptionTest.java Changeset: b89ba9a6d9a6 Author: sherman Date: 2008-12-10 14:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b89ba9a6d9a6 6642323: Speeding up Single Byte Decoders 6642328: Speeding up Single Byte Encoders Summary: re-implementation of mapping based sbcs charts Reviewed-by: alanb ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/IBM037.c2b + make/tools/CharsetMapping/IBM037.map + make/tools/CharsetMapping/IBM037.nr + make/tools/CharsetMapping/IBM1006.map + make/tools/CharsetMapping/IBM1025.c2b + make/tools/CharsetMapping/IBM1025.map + make/tools/CharsetMapping/IBM1025.nr + make/tools/CharsetMapping/IBM1026.c2b + make/tools/CharsetMapping/IBM1026.map + make/tools/CharsetMapping/IBM1026.nr + make/tools/CharsetMapping/IBM1046.map + make/tools/CharsetMapping/IBM1047.map + make/tools/CharsetMapping/IBM1097.map + make/tools/CharsetMapping/IBM1098.map + make/tools/CharsetMapping/IBM1112.c2b + make/tools/CharsetMapping/IBM1112.map + make/tools/CharsetMapping/IBM1112.nr + make/tools/CharsetMapping/IBM1122.c2b + make/tools/CharsetMapping/IBM1122.map + make/tools/CharsetMapping/IBM1122.nr + make/tools/CharsetMapping/IBM1123.c2b + make/tools/CharsetMapping/IBM1123.map + make/tools/CharsetMapping/IBM1123.nr + make/tools/CharsetMapping/IBM1124.map + make/tools/CharsetMapping/IBM1140.c2b + make/tools/CharsetMapping/IBM1140.map + make/tools/CharsetMapping/IBM1141.c2b + make/tools/CharsetMapping/IBM1141.map + make/tools/CharsetMapping/IBM1142.c2b + make/tools/CharsetMapping/IBM1142.map + make/tools/CharsetMapping/IBM1143.c2b + make/tools/CharsetMapping/IBM1143.map + make/tools/CharsetMapping/IBM1144.c2b + make/tools/CharsetMapping/IBM1144.map + make/tools/CharsetMapping/IBM1145.c2b + make/tools/CharsetMapping/IBM1145.map + make/tools/CharsetMapping/IBM1146.c2b + make/tools/CharsetMapping/IBM1146.map + make/tools/CharsetMapping/IBM1147.c2b + make/tools/CharsetMapping/IBM1147.map + make/tools/CharsetMapping/IBM1148.c2b + make/tools/CharsetMapping/IBM1148.map + make/tools/CharsetMapping/IBM1149.c2b + make/tools/CharsetMapping/IBM1149.map + make/tools/CharsetMapping/IBM273.c2b + make/tools/CharsetMapping/IBM273.map + make/tools/CharsetMapping/IBM273.nr + make/tools/CharsetMapping/IBM277.c2b + make/tools/CharsetMapping/IBM277.map + make/tools/CharsetMapping/IBM277.nr + make/tools/CharsetMapping/IBM278.c2b + make/tools/CharsetMapping/IBM278.map + make/tools/CharsetMapping/IBM278.nr + make/tools/CharsetMapping/IBM280.c2b + make/tools/CharsetMapping/IBM280.map + make/tools/CharsetMapping/IBM280.nr + make/tools/CharsetMapping/IBM284.c2b + make/tools/CharsetMapping/IBM284.map + make/tools/CharsetMapping/IBM284.nr + make/tools/CharsetMapping/IBM285.c2b + make/tools/CharsetMapping/IBM285.map + make/tools/CharsetMapping/IBM285.nr + make/tools/CharsetMapping/IBM297.c2b + make/tools/CharsetMapping/IBM297.map + make/tools/CharsetMapping/IBM297.nr + make/tools/CharsetMapping/IBM420.c2b + make/tools/CharsetMapping/IBM420.map + make/tools/CharsetMapping/IBM420.nr + make/tools/CharsetMapping/IBM424.c2b + make/tools/CharsetMapping/IBM424.map + make/tools/CharsetMapping/IBM424.nr + make/tools/CharsetMapping/IBM437.map + make/tools/CharsetMapping/IBM500.c2b + make/tools/CharsetMapping/IBM500.map + make/tools/CharsetMapping/IBM500.nr + make/tools/CharsetMapping/IBM737.map + make/tools/CharsetMapping/IBM775.map + make/tools/CharsetMapping/IBM838.c2b + make/tools/CharsetMapping/IBM838.map + make/tools/CharsetMapping/IBM838.nr + make/tools/CharsetMapping/IBM850.map + make/tools/CharsetMapping/IBM852.map + make/tools/CharsetMapping/IBM855.map + make/tools/CharsetMapping/IBM856.map + make/tools/CharsetMapping/IBM857.map + make/tools/CharsetMapping/IBM858.map + make/tools/CharsetMapping/IBM860.map + make/tools/CharsetMapping/IBM861.map + make/tools/CharsetMapping/IBM862.map + make/tools/CharsetMapping/IBM863.map + make/tools/CharsetMapping/IBM864.map + make/tools/CharsetMapping/IBM865.map + make/tools/CharsetMapping/IBM866.map + make/tools/CharsetMapping/IBM868.map + make/tools/CharsetMapping/IBM869.map + make/tools/CharsetMapping/IBM870.c2b + make/tools/CharsetMapping/IBM870.map + make/tools/CharsetMapping/IBM870.nr + make/tools/CharsetMapping/IBM871.c2b + make/tools/CharsetMapping/IBM871.map + make/tools/CharsetMapping/IBM871.nr + make/tools/CharsetMapping/IBM874.map + make/tools/CharsetMapping/IBM874.nr + make/tools/CharsetMapping/IBM875.c2b + make/tools/CharsetMapping/IBM875.map + make/tools/CharsetMapping/IBM875.nr + make/tools/CharsetMapping/IBM918.c2b + make/tools/CharsetMapping/IBM918.map + make/tools/CharsetMapping/IBM918.nr + make/tools/CharsetMapping/IBM921.map + make/tools/CharsetMapping/IBM922.map + make/tools/CharsetMapping/ISO_8859_11.map + make/tools/CharsetMapping/ISO_8859_13.map + make/tools/CharsetMapping/ISO_8859_15.map + make/tools/CharsetMapping/ISO_8859_2.map + make/tools/CharsetMapping/ISO_8859_3.map + make/tools/CharsetMapping/ISO_8859_4.map + make/tools/CharsetMapping/ISO_8859_5.map + make/tools/CharsetMapping/ISO_8859_6.map + make/tools/CharsetMapping/ISO_8859_7.map + make/tools/CharsetMapping/ISO_8859_8.map + make/tools/CharsetMapping/ISO_8859_9.map + make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/KOI8_R.map + make/tools/CharsetMapping/KOI8_U.map + make/tools/CharsetMapping/MS1250.map + make/tools/CharsetMapping/MS1251.map + make/tools/CharsetMapping/MS1252.map + make/tools/CharsetMapping/MS1253.map + make/tools/CharsetMapping/MS1254.map + make/tools/CharsetMapping/MS1255.map + make/tools/CharsetMapping/MS1256.map + make/tools/CharsetMapping/MS1257.map + make/tools/CharsetMapping/MS1258.map + make/tools/CharsetMapping/MS874.map + make/tools/CharsetMapping/MacArabic.map + make/tools/CharsetMapping/MacCentralEurope.map + make/tools/CharsetMapping/MacCroatian.map + make/tools/CharsetMapping/MacCyrillic.map + make/tools/CharsetMapping/MacDingbat.map + make/tools/CharsetMapping/MacGreek.map + make/tools/CharsetMapping/MacHebrew.map + make/tools/CharsetMapping/MacIceland.map + make/tools/CharsetMapping/MacRoman.map + make/tools/CharsetMapping/MacRomania.map + make/tools/CharsetMapping/MacSymbol.map + make/tools/CharsetMapping/MacThai.map + make/tools/CharsetMapping/MacTurkish.map + make/tools/CharsetMapping/MacUkraine.map + make/tools/CharsetMapping/SingleByte-X.java + make/tools/CharsetMapping/TIS_620.map + make/tools/CharsetMapping/extsbcs + make/tools/CharsetMapping/sbcs ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java + make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/sun/io/ByteToCharCp850.java ! src/share/classes/sun/io/CharToByteJIS0201.java ! src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java + src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: 18ab3173fcec Author: tbell Date: 2008-12-19 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/18ab3173fcec Merge ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java Changeset: 94bcd3503668 Author: bae Date: 2008-07-25 14:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/94bcd3503668 6687968: PNGImageReader leaks native memory through an Inflater. Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java Changeset: e62bc7b05b8a Author: igor Date: 2008-08-04 18:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e62bc7b05b8a 4356282: RFE: T2K should be used to rasterize CID/CFF fonts Reviewed-by: bae, prr ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/windows/native/sun/font/fontpath.c Changeset: a56641c1f54e Author: tdv Date: 2008-08-04 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a56641c1f54e 6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque destination Reviewed-by: campbell ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java Changeset: b2413144d908 Author: tdv Date: 2008-08-04 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b2413144d908 6717988: D3D: rendering problems with JConsole on [Nvidia FX 5200] Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 06a02adcba4e Author: tdv Date: 2008-08-05 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/06a02adcba4e 6733718: test /java/awt/FullScreen/UninitializedDisplayModeChangeTest/ fails Reviewed-by: igor + test/java/awt/FullScreen/UninitializedDisplayModeChangeTest/DisplayModeChanger.java Changeset: 15be3e891e97 Author: jgodinez Date: 2008-08-07 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/15be3e891e97 6731937: javax/print/CheckDupFlavor.java fails Reviewed-by: campbell, tdv ! src/solaris/classes/sun/print/IPPPrintService.java + test/javax/print/CheckDupFlavor.java Changeset: 3c4561f955f3 Author: lana Date: 2008-08-07 22:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3c4561f955f3 Merge - 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/javax/management/ToQueryString.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/solaris/classes/sun/print/IPPPrintService.java - test/javax/management/Introspector/LegacyIntrospectorTest.java Changeset: 3d3ef4073bdd Author: jgodinez Date: 2008-08-19 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3d3ef4073bdd 6731826: race condition in UnixPrintServiceLookup Reviewed-by: campbell, tdv ! src/solaris/classes/sun/print/IPPPrintService.java + test/javax/print/TestRaceCond.java Changeset: cd88b4ad7f25 Author: tdv Date: 2008-08-28 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cd88b4ad7f25 6739267: D3D/OGL: add missing ThreeByteBgr to texture upload blit loop Reviewed-by: campbell, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h Changeset: b8f91ea2fb33 Author: tdv Date: 2008-09-12 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b8f91ea2fb33 6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal Reviewed-by: prr, tdv Contributed-by: rkennke at kennke.org ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: 41ff3f84cd96 Author: prr Date: 2008-09-24 11:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/41ff3f84cd96 6751621: TextLayout.getBounds() doesn't account for strike through Reviewed-by: igor, dougfelt ! src/share/classes/sun/font/Decoration.java ! src/share/classes/sun/font/Underline.java + test/java/awt/font/TextLayout/DecorationBoundsTest.java Changeset: 3bc4d79d8123 Author: tdv Date: 2008-10-09 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3bc4d79d8123 6749060: LCD AA text rendered incorrectly when destination is non opaque (sw pipeline only) Reviewed-by: campbell, prr ! src/share/classes/sun/java2d/SurfaceData.java ! test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java Changeset: 9a6094d65d28 Author: jgodinez Date: 2008-10-13 15:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9a6094d65d28 6732647: isAttributeValueSupported() is not consistant with getSupportedValues() for Copies, TEXT flavor Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintService.java ! test/javax/print/attribute/PSCopiesFlavorTest.java Changeset: 22d965ed3b93 Author: prr Date: 2008-10-16 06:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/22d965ed3b93 6751616: outline for underline in TextLayout with underline is off rasterized underline Reviewed-by: dougfelt, igor ! src/share/classes/sun/font/Decoration.java + test/java/awt/font/TextLayout/UnderlinePositionTest.java Changeset: 665850610378 Author: lana Date: 2008-10-20 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/665850610378 Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README - make/java/nio/spp.sh - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java - src/share/classes/java/nio/channels/package.html - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - 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 ! src/share/classes/sun/swing/SwingUtilities2.java - 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/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/javavm/include/typedefs_md.h - 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 - src/windows/javavm/include/typedefs_md.h - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: 452c58b2f533 Author: tdv Date: 2008-10-21 08:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/452c58b2f533 6755274: 6u10b33 2d tests fails on sles10x64 with jvm crash Reviewed-by: campbell ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java Changeset: c739feb28074 Author: prr Date: 2008-10-28 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c739feb28074 6764543: SIGSEGV in libfontconfig.so starting from jdk7b33 Reviewed-by: campbell, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: 594c52582b21 Author: tdv Date: 2008-10-28 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/594c52582b21 6764257: D3D/OGL: color is not reset properly after save/restoreState() [RSL] Reviewed-by: campbell ! src/share/classes/sun/java2d/pipe/BufferedContext.java + test/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java Changeset: 9cdababf6179 Author: igor Date: 2008-10-29 01:52 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9cdababf6179 6761856: OpenJDK: vertical text metrics may be significanly different from those returned by Sun JDK Reviewed-by: bae, prr ! src/share/native/sun/font/freetypeScaler.c ! test/java/awt/font/TextLayout/TextLayoutBounds.java Changeset: 3a9d06af8830 Author: bae Date: 2008-11-01 20:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3a9d06af8830 6541476: PNG imageio plugin incorrectly handles iTXt chunk Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/ITXtTest.java Changeset: 8eb24fc88242 Author: tdv Date: 2008-11-18 17:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8eb24fc88242 6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage Reviewed-by: campbell, flar ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp + test/sun/java2d/DirectX/OpaqueImageToSurfaceBlitTest/OpaqueImageToSurfaceBlitTest.java Changeset: 3fea7e660a8f Author: tdv Date: 2008-11-18 18:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3fea7e660a8f 6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp ! src/windows/native/sun/java2d/d3d/D3DContext.cpp Changeset: be363ea85cb4 Author: jgodinez Date: 2008-11-25 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/be363ea85cb4 6653384: Variable "initialized" in class CUPSPrinter is static by mistake Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PrinterJob/GetMediasTest.java Changeset: c8eea39734e8 Author: jgodinez Date: 2008-12-04 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c8eea39734e8 6587245: Import declaration not used in sun.print.* Reviewed-by: tdv, prr ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDocPrintService.java ! src/share/classes/javax/print/PrintServiceLookup.java ! src/share/classes/javax/print/attribute/URISyntax.java ! src/share/classes/javax/print/event/PrintServiceAttributeEvent.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PrintJobAttributeException.java ! src/share/classes/sun/print/SunMinMaxPage.java ! src/share/classes/sun/print/SunPageSelection.java Changeset: 15435c60c751 Author: tdv Date: 2008-12-04 11:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/15435c60c751 6708580: Java applications slow when EXA enabled Reviewed-by: prr, tdv Contributed-by: ceisserer ! make/sun/awt/mapfile-mawt-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: b0c446712fae Author: jgodinez Date: 2008-12-08 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b0c446712fae 6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown Reviewed-by: tdv, prr ! src/share/classes/java/awt/print/PrinterJob.java Changeset: b163d898f83f Author: tdv Date: 2008-12-08 17:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b163d898f83f 6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red Reviewed-by: campbell ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: bf5dd3128c6a Author: lana Date: 2008-12-08 19:49 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bf5dd3128c6a Merge Changeset: 50c67678b0d1 Author: lana Date: 2009-01-06 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/50c67678b0d1 Merge ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 8dcc06d43798 Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8dcc06d43798 Added tag jdk7-b43 for changeset 50c67678b0d1 ! .hgtags From john.coomes at sun.com Fri Jan 16 00:47:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 16 Jan 2009 08:47:31 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 4 new changesets Message-ID: <20090116084738.B3A54DA6A@hg.openjdk.java.net> Changeset: 8db0c5fd6e99 Author: jjg Date: 2008-12-02 14:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8db0c5fd6e99 6778638: javadoc regression tests require tabs Reviewed-by: darcy ! test/com/sun/javadoc/testSourceTab/DoubleTab/C.java ! test/com/sun/javadoc/testSourceTab/SingleTab/C.java ! test/com/sun/javadoc/testSourceTab/TestSourceTab.java Changeset: 4efd44aa85ff Author: tbell Date: 2008-12-05 21:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/4efd44aa85ff Merge Changeset: e2f8f6daee9d Author: tbell Date: 2008-12-19 10:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e2f8f6daee9d Merge Changeset: 05b47447cbcf Author: xdono Date: 2009-01-15 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/05b47447cbcf Added tag jdk7-b43 for changeset e2f8f6daee9d ! .hgtags From Christian.Thalinger at Sun.COM Fri Jan 16 06:29:04 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 16 Jan 2009 15:29:04 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> Message-ID: <1232116144.1361.93.camel@localhost.localdomain> On Thu, 2009-01-15 at 12:51 -0800, John Rose wrote: > The problem of delaying optimizations until the matcher is the > optimizer (esp. loop opts) can push the graph into an unrecognizable > shape. If control inputs are preventing the matcher's merge-up, > perhaps they are fallout from loop opts or some other CFG change. > > Maybe we should bite the bullet and introduce an ideal node LoadUB > for read-unsigned-8 (and maybe LoadUI for read-unsigned-32? -- we > have LoadC for LoadUS; it could be renamed to LoadUS). > > If we rewrite LoadB/AndI pairs early to LoadUB, in Node::Ideal(), the > optimization will be "in the bank" and later transformations cannot > interfere with it. Should I try to make that changes? -- Christian From mail at nmichael.de Fri Jan 16 09:44:36 2009 From: mail at nmichael.de (Nicolas Michael) Date: Fri, 16 Jan 2009 18:44:36 +0100 Subject: Code Cache, Compilation & Inlining In-Reply-To: <1232011677.1361.62.camel@localhost.localdomain> References: <1232011677.1361.62.camel@localhost.localdomain> Message-ID: <4970C784.9040805@nmichael.de> Hi Christian, thanks a lot for this info! On our system, I get the following output with a Java 7 debug build: java -Xprintflags | grep CodeCacheSize uintx InitialCodeCacheSize = 1572864 {pd product} uintx ReservedCodeCacheSize = 33554432 {pd product} This seems to roughly match our perfdata dumps that I automatically collect with each testrun. With the default code cache size, I have the following values after C2 stopped compiling because of a full code cache: sun.ci.nmethodCodeSize = 10727808 sun.ci.nmethodSize = 30215640 sun.ci.osrBytes = 26182 sun.ci.osrCompiles = 32 sun.ci.osrTime = 5016824306 sun.ci.standardBytes = 2292726 sun.ci.standardCompiles = 7550 sun.ci.standardTime = 578065415777 sun.ci.threads = 2 sun.ci.totalBailouts = 3 sun.ci.totalCompiles = 7582 sun.ci.totalInvalidates = 0 Which of these values fill up the 32 MB code cache? sun.ci.nmethodSize + sun.ci.osrBytes + sun.ci.standardBytes = 32534548 ?? What is "sun.ci.nmethodCodeSize", though? That's 10 MB -- if this came on top, it would exceed the size of the code cache. For a testrun with -XX:ReservedCodeCacheSize=128m I got the following values which indicate that the default 32 MB was just slightly too small and something like 48 MB would certainly be more than enough: sun.ci.nmethodCodeSize = 12793696 sun.ci.nmethodSize = 36462344 sun.ci.osrBytes = 26469 sun.ci.osrCompiles = 39 sun.ci.osrTime = 7769266817 sun.ci.standardBytes = 2740711 sun.ci.standardCompiles = 8997 sun.ci.standardTime = 754631615591 sun.ci.threads = 2 sun.ci.totalBailouts = 2 sun.ci.totalCompiles = 9036 sun.ci.totalInvalidates = 0 So thanks again for your help!! Anyone who could probably help me with the other issues about deoptimization, interpreted code and inlining? Thanks, Nick. Christian Thalinger schrieb: > On Tue, 2009-01-13 at 11:45 +0000, Nicolas Michael wrote: >> My questions are: >> - How large is the code cache per default? > > The reserved code cache size depends on the architecture and the > compiler used. With a debug build you can use the -Xprintflags switch > to get the default size: > > $ java -Xprintflags | grep CodeCacheSize > uintx InitialCodeCacheSize = 2555904 {pd product} > uintx ReservedCodeCacheSize = 50331648 {pd product} > > In this case (C2 on amd64) it's 48MB. > >> - Is there any limit for the code cache? In my tests where I increased >> it, I set it to 128m (which is much too large, I assume, but worked). > > AFAICT no, there is not. You can set it as high as your architecture > can address memory. > > -- Christian > > From Vladimir.Kozlov at Sun.COM Fri Jan 16 11:31:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 16 Jan 2009 11:31:20 -0800 Subject: Request for reviews (XXXS): 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Message-ID: <4970E088.2090001@sun.com> http://webrev.invokedynamic.info/kvn/6794939/index.html Fixed 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Problem: Typo in the assert in TypeKlassPtr::cast_to_ptr_type(). Solution: Fix the assert's check to _base == KlassPtr. Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT From John.Rose at Sun.COM Fri Jan 16 12:29:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 16 Jan 2009 12:29:16 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232116144.1361.93.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> Message-ID: <0F136F86-04C5-4AE8-9E3D-25C87D43F982@Sun.COM> Yes. It's a valid ideal node type, not hardware specific and useful to optimizations. IMO, matcher-based optimizations are nice-to-haves, not requirements. If you have a optimization you really need, make it in the ideal graph. This is such a case. (As an aside, I would like to see someone dig into the matcher, and record the (re-)learning process on http://wikis.sun.com/display/ HotSpotInternals .) -- John On Jan 16, 2009, at 6:29 AM, Christian Thalinger wrote: > On Thu, 2009-01-15 at 12:51 -0800, John Rose wrote: >> The problem of delaying optimizations until the matcher is the >> optimizer (esp. loop opts) can push the graph into an unrecognizable >> shape. If control inputs are preventing the matcher's merge-up, >> perhaps they are fallout from loop opts or some other CFG change. >> >> Maybe we should bite the bullet and introduce an ideal node LoadUB >> for read-unsigned-8 (and maybe LoadUI for read-unsigned-32? -- we >> have LoadC for LoadUS; it could be renamed to LoadUS). >> >> If we rewrite LoadB/AndI pairs early to LoadUB, in Node::Ideal(), the >> optimization will be "in the bank" and later transformations cannot >> interfere with it. > > Should I try to make that changes? > > -- Christian > From vladimir.kozlov at sun.com Fri Jan 16 13:56:21 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 16 Jan 2009 21:56:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6790209: server VM fails with assert(will_link, "_new: typeflow responsibility") Message-ID: <20090116215623.382AFDAF7@hg.openjdk.java.net> Changeset: 48bb4a49b7ac Author: kvn Date: 2009-01-16 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/48bb4a49b7ac 6790209: server VM fails with assert(will_link,"_new: typeflow responsibility") Summary: Add missing code for reflection class loader in SystemDictionary::find(). Reviewed-by: never, jrose ! src/share/vm/classfile/systemDictionary.cpp From Ulf.Zibis at gmx.de Mon Jan 19 06:41:49 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 19 Jan 2009 15:41:49 +0100 Subject: hg: jdk7/tl/jdk: 6642323: Speeding up Single Byte Decoders; ... In-Reply-To: <1232363156.18371.176.camel@localhost.localdomain> References: <497217B4.3000307@gmx.de> <1232218297.7455.9.camel@localhost.localdomain> <49723047.9000206@gmx.de> <1232222998.7455.20.camel@localhost.localdomain> <49724B41.6070104@gmx.de> <1232232491.7455.26.camel@localhost.localdomain> <49728D7D.9050009@gmx.de> <1232363156.18371.176.camel@localhost.localdomain> Message-ID: <4974912D.5030904@gmx.de> Hi Christian, thanks for your numbers from your tests. The magic inlining deceleration disapeared on your machine. Do you have used -client mode, because my values, you have taken for compare have been from -client mode. O:-) I also played around with warm up: time for warm up 1: 3539 ms time for warm up 2: 3110 ms time for warm up 3: 2697 ms time for warm up 4: 2703 ms time for map[a & 0xFF]: 3561 ms time for map[a + 0x80]: 3510 ms time for inlined map[a & 0xFF]: 3563 ms time for inlined map[a + 0x80]: 3470 ms test loops ./. warm up: 1.3042054 *Surprise*: testloops are much slower than warm up. Maybe it's the overheating effect on my mobile CPU. Can you check on your system? See my updated benchmark code at the end of mail ... -Ulf Am 19.01.2009 12:05, Christian Thalinger schrieb: > On Sun, 2009-01-18 at 03:01 +0100, Ulf Zibis wrote: > >> My results by JDK 1.7.0 ea b43 : >> >> time for 1st warm up: 3091 ms >> time for 2nd warm up: 3100 ms >> time for map[a & 0xFF]: 7207 ms >> time for map[a + 0x80]: 7225 ms >> time for inlined map[a & 0xFF]: 8100 ms >> time for inlined map[a + 0x80]: 8084 ms >> > > Vanilla HotSpot: > > time for 1st warm up: 622 ms > time for 2nd warm up: 586 ms > time for map[a & 0xFF]: 1460 ms > time for map[a + 0x80]: 1456 ms > time for inlined map[a & 0xFF]: 1461 ms > time for inlined map[a + 0x80]: 1454 ms > > Hotspot w/ unsigned-byte loads: > > time for 1st warm up: 680 ms > time for 2nd warm up: 641 ms > time for map[a & 0xFF]: 1537 ms > time for map[a + 0x80]: 1468 ms > time for inlined map[a & 0xFF]: 1525 ms > time for inlined map[a + 0x80]: 1462 ms > > For technical details I will reply on hotspot-compiler-dev. > > -- Christian > > > package build.tools.charsetmapping; /** * * @author Ulf Zibis */ public class DecoderBenchmark { public static void main(String[] args) { foo(); } static final char[] map = new char[256]; static final byte[] src = new byte[16384]; // be aware of exceeding CPU cache static final char[] dst = new char[16384]; // be aware of exceeding CPU cache static final int LOOPS = 100; static final int OUTER_LOOPS = 1000; static final int WARMUP_LOOPS = 4; static final float WARMUP_RATIO = 0.25f; static void foo() { // fill arrays, to force real memory load and prohibit HotSpot from just incrementing // (maybe candidate for sophisticated HotSpot optimization ;-) ) for (int i=0; i References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <0F136F86-04C5-4AE8-9E3D-25C87D43F982@Sun.COM> Message-ID: <1232376193.18371.394.camel@localhost.localdomain> On Fri, 2009-01-16 at 12:29 -0800, John Rose wrote: > Yes. It's a valid ideal node type, not hardware specific and useful > to optimizations. As I've already written on hotspot-dev, the optimization works but it's generally not faster. I'm not sure yet why this is the case, as the new code is denser. Maybe both codes get translated to the same micro-ops, but then the performance should be at least equal. The following example is with my changes (Intel Core2 Duo T9300 @ 2.5GHz): time for map[a & 0xFF]: 1525 ms time for map[a + 0x80]: 1461 ms The first one boils down to: 0xfffffd7ffa3029d2: movzbl 0x19(%r10),%r10d 0xfffffd7ffa3029d7: movzwl 0x18(%r14,%r10,2),%r10d ;*caload 0xfffffd7ffa3029dd: mov %r10w,0x1a(%rbp,%rdi,2) ;*castore and the second to: 0xfffffd7ffa302b24: movsbl 0x19(%r13,%rdi,1),%r10d 0xfffffd7ffa302b4e: movslq %r10d,%r10 0xfffffd7ffa302b51: movzwl 0x118(%r14,%r10,2),%r10d ;*caload 0xfffffd7ffa302b5a: mov %r10w,0x1a(%rbp,%rdi,2) ;*castore Maybe out-of-order execution and micro-ops optimizations (I don't know if there are any in an Intel CPU) can combine movsbl and movslq to one micro-op, but still, both variants should have the same performance. Generating movzbq instead of movzbl gives: time for map[a & 0xFF]: 1533 ms 0xfffffd7ffa303312: movzbq 0x19(%r10),%r10 0xfffffd7ffa303317: movzwl 0x18(%r14,%r10,2),%r10d ;*caload 0xfffffd7ffa30331d: mov %r10w,0x1a(%rbp,%rdi,2) ;*castore However, I think we should integrate my changes as it opens up the possibility for new optimizations more easily, e.g. superword. The unrolled loop could then use a code sequence like: pxor xmm7, xmm7 movdqa xmm1, xmm0 ; copy source punpcklbw xmm0, xmm7 ; unpack the 8 low-end bytes ; into 8 zero-extended 16-bit words punpckhbw xmm1, xmm7 ; unpack the 8 high-end bytes ; into 8 zero-extended 16-bit words Processing 8 or 16 values at once. And that should definitely be faster... -- Christian From Christian.Thalinger at Sun.COM Mon Jan 19 09:37:58 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Jan 2009 18:37:58 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232376193.18371.394.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <0F136F86-04C5-4AE8-9E3D-25C87D43F982@Sunn.COM> <1232376193.18371.394.camel@localhost.localdomain> Message-ID: <1232386678.18371.593.camel@localhost.localdomain> On Mon, 2009-01-19 at 15:43 +0100, Christian Thalinger wrote: > As I've already written on hotspot-dev, the optimization works but it's > generally not faster. On i486 things are looking much better with unsigned-byte loads: time for map[a & 0xFF]: 2510 ms time for map[a + 0x80]: 1875 ms vs. time for map[a & 0xFF]: 2102 ms time for map[a + 0x80]: 1870 ms This is a 20% speedup. But it's still slower than the +128 trick. The reason for this seems to be that the generated code is very different. When using unsigned-byte loads the values are loaded in a burst and stored in temporary locations, like on amd64. Unfortunately (or obviously) these temporaries are on the stack: 0xf90d8b5a: movzbl 0x12(%edi),%ecx 0xf90d8b5e: mov %ecx,0x18(%esp) 0xf90d8b62: movzbl 0x11(%edi),%ecx 0xf90d8b66: mov %ecx,0x1c(%esp) 0xf90d8b6a: movzbl 0x10(%edi),%ecx 0xf90d8b6e: mov %ecx,0x24(%esp) 0xf90d8b72: movzbl 0xf(%edi),%ecx 0xf90d8b76: mov %ecx,0x28(%esp) 0xf90d8b7a: movzbl 0xe(%edi),%ecx 0xf90d8b7e: mov %ecx,0x2c(%esp) 0xf90d8b82: movzbl 0xd(%edi),%ecx 0xf90d8b86: mov %ecx,0x34(%esp) And later loaded again: 0xf90d8b98: mov 0x34(%esp),%ecx 0xf90d8b9c: movzwl 0xc(%ebx,%ecx,2),%edi ;*caload This is done for all 8 unrolled loops. While the +128 code is more interleaved and uses a temporary location only for 4 of the 8 unrolled loops. The other 4 are using: 0xf90d8c8d: movsbl 0xe(%esi,%edi,1),%eax ... 0xf90d8cac: movzwl 0x10c(%ebx,%eax,2),%eax ;*caload 0xf90d8cb4: mov %ax,0x10(%ebp,%edi,2) ;*castore Maybe someone can explain to me why the generated code is so different? -- Christian From Christian.Thalinger at Sun.COM Mon Jan 19 10:39:12 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 19 Jan 2009 19:39:12 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232376193.18371.394.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <0F136F86-04C5-4AE8-9E3D-25C87D43F982@Sunn.COM> <1232376193.18371.394.camel@localhost.localdomain> Message-ID: <1232390352.18371.659.camel@localhost.localdomain> On Mon, 2009-01-19 at 15:43 +0100, Christian Thalinger wrote: > However, I think we should integrate my changes as it opens up the > possibility for new optimizations more easily, e.g. superword. The > unrolled loop could then use a code sequence like: > > pxor xmm7, xmm7 > movdqa xmm1, xmm0 ; copy source > punpcklbw xmm0, xmm7 ; unpack the 8 low-end bytes > ; into 8 zero-extended 16-bit words > punpckhbw xmm1, xmm7 ; unpack the 8 high-end bytes > ; into 8 zero-extended 16-bit words > > Processing 8 or 16 values at once. And that should definitely be > faster... ...but in this special decoder example, that one could only be applied for the non-map case. -- Christian From John.Rose at Sun.COM Tue Jan 20 00:13:27 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 20 Jan 2009 00:13:27 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232386678.18371.593.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> Message-ID: On Jan 19, 2009, at 9:37 AM, Christian Thalinger wrote: > Maybe someone can explain to me why the generated code is so > different? You have observed a common traffic jam of loads at the top of an unrolled loop. That happens because, when generating a CFG from the sea of nodes, we allow load operations to float upward in the graph (toward earlier points). That means they all get scheduled at the top of the loop body. This is valid, and it usually makes sense on machines with lots of registers, but it is kind of dumb when the number of loaded values is larger than the number of available temp registers. But we can't measure register pressure at the point the CFG is built. It's the typical NP-hard chicken-and-egg problem, of needing a CFG to build a register allocation, but needing a register allocation to make a good CFG assignment. Years ago we decided to led the loads float up, and assume that modern hardware would supply the temp. registers and/or stack caches. It would be more graceful to throttle the load placement a little more (e.g., to try to reduce load-to-last-use distance). But this seems to be a medium-large project, and there have always been more pressing matters to deal with. I can't say off-hand why the x+0x80 version schedules the loads better. The +0x80 part probably gets subsumed into the index ranges which are split in complicated ways (as I mentioned earlier). I have no idea why the signed loads (feeding the +0x80 ops) would trickle downward in the graph compared with the unsigned loads bouncing up to the loop top. This might be a case where PrintOptoAssembly would supply a missing clue; the ideal graph visualizer would be even better. Maybe there are "invisible" (non-coding) nodes which participate in the CFG and accidentally prevent the signed loads from rising. Or maybe the heuristics are just rolling opposite ways on similar but slightly different inputs; this also is typical of NP- hard algorithms. -- John From John.Rose at Sun.COM Tue Jan 20 02:53:16 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 20 Jan 2009 02:53:16 -0800 Subject: for review (XXL): 6655638 method handles for invokedynamic References: Message-ID: <2306E419-8BB4-48CB-94F0-5B91B8112385@sun.com> This is part of the JVM side of the JSR 292 Reference Implementation. It should have no effect on application execution, unless one of the new flags is turned on (chiefly -XX: +MethodHandleSupport). Present limitations: - It works only on x86/32. (No sparc, compressed oops, cpp interpreter.) - There are no compiler optimizations. - It is young code. There are bugs. But only when a new flag is turned on. This review is for contents of meth.patch, to be pushed from mlvm to http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot . Here is the webrev for this review: http://webrev.invokedynamic.info/jrose/6655638.meth/ Here is the mlvm patch where the code currently lives: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/meth.patch An earlier version of these changes pass JPRT; it is expected that at most minor tweaks will be needed to push it through again. Even though they are large, the changes should also pass a simple visual inspection, since all substantially new control paths are guarded by tests of the new flags. Please give it a look. -- John P.S. Here are some relevant conversations about method handles and invokedynamic: http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-January/ 000321.html http://blogs.sun.com/jrose/entry/international_invokedynamic_day http://blogs.sun.com/dannycoward/entry/firing_up_the_engines_for http://groups.google.com/group/jvm-languages/browse_thread/thread/ a4b8a616eb987ca8 P.P.S. The proposed JDK changes are independent. At present, you can find them here, in patch and webrev formats: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/raw-file/tip/ meth.proj.patch http://webrev.invokedynamic.info/jrose/6655638.meth.proj/ From Ulf.Zibis at gmx.de Tue Jan 20 04:30:22 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 20 Jan 2009 13:30:22 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> Message-ID: <4975C3DE.8050109@gmx.de> Hi, I'm much impressed, how sophisticated HotSpot optimizer is, and that there are some guys looking deeper to find the source of the unsigned load deceleration. I'll keep my fingers crossed for you finding out the mystery, so we can get rid of the +128 trick. What does "NP-hard" mean? -Ulf Am 20.01.2009 09:13, John Rose schrieb: > On Jan 19, 2009, at 9:37 AM, Christian Thalinger wrote: > >> Maybe someone can explain to me why the generated code is so different? > > You have observed a common traffic jam of loads at the top of an > unrolled loop. That happens because, when generating a CFG from the > sea of nodes, we allow load operations to float upward in the graph > (toward earlier points). That means they all get scheduled at the top > of the loop body. This is valid, and it usually makes sense on > machines with lots of registers, but it is kind of dumb when the > number of loaded values is larger than the number of available temp > registers. But we can't measure register pressure at the point the > CFG is built. It's the typical NP-hard chicken-and-egg problem, of > needing a CFG to build a register allocation, but needing a register > allocation to make a good CFG assignment. Years ago we decided to led > the loads float up, and assume that modern hardware would supply the > temp. registers and/or stack caches. It would be more graceful to > throttle the load placement a little more (e.g., to try to reduce > load-to-last-use distance). But this seems to be a medium-large > project, and there have always been more pressing matters to deal with. > > I can't say off-hand why the x+0x80 version schedules the loads > better. The +0x80 part probably gets subsumed into the index ranges > which are split in complicated ways (as I mentioned earlier). I have > no idea why the signed loads (feeding the +0x80 ops) would trickle > downward in the graph compared with the unsigned loads bouncing up to > the loop top. This might be a case where PrintOptoAssembly would > supply a missing clue; the ideal graph visualizer would be even > better. Maybe there are "invisible" (non-coding) nodes which > participate in the CFG and accidentally prevent the signed loads from > rising. Or maybe the heuristics are just rolling opposite ways on > similar but slightly different inputs; this also is typical of NP-hard > algorithms. > > -- John > > From mlists at juma.me.uk Tue Jan 20 05:31:58 2009 From: mlists at juma.me.uk (Ismael Juma) Date: Tue, 20 Jan 2009 13:31:58 +0000 (UTC) Subject: A question about bytecodes + unsigned load performance ./. =?utf-8?b?YWRkCXBlcmZvcm1hY2U=?= References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomai n> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <4975C3DE.8050109@gmx.de> Message-ID: Ulf Zibis writes: > What does "NP-hard" mean? http://en.wikipedia.org/wiki/NP-hard Ismael From Thomas.Rodriguez at Sun.COM Tue Jan 20 11:22:53 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 20 Jan 2009 11:22:53 -0800 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232376193.18371.394.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> Message-ID: On Jan 19, 2009, at 6:43 AM, Christian Thalinger wrote: > On Fri, 2009-01-16 at 12:29 -0800, John Rose wrote: >> Yes. It's a valid ideal node type, not hardware specific and useful >> to optimizations. > > As I've already written on hotspot-dev, the optimization works but > it's > generally not faster. I think on an out of order machine that much of this simply gets hidden, especially when there's a lot of load and store traffic. Try measuring a loop without stores, maybe something that simply sums the results. Sparc would benefit from this much more since it's in order and sign extending loads introduce a bubble in the pipeline. tom > > > I'm not sure yet why this is the case, as the new code is denser. > Maybe > both codes get translated to the same micro-ops, but then the > performance should be at least equal. > > The following example is with my changes (Intel Core2 Duo T9300 @ > 2.5GHz): > > time for map[a & 0xFF]: 1525 ms > time for map[a + 0x80]: 1461 ms > > The first one boils down to: > > 0xfffffd7ffa3029d2: movzbl 0x19(%r10),%r10d > 0xfffffd7ffa3029d7: movzwl 0x18(%r14,%r10,2),%r10d ;*caload > 0xfffffd7ffa3029dd: mov %r10w,0x1a(%rbp,%rdi,2) ;*castore > > and the second to: > > 0xfffffd7ffa302b24: movsbl 0x19(%r13,%rdi,1),%r10d > 0xfffffd7ffa302b4e: movslq %r10d,%r10 > 0xfffffd7ffa302b51: movzwl 0x118(%r14,%r10,2),%r10d ;*caload > 0xfffffd7ffa302b5a: mov %r10w,0x1a(%rbp,%rdi,2) ;*castore > > Maybe out-of-order execution and micro-ops optimizations (I don't know > if there are any in an Intel CPU) can combine movsbl and movslq to one > micro-op, but still, both variants should have the same performance. > Generating movzbq instead of movzbl gives: > > time for map[a & 0xFF]: 1533 ms > > 0xfffffd7ffa303312: movzbq 0x19(%r10),%r10 > 0xfffffd7ffa303317: movzwl 0x18(%r14,%r10,2),%r10d ;*caload > 0xfffffd7ffa30331d: mov %r10w,0x1a(%rbp,%rdi,2) ;*castore > > However, I think we should integrate my changes as it opens up the > possibility for new optimizations more easily, e.g. superword. The > unrolled loop could then use a code sequence like: > > pxor xmm7, xmm7 > movdqa xmm1, xmm0 ; copy source > punpcklbw xmm0, xmm7 ; unpack the 8 low-end bytes > ; into 8 zero-extended 16-bit words > punpckhbw xmm1, xmm7 ; unpack the 8 high-end bytes > ; into 8 zero-extended 16-bit words > > Processing 8 or 16 values at once. And that should definitely be > faster... > > -- Christian > From Christian.Thalinger at Sun.COM Tue Jan 20 13:12:44 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 20 Jan 2009 22:12:44 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> Message-ID: <1232485964.453.5.camel@localhost.localdomain> On Tue, 2009-01-20 at 11:22 -0800, Tom Rodriguez wrote: > I think on an out of order machine that much of this simply gets > hidden, especially when there's a lot of load and store traffic. Try > measuring a loop without stores, maybe something that simply sums the > results. Good idea. I will try that tomorrow. > Sparc would benefit from this much more since it's in order > and sign extending loads introduce a bubble in the pipeline. We have a SPARC at the university, but I guess Sun has also some machines I could use, right? :-) Could someone point me to the right machines I am allowed to use? -- Christian From Vladimir.Kozlov at Sun.COM Wed Jan 21 09:18:20 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 21 Jan 2009 09:18:20 -0800 Subject: Request for reviews (XXXS): 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Message-ID: <497758DC.9090502@sun.com> Resend. http://webrev.invokedynamic.info/kvn/6794939/index.html Fixed 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Problem: Typo in the assert in TypeKlassPtr::cast_to_ptr_type(). Solution: Fix the assert's check to _base == KlassPtr. Reviewed by: Fix verified (y/n): y, bug's test case Other testing: JPRT From Christian.Thalinger at Sun.COM Wed Jan 21 10:11:48 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 21 Jan 2009 19:11:48 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232485964.453.5.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <49653769.5030102@sun.com> <356859ff351767b500886b33e5763559.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <1232485964.453.5.camel@localhost.localdomain> Message-ID: <1232561508.10525.194.camel@localhost.localdomain> On Tue, 2009-01-20 at 22:12 +0100, Christian Thalinger wrote: > On Tue, 2009-01-20 at 11:22 -0800, Tom Rodriguez wrote: > > I think on an out of order machine that much of this simply gets > > hidden, especially when there's a lot of load and store traffic. Try > > measuring a loop without stores, maybe something that simply sums the > > results. > > Good idea. I will try that tomorrow. You were absolutely right. Simply summing up the bytes as unsigned values is 22% faster. I hope I can try it on a SPARC box soon. -- Christian From vladimir.kozlov at sun.com Wed Jan 21 13:57:10 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 21 Jan 2009 21:57:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6794939: assert(_base == OopPtr, "subclass must override cast_to_ptr_type") Message-ID: <20090121215712.4DC8EDD68@hg.openjdk.java.net> Changeset: 465813e0303a Author: kvn Date: 2009-01-21 11:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/465813e0303a 6794939: assert(_base == OopPtr,"subclass must override cast_to_ptr_type") Summary: Fix the assert in TypeKlassPtr::cast_to_ptr_type(). Reviewed-by: never ! src/share/vm/opto/type.cpp From Christian.Thalinger at Sun.COM Thu Jan 22 02:47:55 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 22 Jan 2009 11:47:55 +0100 Subject: INC/DEC vs. ADD/SUB on Intel processors Message-ID: <1232621275.5801.38.camel@localhost.localdomain> Hi! Since on (newer) Intel processors it's recommended to use ADD/SUB instead of INC/DEC (taken from Intel Optimization Reference Manual): 3.5.1.1 Use of the INC and DEC Instructions The INC and DEC instructions modify only a subset of the bits in the flag register. This creates a dependence on all previous writes of the flag register. This is especially problematic when these instructions are on the critical path because they are used to change an address for a load on which many other instructions depend. Assembly/Compiler Coding Rule 32. (M impact, H generality) INC and DEC instructions should be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and DEC do not, therefore creating false dependencies on earlier instructions that set the flags. ...and HotSpot already has a UseIncDec flag, which seems not to be changed somewhere in the code base, wouldn't it be a good idea to set the flag to false in VM_Version::get_processor_features() for (newer) Intel processors? -- Christian From Christian.Thalinger at Sun.COM Thu Jan 22 07:44:50 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 22 Jan 2009 16:44:50 +0100 Subject: Request for review (S): 6796746: rename LoadC (char) opcode class to LoadUS (unsigned short) Message-ID: <1232639090.5801.48.camel@localhost.localdomain> http://webrev.invokedynamic.info/twisti/6796746/ From john.coomes at sun.com Thu Jan 22 21:00:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 05:00:42 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b44 for changeset a395e3aac474 Message-ID: <20090123050042.EF6FBDEE0@hg.openjdk.java.net> Changeset: 99846f001ca2 Author: xdono Date: 2009-01-22 14:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/99846f001ca2 Added tag jdk7-b44 for changeset a395e3aac474 ! .hgtags From john.coomes at sun.com Thu Jan 22 21:02:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 05:02:54 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b44 for changeset 9803dac72540 Message-ID: <20090123050255.D591ADEE5@hg.openjdk.java.net> Changeset: 68814aa5b44b Author: xdono Date: 2009-01-22 14:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/68814aa5b44b Added tag jdk7-b44 for changeset 9803dac72540 ! .hgtags From john.coomes at sun.com Thu Jan 22 21:07:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 05:07:26 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b44 for changeset b203df0741af Message-ID: <20090123050728.70FA4DEEA@hg.openjdk.java.net> Changeset: 0f113667880d Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/0f113667880d Added tag jdk7-b44 for changeset b203df0741af ! .hgtags From john.coomes at sun.com Thu Jan 22 21:09:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 05:09:41 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b44 for changeset 344485a03674 Message-ID: <20090123050943.50C8CDEEF@hg.openjdk.java.net> Changeset: dea7753d7139 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/dea7753d7139 Added tag jdk7-b44 for changeset 344485a03674 ! .hgtags From john.coomes at sun.com Thu Jan 22 21:12:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 05:12:26 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 17 new changesets Message-ID: <20090123051555.8110ADEF4@hg.openjdk.java.net> Changeset: 57dc40ece164 Author: sherman Date: 2008-12-17 22:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/57dc40ece164 6496274: jar seems to use more CPU than it should Summary: boost jar creating performance especially for the large jar file Reviewed-by: martin ! src/share/classes/sun/tools/jar/Main.java Changeset: 85fe3cd9d6f9 Author: wetmore Date: 2008-12-19 10:35 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/85fe3cd9d6f9 6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider Summary: This is the JSSE portion of the fix. Main part is in PKCS11. Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 850d381fa9aa Author: tbell Date: 2008-12-19 22:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/850d381fa9aa Merge Changeset: 3d09cc6c4ea9 Author: alanb Date: 2008-12-22 19:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/3d09cc6c4ea9 6787009: (attach) Stub injection potentially unsafe on windows-x64 Reviewed-by: mchung ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Changeset: 37a9442e3203 Author: tbell Date: 2009-01-09 21:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/37a9442e3203 Merge Changeset: 0bd360988b3a Author: thurka Date: 2009-01-07 14:06 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0bd360988b3a 6790467: Add test for setInterval() for local MonitoredHost and local MonitoredVm Summary: test for MonitoredHost.setInterval() and MonitoredVm.setInterval() added Reviewed-by: swamyv + test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java Changeset: ff572b4f1ca4 Author: martin Date: 2009-01-07 11:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff572b4f1ca4 6788196: (porting) Bounds checks in io_util.c rely on undefined behaviour Reviewed-by: alanb Contributed-by: gbenson at redhat.com ! src/share/native/java/io/io_util.c ! test/java/io/readBytes/ReadBytesBounds.java Changeset: 0272e442cc5b Author: martin Date: 2009-01-08 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0272e442cc5b 6791458: FileInputStream/RandomAccessFile.read leaks memory if invoked on closed stream with len > 8k Reviewed-by: alanb Contributed-by: jeremymanson at google.com ! src/share/native/java/io/io_util.c + test/java/io/readBytes/MemoryLeak.java Changeset: f6c105e60186 Author: bpatel Date: 2009-01-07 16:39 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f6c105e60186 6790217: Javadoc HTML WCAG 2.0 accessibility issues in jdk docs makefile - Bold tags should be strong Reviewed-by: jjg ! make/docs/Makefile Changeset: 71a6cd33d365 Author: bpatel Date: 2009-01-08 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/71a6cd33d365 Merge Changeset: f5062c0ae8d5 Author: bpatel Date: 2009-01-08 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f5062c0ae8d5 Merge Changeset: 961ea5a46a0c Author: martin Date: 2009-01-09 16:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/961ea5a46a0c 6792066: src/share/native/java/io/io_util.c clean-ups Reviewed-by: alanb ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h Changeset: 5c39d920b488 Author: tbell Date: 2009-01-09 22:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5c39d920b488 Merge Changeset: 4dab1a24dca2 Author: tbell Date: 2009-01-16 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4dab1a24dca2 Merge Changeset: 6dce6ac0929e Author: tbell Date: 2009-01-14 21:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6dce6ac0929e 6754862: jdk/src/windows/bin/java_md.c: hardcoded reference to msvcr71.dll 6779412: VS2008 errors compiling jdk sources Summary: Update Makefiles to tolerate newer Visual Studio releases and runtimes. Reviewed-by: ohair ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/redist/Makefile ! src/share/bin/main.c ! src/windows/bin/java_md.c Changeset: d8eb2738db6b Author: xdono Date: 2009-01-20 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d8eb2738db6b Merge - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: 527b426497a2 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/527b426497a2 Added tag jdk7-b44 for changeset d8eb2738db6b ! .hgtags From john.coomes at sun.com Thu Jan 22 21:21:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 23 Jan 2009 05:21:03 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 9 new changesets Message-ID: <20090123052118.88BB1DEF9@hg.openjdk.java.net> Changeset: 7a595d92e252 Author: jjg Date: 2009-01-07 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7a595d92e252 6512707: "incompatible types" after (unrelated) annotation processing Reviewed-by: darcy Contributed-by: prunge at velocitynet.com.au ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java + test/tools/javac/processing/6512707/T6512707.java + test/tools/javac/processing/6512707/TestAnnotation.java + test/tools/javac/processing/6512707/TestEnum.java Changeset: 47a62d8d98b4 Author: bpatel Date: 2009-01-08 16:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/47a62d8d98b4 6786028: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Bold tags should be strong Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java ! test/com/sun/javadoc/testHref/TestHref.java + test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java + test/com/sun/javadoc/testHtmlStrongTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlStrongTag/pkg2/C2.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java Changeset: dbe9e82f9d25 Author: bpatel Date: 2009-01-08 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dbe9e82f9d25 Merge ! test/com/sun/javadoc/AuthorDD/AuthorDD.java Changeset: 905e151a185a Author: mcimadamore Date: 2009-01-13 13:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/905e151a185a 6765045: Remove rawtypes warnings from langtools Summary: Removed all occurrences of rawtypes warnings from langtools Reviewed-by: jjg, bpatel ! make/build.properties ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Pair.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/sun/tools/javap/FieldData.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/MethodData.java Changeset: d57378c34fdb Author: mcimadamore Date: 2009-01-13 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d57378c34fdb 6665356: Cast not allowed when both qualifying type and inner class are parameterized Summary: Fixed parser and cats conversion in order to allow cast between generic inner classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/cast/6665356/T6665356.java + test/tools/javac/cast/6665356/T6665356.out + test/tools/javac/generics/rare/6665356/T6665356.java + test/tools/javac/generics/rare/6665356/T6665356.out Changeset: 09eb1acc9610 Author: mcimadamore Date: 2009-01-13 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/09eb1acc9610 6723444: javac fails to substitute type variables into a constructor's throws clause Summary: Added constructor's actual type info to NewClass AST node Reviewed-by: jjg Contributed-by: mark at twistedbanana.demon.co.uk ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/generics/6723444/T6723444.java + test/tools/javac/generics/6723444/T6723444.out Changeset: e157bd68dfc5 Author: mcimadamore Date: 2009-01-13 13:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e157bd68dfc5 6558559: Extra "unchecked" diagnostic Summary: Fixed Types.sideCast in order to suppress redundant unchecked warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6558559/T6558559a.java + test/tools/javac/cast/6558559/T6558559b.java Changeset: 28f0b10d6c1a Author: tbell Date: 2009-01-16 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/28f0b10d6c1a Merge Changeset: 30db5e0aaf83 Author: xdono Date: 2009-01-22 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/30db5e0aaf83 Added tag jdk7-b44 for changeset 28f0b10d6c1a ! .hgtags From Christian.Thalinger at Sun.COM Tue Jan 27 13:46:46 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 27 Jan 2009 21:46:46 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6796746: rename LoadC (char) opcode class to LoadUS (unsigned short) Message-ID: <20090127214653.BC858E29A@hg.openjdk.java.net> Changeset: 3b5ac9e7e6ea Author: twisti Date: 2009-01-26 16:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3b5ac9e7e6ea 6796746: rename LoadC (char) opcode class to LoadUS (unsigned short) Summary: Renaming LoadC to LoadUS would round up the planned introduction of LoadUB and LoadUI. Reviewed-by: phh, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp From john.coomes at sun.com Thu Jan 29 21:00:58 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 05:00:58 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b45 for changeset 99846f001ca2 Message-ID: <20090130050058.D9641E4BF@hg.openjdk.java.net> Changeset: e8a2a4d18777 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/e8a2a4d18777 Added tag jdk7-b45 for changeset 99846f001ca2 ! .hgtags From john.coomes at sun.com Thu Jan 29 21:03:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 05:03:21 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b45 for changeset 68814aa5b44b Message-ID: <20090130050322.81591E4C6@hg.openjdk.java.net> Changeset: 1691dbfc08f8 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/1691dbfc08f8 Added tag jdk7-b45 for changeset 68814aa5b44b ! .hgtags From john.coomes at sun.com Thu Jan 29 21:09:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 05:09:25 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b45 for changeset 0f113667880d Message-ID: <20090130050927.89992E4D3@hg.openjdk.java.net> Changeset: b2271877894a Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/b2271877894a Added tag jdk7-b45 for changeset 0f113667880d ! .hgtags From john.coomes at sun.com Thu Jan 29 21:11:51 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 05:11:51 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b45 for changeset dea7753d7139 Message-ID: <20090130051154.0F295E4D8@hg.openjdk.java.net> Changeset: af4a3eeb7812 Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/af4a3eeb7812 Added tag jdk7-b45 for changeset dea7753d7139 ! .hgtags From john.coomes at sun.com Thu Jan 29 21:14:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 05:14:14 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b45 for changeset 527b426497a2 Message-ID: <20090130051441.8D242E4DD@hg.openjdk.java.net> Changeset: 997c6403bf2e Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/997c6403bf2e Added tag jdk7-b45 for changeset 527b426497a2 ! .hgtags From john.coomes at sun.com Thu Jan 29 21:20:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 30 Jan 2009 05:20:03 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b45 for changeset 30db5e0aaf83 Message-ID: <20090130052006.4F57CE4E2@hg.openjdk.java.net> Changeset: d957ceba29f9 Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d957ceba29f9 Added tag jdk7-b45 for changeset 30db5e0aaf83 ! .hgtags From Ulf.Zibis at gmx.de Fri Jan 30 15:43:41 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 31 Jan 2009 00:43:41 +0100 Subject: A question about bytecodes + unsigned load performance ./. add performace In-Reply-To: <1232561508.10525.194.camel@localhost.localdomain> References: <04e11560b685647fecac6de6e1106af4.squirrel@webmail.elfarto.com> <85E80190-2636-45E8-AA76-BAA0F332CAC0@Sun.COM> <49665978.8070206@elfarto.com> <94E1EF31-8A55-4C6F-A938-E130DC33AE49@Sun.COM> <15780B10-FC97-412D-85F2-C5092FF7013D@sun.com> <4967E171.6070307@gmx.de> <4F23C298-6A53-4DEA-B39D-84C8609FD9DC@Sun.COM> <49680E3B.3000506@gmx.de> <2298C764-D530-4F46-AFD3-136BB62B57D3@Sun.COM> <1231777780.18329.98.camel@localhost.localdomain> <558E126C-9CE8-4D16-8C26-23D528A2733D@Sun.COM> <1231850179.23038.6.camel@localhost.localdomain> <496CDCEB.3070007@sun.com> <1232032692.1361.74.camel@localhost.localdomain> <496F75F2.1070009@sun.com> <1232042420.1361.90.camel@localhost.localdomain> <496F85A8.3060609@sun.com> <39AAF268-0CAD-49C2-8602-15A1BA093EF9@sun.com> <1232116144.1361.93.camel@localhost.localdomain> <1232485964.453.5.camel@localhost.localdomain> <1232561508.10525.194.camel@localhost.localdomain> Message-ID: <498390AD.6090405@gmx.de> Am 21.01.2009 19:11, Christian Thalinger schrieb: > On Tue, 2009-01-20 at 22:12 +0100, Christian Thalinger wrote: > >> On Tue, 2009-01-20 at 11:22 -0800, Tom Rodriguez wrote: >> >>> I think on an out of order machine that much of this simply gets >>> hidden, especially when there's a lot of load and store traffic. Try >>> measuring a loop without stores, maybe something that simply sums the >>> results. >>> >> Good idea. I will try that tomorrow. >> > > You were absolutely right. Simply summing up the bytes as unsigned > values is 22% faster. > > I hope I can try it on a SPARC box soon. > > -- Christian > > Hi, I have experienced differences, if benchmark test exceeds CPU L1-cache or not. Try: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/DecoderBenchmark.java?rev=607&view=markup -Ulf