From thomas.rodriguez at sun.com Wed Jul 1 14:40:34 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 01 Jul 2009 21:40:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6856025: assert(_base >= OopPtr && _base <= KlassPtr, "Not a Java pointer") Message-ID: <20090701214042.BE094E84A@hg.openjdk.java.net> Changeset: bf3489cc0aa0 Author: never Date: 2009-07-01 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bf3489cc0aa0 6856025: assert(_base >= OopPtr && _base <= KlassPtr,"Not a Java pointer") Reviewed-by: kvn ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp From vladimir.kozlov at sun.com Wed Jul 1 19:44:49 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 02 Jul 2009 02:44:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 26 new changesets Message-ID: <20090702024544.C8F3BE893@hg.openjdk.java.net> Changeset: 315a5d70b295 Author: iveresov Date: 2009-05-11 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/315a5d70b295 6484957: G1: parallel concurrent refinement 6826318: G1: remove traversal-based refinement code Summary: Removed traversal-based refinement code as it's no longer used. Made the concurrent refinement (queue-based) parallel. Reviewed-by: tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 215f81b4d9b3 Author: iveresov Date: 2009-05-18 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/215f81b4d9b3 6841831: G1: assert(contains_reference(from),"We just added it!") fires Summary: During parallel rset updating we have to make sure that the worker ids of the refinement threads do not intersect with the worker ids that can be claimed by the mutator threads. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 29e7d79232b9 Author: apetrusenko Date: 2009-05-19 04:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/29e7d79232b9 6819065: G1: eliminate high serial card table clearing time Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 7fd05714f579 Author: jcoomes Date: 2009-05-26 16:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fd05714f579 Merge Changeset: fe1574da39fc Author: ysr Date: 2009-06-07 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe1574da39fc 6848641: CMSCollector::_roots_scanning_options should be initialized Summary: The field is now initialized in the constructor. Reviewed-by: iveresov, jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: f89cf529c3c7 Author: iveresov Date: 2009-06-08 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f89cf529c3c7 6849122: G1: Typo introduced during implementation of the parallel refinement Summary: Typo fix Reviewed-by: jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 7295839252de Author: jmasa Date: 2009-06-10 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7295839252de Merge Changeset: aa0c48844632 Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/aa0c48844632 Added tag jdk7-b59 for changeset c55be0c7bd32 ! .hgtags Changeset: f5ee65f94d9a Author: ohair Date: 2009-05-15 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f5ee65f94d9a Merge - make/jprt.config ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: a77eddcd510c Author: ohair Date: 2009-05-19 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a77eddcd510c 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: cf4f487696ba Author: trims Date: 2009-06-11 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cf4f487696ba Merge Changeset: 08f86fa55a31 Author: trims Date: 2009-06-11 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/08f86fa55a31 6850551: Bump the HS16 build number to 04 Summary: Update the HS16 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 86092459c54d Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/86092459c54d Added tag jdk7-b60 for changeset a77eddcd510c ! .hgtags Changeset: 27b728fd1281 Author: trims Date: 2009-06-11 21:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/27b728fd1281 Merge Changeset: 821269eca479 Author: ysr Date: 2009-06-11 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/821269eca479 6820167: GCALotAtAllSafepoints + FullGCALot(ScavengeALot) options crash JVM Summary: Short-circuit gc-a-lot attempts by non-JavaThreads; SkipGCALot c'tor to elide re-entrant gc-a-lot attempts. Reviewed-by: apetrusenko, jcoomes, jmasa, kamg ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: d44bdab1c03d Author: johnc Date: 2009-06-11 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d44bdab1c03d 6843694: G1: assert(index < _vs.committed_size(),"bad index"), g1BlockOffsetTable.inline.hpp:55 Summary: For heaps larger than 32Gb, the number of heap regions overflows the data type used to hold the region index in the SparsePRT structure. Changed the region indexes, card indexes, and RSet hash table buckets to ints and added some size overflow guarantees. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 353ba4575581 Author: jcoomes Date: 2009-06-07 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/353ba4575581 6814552: par compact - some compilers fail to optimize bitmap code Reviewed-by: tonyp, iveresov, jmasa, ysr ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp Changeset: 6e2afda171db Author: jcoomes Date: 2009-06-11 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6e2afda171db 6849716: BitMap - performance regression introduced with G1 Summary: make verification code visible only in debug builds Reviewed-by: iveresov, ysr, johnc, apetrusenko, tonyp ! src/share/vm/includeDB_compiler1 ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/macros.hpp Changeset: 3104f76478ee Author: jmasa Date: 2009-06-18 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3104f76478ee Merge Changeset: 830ca2573896 Author: tonyp Date: 2009-06-12 16:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/830ca2573896 6850846: G1: extend G1 marking verification Summary: extend G1 marking verification to use either the "prev" or "next" marking information, as appropriate. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 85d0690f7d12 Author: jmasa Date: 2009-06-19 07:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/85d0690f7d12 Merge Changeset: a88386380bda Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a88386380bda Added tag jdk7-b61 for changeset 27b728fd1281 ! .hgtags Changeset: 8754a3c37762 Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8754a3c37762 Added tag jdk7-b62 for changeset a88386380bda ! .hgtags Changeset: f9c95d5dc41f Author: trims Date: 2009-06-25 22:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9c95d5dc41f Merge Changeset: 32c83fb84370 Author: trims Date: 2009-06-30 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/32c83fb84370 6856257: Bump the HS16 build number to 05 Summary: Update the HS16 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b64314863098 Author: kvn Date: 2009-07-01 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b64314863098 Merge From vladimir.kozlov at sun.com Wed Jul 1 22:54:13 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 02 Jul 2009 05:54:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6840775: Multiple JVM crashes seen with 1.6.0_10 through 1.6.0_14 Message-ID: <20090702055415.4CDB1E8C8@hg.openjdk.java.net> Changeset: acba6af809c8 Author: kvn Date: 2009-07-01 20:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/acba6af809c8 6840775: Multiple JVM crashes seen with 1.6.0_10 through 1.6.0_14 Summary: Put missed reference to allocated array in copyOf() intrinsic into OopMap for the call slow_arraycopy(). Reviewed-by: never ! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java ! make/solaris/makefiles/optimized.make ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/library_call.cpp From Vladimir.Kozlov at Sun.COM Thu Jul 2 10:59:03 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 02 Jul 2009 10:59:03 -0700 Subject: Inconsistency between adr types of ideal and mach loads from conP Message-ID: <4A4CF567.2080405@sun.com> While testing my changes for StoreOop macro node with CTW rt.jar I hit this problem. In ideal graph load from ConP has exact adr type and its memory edge is immutable memory: [t at 21 l at 21]: print m._new2old_map[133]->dump(2) o3 Start === o3 o0 [[o3 o5 o6 o7 o8 o9 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} o73 Initialize === o3560 o1 o76 o1 o1 o1 o3561 [[o74 o75 ]] o97 ConP === o0 [[ ... o3500 ... ]] #java/lang/Class:exact * Oop:java/lang/Class:exact * o7 Parm === o3 [[ ... o3500 o3510 ]] Memory Memory: @BotPTR *+bot, idx=Bot; o74 Proj === o73 [[o3504 o77 o3500 ]] #0 o3500 LoadI === o74 o7 o97 [[o3501 o3514 o3752 o3530 o3538 ]] @java/lang/Class:exact *, idx=11; #int [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()->dump() java/lang/Class:exact * But corresponding mach load has rawptr type since the "direct" address has only offset "disp" and no base: [t at 21 l at 21]: print load->dump(2) 91 Start === 91 1 [[ 91 90 92 ... ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms: KeyStroke::getKeyStroke @ bci:17 MotifTextUI:: @ bci:14 68 Initialize === 69 0 124 0 0 0 125 [[ 67 144 ]] !jvms: MotifTextUI:: @ bci:6 92 MachProj === 91 [[ ... 113 ... ]] #2/unmatched Memory: @BotPTR *+bot, idx=Bot; !jvms: MotifTextUI:: @ bci:-1 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched !jvms: MotifTextUI:: @ bci:6 133 loadI === 67 92 [[ 65 134 146 145 165 ]] java/lang/Class:exact * [t at 21 l at 21]: print load->adr_type()->dump() rawptr:BotPTR class TypePtr* MachNode::adr_type() { ... // Direct addressing modes have no base node, simply an indirect // offset, which is always to raw memory. if (base == NULL) { ... // %%% make offset be intptr_t assert(!Universe::heap()->is_in_reserved((oop)offset), "must be a raw ptr"); return TypeRawPtr::BOTTOM; } When the mach load is processed in PhaseCFG::insert_anti_dependences() it became anti-dep on the Initialize node (which also has rawptr:BotPTR type) at the same block: } else { // Found a possibly-interfering store in the load's 'early' block. // This means 'load' cannot sink at all in the dominator tree. // Add an anti-dep edge, and squeeze 'load' into the highest block. assert(store != load->in(0), "dependence cycle found"); if (verify) { assert(store->find_edge(load) != -1, "missing precedence edge"); } else { store->add_prec(load); } 68 Initialize === 69 0 124 0 0 0 125 | 133 [[ 67 144 ]] !jvms: MotifTextUI:: @ bci:6 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched !jvms: MotifTextUI:: @ bci:6 133 loadI === 67 92 [[ 65 134 146 145 165 68 ]] java/lang/Class:exact * And this screw up local scheduling since the load has the control edge after the Initialize. Note: in 64-bit VM "direct" address mode is not available. Should I fix MemNode::adr_type() to return rawptr type for such case or MachNode::adr_type() to return exact type? Thanks, Vladimir From Thomas.Rodriguez at Sun.COM Thu Jul 2 11:12:26 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 02 Jul 2009 11:12:26 -0700 Subject: Inconsistency between adr types of ideal and mach loads from conP In-Reply-To: <4A4CF567.2080405@sun.com> References: <4A4CF567.2080405@sun.com> Message-ID: I think MemNode::adr_type is the one we consider to be correct since that's the one used for all the optimizations. MachNode::adr_type needs to return the same answer or at least an equivalent answer from an aliasing standpoint. tom On Jul 2, 2009, at 10:59 AM, Vladimir Kozlov wrote: > While testing my changes for StoreOop macro node with CTW rt.jar > I hit this problem. > > In ideal graph load from ConP has exact adr type and its memory > edge is immutable memory: > > [t at 21 l at 21]: print m._new2old_map[133]->dump(2) > o3 Start === o3 o0 [[o3 o5 o6 o7 o8 o9 ]] #{0:control, > 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} > o73 Initialize === o3560 o1 o76 o1 o1 o1 o3561 [[o74 o75 ]] > o97 ConP === o0 [[ ... o3500 ... ]] #java/lang/Class:exact > * Oop:java/lang/Class:exact * > o7 Parm === o3 [[ ... o3500 o3510 ]] Memory Memory: > @BotPTR *+bot, idx=Bot; > o74 Proj === o73 [[o3504 o77 o3500 ]] #0 > o3500 LoadI === o74 o7 o97 [[o3501 o3514 o3752 o3530 o3538 ]] > @java/lang/Class:exact *, idx=11; #int > > [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()->dump() > java/lang/Class:exact * > > But corresponding mach load has rawptr type since the "direct" address > has only offset "disp" and no base: > > [t at 21 l at 21]: print load->dump(2) > 91 Start === 91 1 [[ 91 90 92 ... ]] #{0:control, > 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms: > KeyStroke::getKeyStroke @ bci:17 MotifTextUI:: @ bci:14 > 68 Initialize === 69 0 124 0 0 0 125 [[ 67 > 144 ]] !jvms: MotifTextUI:: @ bci:6 > 92 MachProj === 91 [[ ... 113 ... ]] #2/unmatched > Memory: @BotPTR *+bot, idx=Bot; !jvms: MotifTextUI:: @ bci:-1 > 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched ! > jvms: MotifTextUI:: @ bci:6 > 133 loadI === 67 92 [[ 65 134 146 145 165 ]] java/lang/ > Class:exact * > > [t at 21 l at 21]: print load->adr_type()->dump() > rawptr:BotPTR > > class TypePtr* MachNode::adr_type() { > ... > // Direct addressing modes have no base node, simply an indirect > // offset, which is always to raw memory. > if (base == NULL) { > ... > // %%% make offset be intptr_t > assert(!Universe::heap()->is_in_reserved((oop)offset), "must be a > raw ptr"); > return TypeRawPtr::BOTTOM; > } > > > When the mach load is processed in PhaseCFG::insert_anti_dependences() > it became anti-dep on the Initialize node (which also has > rawptr:BotPTR type) > at the same block: > > } else { > // Found a possibly-interfering store in the load's 'early' > block. > // This means 'load' cannot sink at all in the dominator tree. > // Add an anti-dep edge, and squeeze 'load' into the highest > block. > assert(store != load->in(0), "dependence cycle found"); > if (verify) { > assert(store->find_edge(load) != -1, "missing precedence > edge"); > } else { > store->add_prec(load); > } > > 68 Initialize === 69 0 124 0 0 0 125 | 133 [[ 67 > 144 ]] !jvms: MotifTextUI:: @ bci:6 > 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched ! > jvms: MotifTextUI:: @ bci:6 > 133 loadI === 67 92 [[ 65 134 146 145 165 68 ]] java/ > lang/Class:exact * > > And this screw up local scheduling since the load has the control > edge after the Initialize. > > Note: in 64-bit VM "direct" address mode is not available. > > Should I fix MemNode::adr_type() to return rawptr type for such case > or > MachNode::adr_type() to return exact type? > > Thanks, > Vladimir > From Thomas.Rodriguez at Sun.COM Thu Jul 2 14:27:53 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 02 Jul 2009 14:27:53 -0700 Subject: anti deps, loadKlass and calls Message-ID: <86800A03-CFBE-4246-B046-F9A634E0D12B@sun.com> I'm looking at a compilation bailout that results from a failure to schedule a chain of loadKlass with an extra precedence edge. This is bug 6857159. This is the cycle that causes the problem: 24 tlsLoadP === 16 [[ 25 23 ]] 9 loadKlass === _ 18 22 [[ 8 13 ]] * Klass: * 22 loadKlass === _ 18 23 [[ 9 ]] klass java/lang/ Thread: 0x080de410 * Klass:klass java/lang/Thread: 0x080de410 * ! jvms: ct$ct0::run @ bci:7 13 CallDynamicJavaDirect === 15 17 18 19 0 20 0 0 | 9 [[ 14 12 21 26 ]] Dynamic ct$ct0::message # void ( ct$ct0:NotNull * ) ct$ct0::run @ bci:1 !jvms: ct$ct0::run @ bci:1 26 MachProj === 13 [[ 23 4 29 31 ]] #2/unmatched Memory: @BotPTR *+bot, idx=Bot; !jvms: ct$ct0::run @ bci:1 23 loadP === _ 26 24 [[ 22 4 ]] java/lang/Thread:NotNull * Oop:java/lang/Thread:NotNull * !jvms: ct$ct0::run @ bci:4 The code corresponds to a checkcast of Thread.currentThread() to a type in the middle of hierarchy of classes. The test case is in the bug report. The first loadKlass is loading the klass from the header and it's in its own alias class and is marked as not rewritable. This causes the anti dep code to just skip it. The loadKlass with the precedence edge is a load from the superclass display list used by checkcast. Since it's not in it's own alias class we can't set the is_rewritable flag to false so we will actually look for anti deps. Because it uses the same memory input as the call we end up creating an anti dep edge between them even though the loadP is actually dependent on the output of the call. So maybe LoadKlass should return false for needs_anti_dependence_check? The memory edges on them should always guarantee correct placement. The other thing that seems wrong is that the loadP getting the current thread from tls should use immutable_memory instead of the current memory since it's an unchanging value. Either of these changes actually fix the problem but I think skipping the anti-dep check is the more correct one. This failure was caused by 6385730 where we changed LoadKlass and LoadRange to use the starting memory to indicate that they could be commoned across the whole compile. Prior to that they would have used the same memory as the loadP so it would have worked correctly. tom From Vladimir.Kozlov at Sun.COM Thu Jul 2 16:03:31 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 02 Jul 2009 16:03:31 -0700 Subject: anti deps, loadKlass and calls In-Reply-To: <86800A03-CFBE-4246-B046-F9A634E0D12B@sun.com> References: <86800A03-CFBE-4246-B046-F9A634E0D12B@sun.com> Message-ID: <4A4D3CC3.2080002@sun.com> I agree that LoadKlass and LoadRange should return false for needs_anti_dependence_check since they are accessing memory which can't be modified. Vladimir Tom Rodriguez wrote: > I'm looking at a compilation bailout that results from a failure to > schedule a chain of loadKlass with an extra precedence edge. This is > bug 6857159. This is the cycle that causes the problem: > > > 24 tlsLoadP === 16 [[ 25 23 ]] > 9 loadKlass === _ 18 22 [[ 8 13 ]] * Klass: * > 22 loadKlass === _ 18 23 [[ 9 ]] klass java/lang/Thread: > 0x080de410 * Klass:klass java/lang/Thread: 0x080de410 * !jvms: > ct$ct0::run @ bci:7 > 13 CallDynamicJavaDirect === 15 17 18 19 0 20 0 0 | 9 [[ > 14 12 21 26 ]] Dynamic ct$ct0::message # void ( ct$ct0:NotNull * ) > ct$ct0::run @ bci:1 !jvms: ct$ct0::run @ bci:1 > 26 MachProj === 13 [[ 23 4 29 31 ]] #2/unmatched > Memory: @BotPTR *+bot, idx=Bot; !jvms: ct$ct0::run @ bci:1 > 23 loadP === _ 26 24 [[ 22 4 ]] java/lang/Thread:NotNull * > Oop:java/lang/Thread:NotNull * !jvms: ct$ct0::run @ bci:4 > > The code corresponds to a checkcast of Thread.currentThread() to a type > in the middle of hierarchy of classes. The test case is in the bug > report. The first loadKlass is loading the klass from the header and > it's in its own alias class and is marked as not rewritable. This > causes the anti dep code to just skip it. The loadKlass with the > precedence edge is a load from the superclass display list used by > checkcast. Since it's not in it's own alias class we can't set the > is_rewritable flag to false so we will actually look for anti deps. > Because it uses the same memory input as the call we end up creating an > anti dep edge between them even though the loadP is actually dependent > on the output of the call. So maybe LoadKlass should return false for > needs_anti_dependence_check? The memory edges on them should always > guarantee correct placement. The other thing that seems wrong is that > the loadP getting the current thread from tls should use > immutable_memory instead of the current memory since it's an unchanging > value. Either of these changes actually fix the problem but I think > skipping the anti-dep check is the more correct one. > > This failure was caused by 6385730 where we changed LoadKlass and > LoadRange to use the starting memory to indicate that they could be > commoned across the whole compile. Prior to that they would have used > the same memory as the loadP so it would have worked correctly. > > tom From Vladimir.Kozlov at Sun.COM Thu Jul 2 17:49:53 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 02 Jul 2009 17:49:53 -0700 Subject: Inconsistency between adr types of ideal and mach loads from conP In-Reply-To: References: <4A4CF567.2080405@sun.com> Message-ID: <4A4D55B1.1020205@sun.com> Thanks, Tom the failed before compilation passed with this fix: @@ -300,6 +300,12 @@ const Node* MachNode::get_base_and_disp( } } adr_type = t_disp->add_offset(offset); + } else if( base == NULL && offset != 0 && offset != Type::OffsetBot ) { + // Use ideal type if it is ptr. + const TypePtr *tp = oper->type()->isa_ptr(); + if( tp != NULL ) { + adr_type = tp; + } } } Thanks, Vladimir Tom Rodriguez wrote: > I think MemNode::adr_type is the one we consider to be correct since > that's the one used for all the optimizations. MachNode::adr_type needs > to return the same answer or at least an equivalent answer from an > aliasing standpoint. > > tom > > On Jul 2, 2009, at 10:59 AM, Vladimir Kozlov wrote: > >> While testing my changes for StoreOop macro node with CTW rt.jar >> I hit this problem. >> >> In ideal graph load from ConP has exact adr type and its memory >> edge is immutable memory: >> >> [t at 21 l at 21]: print m._new2old_map[133]->dump(2) >> o3 Start === o3 o0 [[o3 o5 o6 o7 o8 o9 ]] #{0:control, >> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} >> o73 Initialize === o3560 o1 o76 o1 o1 o1 o3561 [[o74 o75 ]] >> o97 ConP === o0 [[ ... o3500 ... ]] #java/lang/Class:exact * >> Oop:java/lang/Class:exact * >> o7 Parm === o3 [[ ... o3500 o3510 ]] Memory Memory: @BotPTR >> *+bot, idx=Bot; >> o74 Proj === o73 [[o3504 o77 o3500 ]] #0 >> o3500 LoadI === o74 o7 o97 [[o3501 o3514 o3752 o3530 o3538 ]] >> @java/lang/Class:exact *, idx=11; #int >> >> [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()->dump() >> java/lang/Class:exact * >> >> But corresponding mach load has rawptr type since the "direct" address >> has only offset "disp" and no base: >> >> [t at 21 l at 21]: print load->dump(2) >> 91 Start === 91 1 [[ 91 90 92 ... ]] #{0:control, 1:abIO, >> 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms: >> KeyStroke::getKeyStroke @ bci:17 MotifTextUI:: @ bci:14 >> 68 Initialize === 69 0 124 0 0 0 125 [[ 67 144 ]] >> !jvms: MotifTextUI:: @ bci:6 >> 92 MachProj === 91 [[ ... 113 ... ]] #2/unmatched >> Memory: @BotPTR *+bot, idx=Bot; !jvms: MotifTextUI:: @ bci:-1 >> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched !jvms: >> MotifTextUI:: @ bci:6 >> 133 loadI === 67 92 [[ 65 134 146 145 165 ]] >> java/lang/Class:exact * >> >> [t at 21 l at 21]: print load->adr_type()->dump() >> rawptr:BotPTR >> >> class TypePtr* MachNode::adr_type() { >> ... >> // Direct addressing modes have no base node, simply an indirect >> // offset, which is always to raw memory. >> if (base == NULL) { >> ... >> // %%% make offset be intptr_t >> assert(!Universe::heap()->is_in_reserved((oop)offset), "must be a >> raw ptr"); >> return TypeRawPtr::BOTTOM; >> } >> >> >> When the mach load is processed in PhaseCFG::insert_anti_dependences() >> it became anti-dep on the Initialize node (which also has >> rawptr:BotPTR type) >> at the same block: >> >> } else { >> // Found a possibly-interfering store in the load's 'early' block. >> // This means 'load' cannot sink at all in the dominator tree. >> // Add an anti-dep edge, and squeeze 'load' into the highest block. >> assert(store != load->in(0), "dependence cycle found"); >> if (verify) { >> assert(store->find_edge(load) != -1, "missing precedence edge"); >> } else { >> store->add_prec(load); >> } >> >> 68 Initialize === 69 0 124 0 0 0 125 | 133 [[ 67 >> 144 ]] !jvms: MotifTextUI:: @ bci:6 >> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched !jvms: >> MotifTextUI:: @ bci:6 >> 133 loadI === 67 92 [[ 65 134 146 145 165 68 ]] >> java/lang/Class:exact * >> >> And this screw up local scheduling since the load has the control >> edge after the Initialize. >> >> Note: in 64-bit VM "direct" address mode is not available. >> >> Should I fix MemNode::adr_type() to return rawptr type for such case or >> MachNode::adr_type() to return exact type? >> >> Thanks, >> Vladimir >> > From john.coomes at sun.com Thu Jul 2 21:31:35 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Jul 2009 04:31:35 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b63 for changeset 57f7e028c7ad Message-ID: <20090703043135.94DF2E9FB@hg.openjdk.java.net> Changeset: 9849536536d2 Author: xdono Date: 2009-07-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/9849536536d2 Added tag jdk7-b63 for changeset 57f7e028c7ad ! .hgtags From john.coomes at sun.com Thu Jul 2 21:36:23 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Jul 2009 04:36:23 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b63 for changeset d20e45cd539f Message-ID: <20090703043624.EA5BCEA00@hg.openjdk.java.net> Changeset: b3ad991d9534 Author: xdono Date: 2009-07-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/b3ad991d9534 Added tag jdk7-b63 for changeset d20e45cd539f ! .hgtags From john.coomes at sun.com Thu Jul 2 21:47:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Jul 2009 04:47:13 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b63 for changeset ae449e9c04c1 Message-ID: <20090703044716.5D029EA05@hg.openjdk.java.net> Changeset: a10eec7a1edf Author: xdono Date: 2009-07-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/a10eec7a1edf Added tag jdk7-b63 for changeset ae449e9c04c1 ! .hgtags From john.coomes at sun.com Thu Jul 2 21:52:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Jul 2009 04:52:04 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b63 for changeset b8a6e883c0a6 Message-ID: <20090703045206.E5D64EA0A@hg.openjdk.java.net> Changeset: aaa25dfd3de6 Author: xdono Date: 2009-07-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/aaa25dfd3de6 Added tag jdk7-b63 for changeset b8a6e883c0a6 ! .hgtags From john.coomes at sun.com Thu Jul 2 21:57:52 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Jul 2009 04:57:52 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 15 new changesets Message-ID: <20090703050124.2AC60EA11@hg.openjdk.java.net> Changeset: 9cf4ef04d9a7 Author: prr Date: 2009-05-06 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9cf4ef04d9a7 6806822: Font.getFontName() is slow in Java5 and 6 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: ec0a8acd4737 Author: jgodinez Date: 2009-05-14 09:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ec0a8acd4737 Merge Changeset: fb03586d68b6 Author: jgodinez Date: 2009-05-21 09:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fb03586d68b6 6829659: Circle is rendered in C shape Reviewed-by: campbell, flar Contributed-by: Google ! src/share/classes/sun/java2d/pisces/PiscesCache.java + test/sun/pisces/ScaleTest.java Changeset: 907324eb3e64 Author: bae Date: 2009-05-23 08:35 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/907324eb3e64 4893408: JPEGReader throws IllegalArgException when setting the destination to BYTE_GRAY Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c + test/javax/imageio/plugins/jpeg/ReadAsGrayTest.java Changeset: b92e3fbbcb63 Author: jgodinez Date: 2009-06-08 13:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b92e3fbbcb63 Merge Changeset: 378feb59435b Author: bae Date: 2009-06-11 13:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/378feb59435b 6296893: BMP Writer handles TopDown property incorrectly for some of the compression types Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java + test/javax/imageio/plugins/bmp/TopDownTest.java Changeset: e138ae33b128 Author: bae Date: 2009-06-11 14:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e138ae33b128 5101862: WBMP Image reader tries to load Quicktime MOV files Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReader.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java + test/javax/imageio/plugins/wbmp/CanDecodeTest.java Changeset: 0ce29cbeb6a9 Author: bae Date: 2009-06-15 14:49 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0ce29cbeb6a9 6829549: JVM crash on certain images Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java Changeset: 5896dcd01fe3 Author: bae Date: 2009-06-15 17:19 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5896dcd01fe3 6684104: Applets fails to launch using ImageIO if .java.policy with File permissions present on the system Reviewed-by: igor, prr ! src/share/classes/javax/imageio/ImageIO.java + test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java + test/javax/imageio/CachePremissionsTest/rw.policy + test/javax/imageio/CachePremissionsTest/rwd.policy + test/javax/imageio/CachePremissionsTest/w.policy Changeset: 956715ded919 Author: jgodinez Date: 2009-06-15 09:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/956715ded919 Merge Changeset: 70903e2c39e3 Author: jgodinez Date: 2009-06-22 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/70903e2c39e3 6850398: Allow GraphicsEnvironment to be loaded by system classloader (edit) Reviewed-by: campbell, prr ! src/share/classes/java/awt/GraphicsEnvironment.java Changeset: fafa991c27ac Author: prr Date: 2009-06-22 14:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fafa991c27ac 6853617: race condition in java.awt.Font.getAttributes() (private method) Reviewed-by: igor, jgodinez ! src/share/classes/java/awt/Font.java Changeset: 2886eb650801 Author: jgodinez Date: 2009-06-24 11:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2886eb650801 Merge - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 2ed6ed6b5bfc Author: jgodinez Date: 2009-06-29 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2ed6ed6b5bfc Merge Changeset: 120df7f49509 Author: xdono Date: 2009-07-02 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/120df7f49509 Added tag jdk7-b63 for changeset 2ed6ed6b5bfc ! .hgtags From john.coomes at sun.com Thu Jul 2 22:13:33 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Jul 2009 05:13:33 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b63 for changeset 5c2c81120555 Message-ID: <20090703051337.72C59EA16@hg.openjdk.java.net> Changeset: 619c768ad104 Author: xdono Date: 2009-07-02 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/619c768ad104 Added tag jdk7-b63 for changeset 5c2c81120555 ! .hgtags From changpeng.fang at sun.com Fri Jul 3 02:13:49 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Fri, 03 Jul 2009 09:13:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6855164: SIGSEGV during compilation of method involving loop over CharSequence. Message-ID: <20090703091403.7E307EA72@hg.openjdk.java.net> Changeset: 0f2d888530e7 Author: cfang Date: 2009-07-02 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0f2d888530e7 6855164: SIGSEGV during compilation of method involving loop over CharSequence. Summary: Don not split a block if it contains a FastLockNode with a PhiNode input. Reviewed-by: kvn, never ! src/share/vm/opto/loopopts.cpp From mlists at juma.me.uk Fri Jul 3 02:53:44 2009 From: mlists at juma.me.uk (Ismael Juma) Date: Fri, 3 Jul 2009 09:53:44 +0000 (UTC) Subject: hg: jdk7/hotspot-comp/hotspot: 6855164: SIGSEGV during compilation =?utf-8?b?b2YJbWV0aG9k?= involving loop over CharSequence. References: <20090703091403.7E307EA72@hg.openjdk.java.net> Message-ID: Hi, writes: > > Changeset: 0f2d888530e7 > Author: cfang > Date: 2009-07-02 16:18 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0f2d888530e7 > > 6855164: SIGSEGV during compilation of method involving loop over CharSequence. Thanks for fixing this. Is there a reason why the test case in the bug report was not included? I remember something in the past about Sun not having the rights to include test cases submitted through the bug tracker, so maybe that's the reason. If so, can something be done to allow the submitter to specify that he or she is ok with Sun including the test case? I am pretty sure that the vast majority of people want the test cases to be included so that regressions don't occur. Best, Ismael From Changpeng.Fang at Sun.COM Fri Jul 3 21:14:01 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Fri, 03 Jul 2009 21:14:01 -0700 Subject: hg: jdk7/hotspot-comp/hotspot: 6855164: SIGSEGV during compilation of method involving loop over CharSequence. In-Reply-To: References: <20090703091403.7E307EA72@hg.openjdk.java.net> Message-ID: <4A4ED709.6010102@sun.com> Ismael Juma wrote: > Hi, > > writes: > >> Changeset: 0f2d888530e7 >> Author: cfang >> Date: 2009-07-02 16:18 -0700 >> URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0f2d888530e7 >> >> 6855164: SIGSEGV during compilation of method involving loop over CharSequence. >> > > Thanks for fixing this. > > Is there a reason why the test case in the bug report was not included? I > remember something in the past about Sun not having the rights to include test > cases submitted through the bug tracker, so maybe that's the reason. If so, can > something be done to allow the submitter to specify that he or she is ok with > Sun including the test case? > > I am pretty sure that the vast majority of people want the test cases to be > included so that regressions don't occur. > > Hi, Ismael: Thanks for pointing this out. I should have included the test case in the bug report with the fix. The test case seems to be the perfect candidate for regression test. I will add the test case soon (unless someone tells me this is not allowed :-) ) Thanks and have a nice weekend! Changpeng > Best, > Ismael > > From mlists at juma.me.uk Sat Jul 4 02:57:17 2009 From: mlists at juma.me.uk (Ismael Juma) Date: Sat, 4 Jul 2009 09:57:17 +0000 (UTC) Subject: hg: jdk7/hotspot-comp/hotspot: 6855164: SIGSEGV during =?utf-8?b?Y29tcGlsYXRpb24Jb2Y=?= method involving loop over CharSequence. References: <20090703091403.7E307EA72@hg.openjdk.java.net> <4A4ED709.6010102@sun.com> Message-ID: Hi Changpeng, Changpeng Fang writes: > Thanks for pointing this out. I should have included the test case in > the bug report with the fix. The test case seems to be > the perfect candidate for regression test. I will add the test case soon > (unless someone tells me this is not > allowed ) Great, thanks. > Thanks and have a nice weekend! And you. :) Best, Ismael From Vladimir.Kozlov at Sun.COM Mon Jul 6 10:37:01 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 06 Jul 2009 10:37:01 -0700 Subject: Request for reviews (XS): 6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class") Message-ID: <4A52363D.8030106@sun.com> http://cr.openjdk.java.net/~kvn/6857661/webrev.00 Fixed 6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class") Problem: It is regression after 6840775 fix. The secondary raw memory barrier (Initialize node) is misplaced on zero length path in generate_arraycopy(). It should be generated only if the path is not dead (in the bug case the copy length is negative) and only after a zeroing code for a new allocated object. Solution: Move the secondary raw memory barrier to the correct place. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Mon Jul 6 12:00:57 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 06 Jul 2009 12:00:57 -0700 Subject: Request for reviews (XS): 6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class") In-Reply-To: <4A52363D.8030106@sun.com> References: <4A52363D.8030106@sun.com> Message-ID: <97C07A25-8364-42CC-90ED-0071DD6E11BD@sun.com> Looks good. tom On Jul 6, 2009, at 10:37 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6857661/webrev.00 > > Fixed 6857661: 64-bit server VM: assert(is_Initialize(),"invalid > node class") > > Problem: > It is regression after 6840775 fix. > The secondary raw memory barrier (Initialize node) > is misplaced on zero length path in generate_arraycopy(). > It should be generated only if the path is not dead > (in the bug case the copy length is negative) and only > after a zeroing code for a new allocated object. > > Solution: > Move the secondary raw memory barrier to the correct place. > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Mon Jul 6 12:05:30 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 06 Jul 2009 12:05:30 -0700 Subject: Request for reviews (XS): 6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class") In-Reply-To: <97C07A25-8364-42CC-90ED-0071DD6E11BD@sun.com> References: <4A52363D.8030106@sun.com> <97C07A25-8364-42CC-90ED-0071DD6E11BD@sun.com> Message-ID: <4A524AFA.30806@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Jul 6, 2009, at 10:37 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6857661/webrev.00 >> >> Fixed 6857661: 64-bit server VM: assert(is_Initialize(),"invalid node >> class") >> >> Problem: >> It is regression after 6840775 fix. >> The secondary raw memory barrier (Initialize node) >> is misplaced on zero length path in generate_arraycopy(). >> It should be generated only if the path is not dead >> (in the bug case the copy length is negative) and only >> after a zeroing code for a new allocated object. >> >> Solution: >> Move the secondary raw memory barrier to the correct place. >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test >> >> Other testing: >> JPRT >> > From Changpeng.Fang at Sun.COM Mon Jul 6 12:43:34 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Mon, 06 Jul 2009 12:43:34 -0700 Subject: Request for reviews (XS): 6857707 : Add missing test case for CR 6855164 from its bug description In-Reply-To: <4A52363D.8030106@sun.com> References: <4A52363D.8030106@sun.com> Message-ID: <4A5253E6.6070805@sun.com> http://cr.openjdk.java.net/~cfang/6857707/webrev.00/ Problem & Solution: See subject. Thanks, Changpeng From Thomas.Rodriguez at Sun.COM Mon Jul 6 12:48:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 06 Jul 2009 12:48:58 -0700 Subject: Request for reviews (XS): 6857707 : Add missing test case for CR 6855164 from its bug description In-Reply-To: <4A5253E6.6070805@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> Message-ID: <5FF5D5FA-C7CE-4122-8D8F-C3792FB81D51@sun.com> looks good. tom On Jul 6, 2009, at 12:43 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6857707/webrev.00/ > > Problem & Solution: See subject. > > Thanks, > > Changpeng From Vladimir.Kozlov at Sun.COM Mon Jul 6 13:03:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 06 Jul 2009 13:03:47 -0700 Subject: Request for reviews (XS): 6857707 : Add missing test case for CR 6855164 from its bug description In-Reply-To: <4A5253E6.6070805@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> Message-ID: <4A5258A3.2080209@sun.com> Good. Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6857707/webrev.00/ > > Problem & Solution: See subject. > > Thanks, > > Changpeng > From Thomas.Rodriguez at Sun.COM Mon Jul 6 13:22:08 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 06 Jul 2009 13:22:08 -0700 Subject: Inconsistency between adr types of ideal and mach loads from conP In-Reply-To: <4A4D55B1.1020205@sun.com> References: <4A4CF567.2080405@sun.com> <4A4D55B1.1020205@sun.com> Message-ID: Shouldn't the assert you added a while back have caught this? Oh, I see it has a cutout for rawptr which would have kept it from checking. Why does this cutout exist? tom On Jul 2, 2009, at 5:49 PM, Vladimir Kozlov wrote: > Thanks, Tom > > the failed before compilation passed with this fix: > > @@ -300,6 +300,12 @@ const Node* MachNode::get_base_and_disp( > } > } > adr_type = t_disp->add_offset(offset); > + } else if( base == NULL && offset != 0 && offset != > Type::OffsetBot ) { > + // Use ideal type if it is ptr. > + const TypePtr *tp = oper->type()->isa_ptr(); > + if( tp != NULL ) { > + adr_type = tp; > + } > } > } > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I think MemNode::adr_type is the one we consider to be correct >> since that's the one used for all the optimizations. >> MachNode::adr_type needs to return the same answer or at least an >> equivalent answer from an aliasing standpoint. >> tom >> On Jul 2, 2009, at 10:59 AM, Vladimir Kozlov wrote: >>> While testing my changes for StoreOop macro node with CTW rt.jar >>> I hit this problem. >>> >>> In ideal graph load from ConP has exact adr type and its memory >>> edge is immutable memory: >>> >>> [t at 21 l at 21]: print m._new2old_map[133]->dump(2) >>> o3 Start === o3 o0 [[o3 o5 o6 o7 o8 o9 ]] #{0:control, >>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} >>> o73 Initialize === o3560 o1 o76 o1 o1 o1 o3561 [[o74 >>> o75 ]] >>> o97 ConP === o0 [[ ... o3500 ... ]] #java/lang/ >>> Class:exact * Oop:java/lang/Class:exact * >>> o7 Parm === o3 [[ ... o3500 o3510 ]] Memory Memory: >>> @BotPTR *+bot, idx=Bot; >>> o74 Proj === o73 [[o3504 o77 o3500 ]] #0 >>> o3500 LoadI === o74 o7 o97 [[o3501 o3514 o3752 o3530 >>> o3538 ]] @java/lang/Class:exact *, idx=11; #int >>> >>> [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()->dump() >>> java/lang/Class:exact * >>> >>> But corresponding mach load has rawptr type since the "direct" >>> address >>> has only offset "disp" and no base: >>> >>> [t at 21 l at 21]: print load->dump(2) >>> 91 Start === 91 1 [[ 91 90 92 ... ]] #{0:control, >>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms: >>> KeyStroke::getKeyStroke @ bci:17 MotifTextUI:: @ bci:14 >>> 68 Initialize === 69 0 124 0 0 0 125 [[ 67 >>> 144 ]] !jvms: MotifTextUI:: @ bci:6 >>> 92 MachProj === 91 [[ ... 113 ... ]] #2/unmatched >>> Memory: @BotPTR *+bot, idx=Bot; !jvms: MotifTextUI:: @ >>> bci:-1 >>> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched ! >>> jvms: MotifTextUI:: @ bci:6 >>> 133 loadI === 67 92 [[ 65 134 146 145 165 ]] java/lang/ >>> Class:exact * >>> >>> [t at 21 l at 21]: print load->adr_type()->dump() >>> rawptr:BotPTR >>> >>> class TypePtr* MachNode::adr_type() { >>> ... >>> // Direct addressing modes have no base node, simply an indirect >>> // offset, which is always to raw memory. >>> if (base == NULL) { >>> ... >>> // %%% make offset be intptr_t >>> assert(!Universe::heap()->is_in_reserved((oop)offset), "must be >>> a raw ptr"); >>> return TypeRawPtr::BOTTOM; >>> } >>> >>> >>> When the mach load is processed in >>> PhaseCFG::insert_anti_dependences() >>> it became anti-dep on the Initialize node (which also has >>> rawptr:BotPTR type) >>> at the same block: >>> >>> } else { >>> // Found a possibly-interfering store in the load's 'early' >>> block. >>> // This means 'load' cannot sink at all in the dominator tree. >>> // Add an anti-dep edge, and squeeze 'load' into the highest >>> block. >>> assert(store != load->in(0), "dependence cycle found"); >>> if (verify) { >>> assert(store->find_edge(load) != -1, "missing precedence >>> edge"); >>> } else { >>> store->add_prec(load); >>> } >>> >>> 68 Initialize === 69 0 124 0 0 0 125 | 133 >>> [[ 67 144 ]] !jvms: MotifTextUI:: @ bci:6 >>> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched ! >>> jvms: MotifTextUI:: @ bci:6 >>> 133 loadI === 67 92 [[ 65 134 146 145 165 68 ]] java/ >>> lang/Class:exact * >>> >>> And this screw up local scheduling since the load has the control >>> edge after the Initialize. >>> >>> Note: in 64-bit VM "direct" address mode is not available. >>> >>> Should I fix MemNode::adr_type() to return rawptr type for such >>> case or >>> MachNode::adr_type() to return exact type? >>> >>> Thanks, >>> Vladimir >>> From Changpeng.Fang at Sun.COM Mon Jul 6 15:06:03 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Mon, 06 Jul 2009 15:06:03 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A5253E6.6070805@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> Message-ID: <4A52754B.8020400@sun.com> http://cr.openjdk.java.net/~cfang/6833129/webrev.00/ Problem: The problem is in intrinsics Object.clone and Arrays.copyOf. When de-optimization occurs on the slow path for array/instance allocation, the Interpreter will continue execution in next bc after the slow allocation calls without actual copying. Solution: Add a restart bit in debuginfo to direct the deopt to restart execution of the bytecode that invokes Object.clone/Arrays.copyOf. The restart bit is set up in Inline Intrinsics of Object.clone/Arrays.copyOf. Tests: Passed specjvm98, JPRT and the test case of clone in the bug report. Thanks, Changpeng From Vladimir.Kozlov at Sun.COM Mon Jul 6 15:49:19 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 06 Jul 2009 15:49:19 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A52754B.8020400@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> Message-ID: <4A527F6F.4050304@sun.com> I would put "restart" variable at the same scope as the call since it is not used in src/share/vm/classfile/javaClasses.cpp I would add a comment about new decoding/encoding in src/share/vm/code/debugInfo.hpp The new code in src/share/vm/opto/bytecodeInfo.cpp should be an assert (not the flag setting) since the restart bytecode should be the top frame. assert(!caller_jvms->is_restart(), "there should be no restart bytecode with inlining"); Also in src/share/vm/opto/callnode.hpp add an assert to check that bci is no changed when _restart is set void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } We talked about using PreserveJVMState pjvms(this) instead of restoring stack and restart flag in intrinsics? Why you did not use it? thanks, Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.00/ > > Problem: > The problem is in intrinsics Object.clone and Arrays.copyOf. When > de-optimization occurs on the slow path for array/instance > allocation, the Interpreter will continue execution in next bc after the > slow allocation calls without actual copying. > > Solution: > Add a restart bit in debuginfo to direct the deopt to restart execution > of the bytecode that invokes Object.clone/Arrays.copyOf. > The restart bit is set up in Inline Intrinsics of > Object.clone/Arrays.copyOf. > > Tests: > Passed specjvm98, JPRT and the test case of clone in the bug report. > > Thanks, > > Changpeng > From changpeng.fang at sun.com Mon Jul 6 17:09:53 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Tue, 07 Jul 2009 00:09:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6857707: Add missing test case for CR 6855164 from its bug description. Message-ID: <20090707001002.72E23EC69@hg.openjdk.java.net> Changeset: 73dac61fe300 Author: cfang Date: 2009-07-06 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/73dac61fe300 6857707: Add missing test case for CR 6855164 from its bug description. Summary: Add missing test case for CR 6855164 from its bug description. Reviewed-by: never + test/compiler/6855164/Test.java From Changpeng.Fang at Sun.COM Mon Jul 6 17:21:46 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Mon, 06 Jul 2009 17:21:46 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A527F6F.4050304@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> Message-ID: <4A52951A.5070409@sun.com> http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ On 07/06/09 15:49, Vladimir Kozlov wrote: > I would put "restart" variable at the same scope as > the call since it is not used in > src/share/vm/classfile/javaClasses.cpp > > I would add a comment about new decoding/encoding in > src/share/vm/code/debugInfo.hpp > > The new code in src/share/vm/opto/bytecodeInfo.cpp > should be an assert (not the flag setting) since > the restart bytecode should be the top frame. > assert(!caller_jvms->is_restart(), "there should be no restart > bytecode with inlining"); > Thanks. > Also in src/share/vm/opto/callnode.hpp add an assert > to check that bci is no changed when _restart is set > void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } Do you meant the restart bit must be false at the time that we set up bci? > We talked about using PreserveJVMState pjvms(this) instead > of restoring stack and restart flag in intrinsics? > Why you did not use it? Just as we discussed a moment ago, I added an assert restart false before we set it to true. Here is the updated webrev link! http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ Thanks, Changpeng > thanks, > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6833129/webrev.00/ >> >> Problem: >> The problem is in intrinsics Object.clone and Arrays.copyOf. When >> de-optimization occurs on the slow path for array/instance >> allocation, the Interpreter will continue execution in next bc after >> the slow allocation calls without actual copying. >> >> Solution: >> Add a restart bit in debuginfo to direct the deopt to restart >> execution of the bytecode that invokes Object.clone/Arrays.copyOf. >> The restart bit is set up in Inline Intrinsics of >> Object.clone/Arrays.copyOf. >> >> Tests: >> Passed specjvm98, JPRT and the test case of clone in the bug report. >> >> Thanks, >> >> Changpeng >> From Vladimir.Kozlov at Sun.COM Mon Jul 6 17:55:11 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 06 Jul 2009 17:55:11 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A52951A.5070409@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> Message-ID: <4A529CEF.4090507@sun.com> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> Also in src/share/vm/opto/callnode.hpp add an assert >> to check that bci is no changed when _restart is set >> void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } > Do you meant the restart bit must be false at the time that we > set up bci? Yes, it should be false when we set or change bci. Since _bci field is private it could be changed only by set_bci(). Your changes look good but you need an additional reviews before the push. Thanks, Vladimir > >> We talked about using PreserveJVMState pjvms(this) instead >> of restoring stack and restart flag in intrinsics? >> Why you did not use it? > Just as we discussed a moment ago, I added an assert restart false before > we set it to true. > > Here is the updated webrev link! > http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ > > Thanks, > > Changpeng > >> thanks, >> Vladimir >> >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> http://cr.openjdk.java.net/~cfang/6833129/webrev.00/ >>> >>> Problem: >>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>> de-optimization occurs on the slow path for array/instance >>> allocation, the Interpreter will continue execution in next bc after >>> the slow allocation calls without actual copying. >>> >>> Solution: >>> Add a restart bit in debuginfo to direct the deopt to restart >>> execution of the bytecode that invokes Object.clone/Arrays.copyOf. >>> The restart bit is set up in Inline Intrinsics of >>> Object.clone/Arrays.copyOf. >>> >>> Tests: >>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>> >>> Thanks, >>> >>> Changpeng >>> > From Vladimir.Kozlov at Sun.COM Mon Jul 6 18:06:46 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 06 Jul 2009 18:06:46 -0700 Subject: Inconsistency between adr types of ideal and mach loads from conP In-Reply-To: References: <4A4CF567.2080405@sun.com> <4A4D55B1.1020205@sun.com> Message-ID: <4A529FA6.5050906@sun.com> I can't recall it now but most likely I thought rawptr mismatching does not affect code correctness. The cutout is not needed with the suggested fix. Vladimir Tom Rodriguez wrote: > Shouldn't the assert you added a while back have caught this? Oh, I see > it has a cutout for rawptr which would have kept it from checking. Why > does this cutout exist? > > tom > > On Jul 2, 2009, at 5:49 PM, Vladimir Kozlov wrote: > >> Thanks, Tom >> >> the failed before compilation passed with this fix: >> >> @@ -300,6 +300,12 @@ const Node* MachNode::get_base_and_disp( >> } >> } >> adr_type = t_disp->add_offset(offset); >> + } else if( base == NULL && offset != 0 && offset != >> Type::OffsetBot ) { >> + // Use ideal type if it is ptr. >> + const TypePtr *tp = oper->type()->isa_ptr(); >> + if( tp != NULL ) { >> + adr_type = tp; >> + } >> } >> } >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> I think MemNode::adr_type is the one we consider to be correct since >>> that's the one used for all the optimizations. MachNode::adr_type >>> needs to return the same answer or at least an equivalent answer from >>> an aliasing standpoint. >>> tom >>> On Jul 2, 2009, at 10:59 AM, Vladimir Kozlov wrote: >>>> While testing my changes for StoreOop macro node with CTW rt.jar >>>> I hit this problem. >>>> >>>> In ideal graph load from ConP has exact adr type and its memory >>>> edge is immutable memory: >>>> >>>> [t at 21 l at 21]: print m._new2old_map[133]->dump(2) >>>> o3 Start === o3 o0 [[o3 o5 o6 o7 o8 o9 ]] #{0:control, >>>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} >>>> o73 Initialize === o3560 o1 o76 o1 o1 o1 o3561 [[o74 o75 ]] >>>> o97 ConP === o0 [[ ... o3500 ... ]] #java/lang/Class:exact >>>> * Oop:java/lang/Class:exact * >>>> o7 Parm === o3 [[ ... o3500 o3510 ]] Memory Memory: >>>> @BotPTR *+bot, idx=Bot; >>>> o74 Proj === o73 [[o3504 o77 o3500 ]] #0 >>>> o3500 LoadI === o74 o7 o97 [[o3501 o3514 o3752 o3530 o3538 ]] >>>> @java/lang/Class:exact *, idx=11; #int >>>> >>>> [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()->dump() >>>> java/lang/Class:exact * >>>> >>>> But corresponding mach load has rawptr type since the "direct" address >>>> has only offset "disp" and no base: >>>> >>>> [t at 21 l at 21]: print load->dump(2) >>>> 91 Start === 91 1 [[ 91 90 92 ... ]] #{0:control, >>>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms: >>>> KeyStroke::getKeyStroke @ bci:17 MotifTextUI:: @ bci:14 >>>> 68 Initialize === 69 0 124 0 0 0 125 [[ 67 144 ]] >>>> !jvms: MotifTextUI:: @ bci:6 >>>> 92 MachProj === 91 [[ ... 113 ... ]] #2/unmatched >>>> Memory: @BotPTR *+bot, idx=Bot; !jvms: MotifTextUI:: @ bci:-1 >>>> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched >>>> !jvms: MotifTextUI:: @ bci:6 >>>> 133 loadI === 67 92 [[ 65 134 146 145 165 ]] >>>> java/lang/Class:exact * >>>> >>>> [t at 21 l at 21]: print load->adr_type()->dump() >>>> rawptr:BotPTR >>>> >>>> class TypePtr* MachNode::adr_type() { >>>> ... >>>> // Direct addressing modes have no base node, simply an indirect >>>> // offset, which is always to raw memory. >>>> if (base == NULL) { >>>> ... >>>> // %%% make offset be intptr_t >>>> assert(!Universe::heap()->is_in_reserved((oop)offset), "must be a >>>> raw ptr"); >>>> return TypeRawPtr::BOTTOM; >>>> } >>>> >>>> >>>> When the mach load is processed in PhaseCFG::insert_anti_dependences() >>>> it became anti-dep on the Initialize node (which also has >>>> rawptr:BotPTR type) >>>> at the same block: >>>> >>>> } else { >>>> // Found a possibly-interfering store in the load's 'early' block. >>>> // This means 'load' cannot sink at all in the dominator tree. >>>> // Add an anti-dep edge, and squeeze 'load' into the highest block. >>>> assert(store != load->in(0), "dependence cycle found"); >>>> if (verify) { >>>> assert(store->find_edge(load) != -1, "missing precedence edge"); >>>> } else { >>>> store->add_prec(load); >>>> } >>>> >>>> 68 Initialize === 69 0 124 0 0 0 125 | 133 [[ 67 >>>> 144 ]] !jvms: MotifTextUI:: @ bci:6 >>>> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched >>>> !jvms: MotifTextUI:: @ bci:6 >>>> 133 loadI === 67 92 [[ 65 134 146 145 165 68 ]] >>>> java/lang/Class:exact * >>>> >>>> And this screw up local scheduling since the load has the control >>>> edge after the Initialize. >>>> >>>> Note: in 64-bit VM "direct" address mode is not available. >>>> >>>> Should I fix MemNode::adr_type() to return rawptr type for such case or >>>> MachNode::adr_type() to return exact type? >>>> >>>> Thanks, >>>> Vladimir >>>> > From vladimir.kozlov at sun.com Mon Jul 6 18:19:33 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 07 Jul 2009 01:19:33 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6857661: 64-bit server VM: assert(is_Initialize(), "invalid node class") Message-ID: <20090707011940.7C437EC77@hg.openjdk.java.net> Changeset: 4325cdaa78ad Author: kvn Date: 2009-07-06 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4325cdaa78ad 6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class") Summary: Move the secondary raw memory barrier to the correct place in generate_arraycopy(). Reviewed-by: never ! src/share/vm/opto/library_call.cpp From John.Rose at Sun.COM Mon Jul 6 22:52:56 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 06 Jul 2009 22:52:56 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A52951A.5070409@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> Message-ID: On Jul 6, 2009, at 5:21 PM, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ Here's a nit: is_restart() in scopeDesc.hpp should be a const function. I'd like to see comment in each case demonstrating why that the values captured in dummy_restart, and the throwaway restart in javaClasses.cpp (which should be called dummy_restart also) don't matter. I'd still like to see the restart decision made by continuation_for turned into an assert. At least compare it with is_restart(): > pc = Interpreter::continuation_for(method(), bcp, > callee_parameters, is_top_frame, use_next_mdp); > + assert(is_restart() == !use_next_mdp, ""); If the assert fails, there may be a bug. -- John From Changpeng.Fang at Sun.COM Tue Jul 7 09:00:56 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 07 Jul 2009 09:00:56 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> Message-ID: <4A537138.4000500@sun.com> On 07/06/09 22:52, John Rose wrote: > On Jul 6, 2009, at 5:21 PM, changpeng fang - Sun Microsystems - Santa > Clara United States wrote: > >> http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ > > Here's a nit: is_restart() in scopeDesc.hpp should be a const function. > Yes. Don't know how could I missed that. Thanks. > I'd like to see comment in each case demonstrating why that the values > captured in dummy_restart, and the throwaway restart in > javaClasses.cpp (which should be called dummy_restart also) don't matter. > They are not going to participate in restart/continue decision. Yes, it is better to write some comments there for better understanding and/or potential future situation changes. Thanks. > I'd still like to see the restart decision made by continuation_for > turned into an assert. At least compare it with is_restart(): > >> pc = Interpreter::continuation_for(method(), bcp, >> callee_parameters, is_top_frame, use_next_mdp); >> + assert(is_restart() == !use_next_mdp, ""); > If the assert fails, there may be a bug. > Yes, it is a little confusion here. I know you want the restart decisions all made by the compilers (the right approach and we will definitely do it). You may have already noticed that the restart bits are all zero in the C1 interface, and for C2, only intrinsics Object.clone and Arrays.copyOf turned on their restart bits. As a result, this work just sets up the framework with the necessary logics to fix this bug. > -- John From Thomas.Rodriguez at Sun.COM Tue Jul 7 13:09:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 07 Jul 2009 13:09:37 -0700 Subject: Inconsistency between adr types of ideal and mach loads from conP In-Reply-To: <4A529FA6.5050906@sun.com> References: <4A4CF567.2080405@sun.com> <4A4D55B1.1020205@sun.com> <4A529FA6.5050906@sun.com> Message-ID: Sounds good. tom On Jul 6, 2009, at 6:06 PM, Vladimir Kozlov wrote: > I can't recall it now but most likely I thought rawptr mismatching > does not affect code correctness. > The cutout is not needed with the suggested fix. > > Vladimir > > Tom Rodriguez wrote: >> Shouldn't the assert you added a while back have caught this? Oh, >> I see it has a cutout for rawptr which would have kept it from >> checking. Why does this cutout exist? >> tom >> On Jul 2, 2009, at 5:49 PM, Vladimir Kozlov wrote: >>> Thanks, Tom >>> >>> the failed before compilation passed with this fix: >>> >>> @@ -300,6 +300,12 @@ const Node* MachNode::get_base_and_disp( >>> } >>> } >>> adr_type = t_disp->add_offset(offset); >>> + } else if( base == NULL && offset != 0 && offset != >>> Type::OffsetBot ) { >>> + // Use ideal type if it is ptr. >>> + const TypePtr *tp = oper->type()->isa_ptr(); >>> + if( tp != NULL ) { >>> + adr_type = tp; >>> + } >>> } >>> } >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I think MemNode::adr_type is the one we consider to be correct >>>> since that's the one used for all the optimizations. >>>> MachNode::adr_type needs to return the same answer or at least an >>>> equivalent answer from an aliasing standpoint. >>>> tom >>>> On Jul 2, 2009, at 10:59 AM, Vladimir Kozlov wrote: >>>>> While testing my changes for StoreOop macro node with CTW rt.jar >>>>> I hit this problem. >>>>> >>>>> In ideal graph load from ConP has exact adr type and its memory >>>>> edge is immutable memory: >>>>> >>>>> [t at 21 l at 21]: print m._new2old_map[133]->dump(2) >>>>> o3 Start === o3 o0 [[o3 o5 o6 o7 o8 o9 ]] #{0:control, >>>>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} >>>>> o73 Initialize === o3560 o1 o76 o1 o1 o1 o3561 [[o74 >>>>> o75 ]] >>>>> o97 ConP === o0 [[ ... o3500 ... ]] #java/lang/ >>>>> Class:exact * Oop:java/lang/Class:exact * >>>>> o7 Parm === o3 [[ ... o3500 o3510 ]] Memory Memory: >>>>> @BotPTR *+bot, idx=Bot; >>>>> o74 Proj === o73 [[o3504 o77 o3500 ]] #0 >>>>> o3500 LoadI === o74 o7 o97 [[o3501 o3514 o3752 o3530 >>>>> o3538 ]] @java/lang/Class:exact *, idx=11; #int >>>>> >>>>> [t at 21 l at 21]: print m._new2old_map[133]->as_Mem()->adr_type()- >>>>> >dump() >>>>> java/lang/Class:exact * >>>>> >>>>> But corresponding mach load has rawptr type since the "direct" >>>>> address >>>>> has only offset "disp" and no base: >>>>> >>>>> [t at 21 l at 21]: print load->dump(2) >>>>> 91 Start === 91 1 [[ 91 90 92 ... ]] #{0:control, >>>>> 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address} !jvms: >>>>> KeyStroke::getKeyStroke @ bci:17 MotifTextUI:: @ bci:14 >>>>> 68 Initialize === 69 0 124 0 0 0 125 [[ 67 >>>>> 144 ]] !jvms: MotifTextUI:: @ bci:6 >>>>> 92 MachProj === 91 [[ ... 113 ... ]] #2/ >>>>> unmatched Memory: @BotPTR *+bot, idx=Bot; !jvms: >>>>> MotifTextUI:: @ bci:-1 >>>>> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched ! >>>>> jvms: MotifTextUI:: @ bci:6 >>>>> 133 loadI === 67 92 [[ 65 134 146 145 165 ]] java/ >>>>> lang/Class:exact * >>>>> >>>>> [t at 21 l at 21]: print load->adr_type()->dump() >>>>> rawptr:BotPTR >>>>> >>>>> class TypePtr* MachNode::adr_type() { >>>>> ... >>>>> // Direct addressing modes have no base node, simply an indirect >>>>> // offset, which is always to raw memory. >>>>> if (base == NULL) { >>>>> ... >>>>> // %%% make offset be intptr_t >>>>> assert(!Universe::heap()->is_in_reserved((oop)offset), "must be >>>>> a raw ptr"); >>>>> return TypeRawPtr::BOTTOM; >>>>> } >>>>> >>>>> >>>>> When the mach load is processed in >>>>> PhaseCFG::insert_anti_dependences() >>>>> it became anti-dep on the Initialize node (which also has >>>>> rawptr:BotPTR type) >>>>> at the same block: >>>>> >>>>> } else { >>>>> // Found a possibly-interfering store in the load's 'early' >>>>> block. >>>>> // This means 'load' cannot sink at all in the dominator tree. >>>>> // Add an anti-dep edge, and squeeze 'load' into the highest >>>>> block. >>>>> assert(store != load->in(0), "dependence cycle found"); >>>>> if (verify) { >>>>> assert(store->find_edge(load) != -1, "missing precedence >>>>> edge"); >>>>> } else { >>>>> store->add_prec(load); >>>>> } >>>>> >>>>> 68 Initialize === 69 0 124 0 0 0 125 | 133 >>>>> [[ 67 144 ]] !jvms: MotifTextUI:: @ bci:6 >>>>> 67 MachProj === 68 [[ 63 133 168 ]] #0/unmatched ! >>>>> jvms: MotifTextUI:: @ bci:6 >>>>> 133 loadI === 67 92 [[ 65 134 146 145 165 68 ]] >>>>> java/lang/Class:exact * >>>>> >>>>> And this screw up local scheduling since the load has the control >>>>> edge after the Initialize. >>>>> >>>>> Note: in 64-bit VM "direct" address mode is not available. >>>>> >>>>> Should I fix MemNode::adr_type() to return rawptr type for such >>>>> case or >>>>> MachNode::adr_type() to return exact type? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> From Thomas.Rodriguez at Sun.COM Tue Jul 7 13:33:32 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 07 Jul 2009 13:33:32 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A52951A.5070409@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> Message-ID: <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> I think the term reexecute should be used in place of restart since that terminology is used elsewhere. Actually I think should_reexecute is better than is_reexecute as well. I don't really like that the restart bit is associated with the bci. It implies that any scope can be reexecuted when it fact it's only the topmost one that can be. Given how these describing scopes is structured I'm not sure I see a better way though. I don't see any asserts to enforce this for the scopeDescs either. The printing forms for ScopeDesc and JVMState should indicate if this is a restarted bytecode or not. The SA also needs to be updated to read these modified ScopeDescs. >> We talked about using PreserveJVMState pjvms(this) instead >> of restoring stack and restart flag in intrinsics? >> Why you did not use it? > Just as we discussed a moment ago, I added an assert restart false > before > we set it to true. I think manually toggling the restart bit back and forth should be avoided. Preserve the original and pass on the modified one or have a helper object that toggles the bit in it's constructor/destructor. tom > > Here is the updated webrev link! > http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ > > Thanks, > > Changpeng > >> thanks, >> Vladimir >> >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> http://cr.openjdk.java.net/~cfang/6833129/webrev.00/ >>> >>> Problem: >>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>> de-optimization occurs on the slow path for array/instance >>> allocation, the Interpreter will continue execution in next bc >>> after the slow allocation calls without actual copying. >>> >>> Solution: >>> Add a restart bit in debuginfo to direct the deopt to restart >>> execution of the bytecode that invokes Object.clone/Arrays.copyOf. >>> The restart bit is set up in Inline Intrinsics of Object.clone/ >>> Arrays.copyOf. >>> >>> Tests: >>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>> >>> Thanks, >>> >>> Changpeng >>> > From Thomas.Rodriguez at Sun.COM Tue Jul 7 13:34:55 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 07 Jul 2009 13:34:55 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A537138.4000500@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <4A537138.4000500@sun.com> Message-ID: <33D7C0B3-89B6-4E90-8BE1-DB38B0756EB9@sun.com> >> I'd still like to see the restart decision made by continuation_for >> turned into an assert. At least compare it with is_restart(): >> >>> pc = Interpreter::continuation_for(method(), bcp, >>> callee_parameters, is_top_frame, use_next_mdp); >>> + assert(is_restart() == !use_next_mdp, ""); >> If the assert fails, there may be a bug. >> > Yes, it is a little confusion here. I know you want the restart > decisions all made by the compilers (the right approach and we will > definitely do it). You may have already noticed that the restart > bits are all zero in the C1 interface, and for C2, only > intrinsics Object.clone and Arrays.copyOf turned on their restart > bits. As a result, this work just sets up the framework with the > necessary logics to fix this bug. Are you saying a separate fix will finish this? Why? This should all be done at once and I think we want some strong asserts to guarantee that reexecute is only used in the way we expect it to be. tom > >> -- John > From vladimir.kozlov at sun.com Tue Jul 7 15:01:07 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Tue, 07 Jul 2009 22:01:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 5 new changesets Message-ID: <20090707220122.72A29ECBD@hg.openjdk.java.net> Changeset: 30b9b25b9cc1 Author: tonyp Date: 2009-06-24 11:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/30b9b25b9cc1 6850869: G1: RSet "scrubbing" scrubs too much Summary: RSet scrubbing incorrectly deletes RSet entries that point to regions tagged as "continues humongous" due to a race when RSet scrubbing iterates over regions in parallel. Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 00f7ec32f290 Author: apetrusenko Date: 2009-06-26 09:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/00f7ec32f290 6854027: Precompiled headers are not being updated in Linux/GCC builds Summary: Fixes incorrect handling of precompiled headers in diff mode. Reviewed-by: never, twisti ! src/share/tools/MakeDeps/Database.java Changeset: 3eb9872b10ce Author: tonyp Date: 2009-06-29 12:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3eb9872b10ce 6855115: G1: Fix for 6850869 is incorrect Summary: Missed updating two variable names when improving the code for 6850869. Reviewed-by: iveresov, jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: e7d5557ad624 Author: jmasa Date: 2009-07-02 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e7d5557ad624 Merge Changeset: f0bd02f95856 Author: kvn Date: 2009-07-07 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f0bd02f95856 Merge From Vladimir.Kozlov at Sun.COM Tue Jul 7 18:44:41 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 07 Jul 2009 18:44:41 -0700 Subject: Request for reviews (L): 6851742: (EA) allocation elimination doesn't work with UseG1GC Message-ID: <4A53FA09.9020602@sun.com> http://cr.openjdk.java.net/~kvn/6851742/webrev.02 Fixed 6851742: (EA) allocation elimination doesn't work with UseG1GC Problem: EA expects only card mark store after oop store but barriers for G1 are much more complex. Solution: - Generate a new macro node StoreOop for a oop store when G1 is used and expand it after an allocation elimination. Use membar node after StoreOop node to keep track of raw memory and control edges needed during StoreOop expansion. Do not generate post barrier if StoreOop node is followed by an other StoreOop for the same object. - Move barriers code generation into IdealKit class since it is used now by graphKit and macroExpand. - Check IGVN delay_transform flag in IdealKit when setting bottom_type for new nodes. - Don't clone memory around leaf call in IdealKit since it modifies only raw memory. - Explicitly remove the original merge region in IfNode split_if() otherwise it will not be removed if it has dead users and it will cause unique_ctrl_out() to return an incorrect result. - Fix IdealKit code in LibraryCallKit::inline_unsafe_access() which produced incorrect graph. - Fix MachNode::adr_type for direct addressing modes to use ideal type if it is ptr. And remove rawptr cutout in mach node adr type verification code. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT, CTW +G1 +EA 32-bit 64-bit From Christian.Thalinger at Sun.COM Wed Jul 8 07:41:32 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 08 Jul 2009 16:41:32 +0200 Subject: Request for reviews (L): 6829187: compiler optimizations required for JSR 292 Message-ID: <4A54B01C.6060900@Sun.COM> Here is the inlining part of the invokedynamic compiler support: http://cr.openjdk.java.net/~twisti/6829187/webrev.01/ I'm using 6829187 here since inlining is part of the compiler support, but I can open another CR if required. -- Christian From tiark.rompf at epfl.ch Wed Jul 8 08:42:35 2009 From: tiark.rompf at epfl.ch (Tiark Rompf) Date: Wed, 8 Jul 2009 17:42:35 +0200 Subject: Escape analysis/scalar replacement question Message-ID: <32294B9E-F4EA-49FF-B68E-4450DE6D7095@epfl.ch> Hi, we're currently reworking parts of the Scala collections library and there are a couple of places that would profit greatly from escape analysis and scalar replacement. For some cases, -XX:+DoEscapeAnalysis already gives very good speedups, but we're frequently encountering situations where the hotspot compiler fails to eliminate allocations although it should be safe to do so. Here is a simplified example: final class VectorStub { int index; } class Test1 { void test() { VectorStub it = new VectorStub(); int max = 1000; while (it.index != max) { int cur = it.index; it = new VectorStub(); it.index = cur + 1; } } } Clearly, none of the allocated objects can escape, but scalar replacement does not take place. It does, however, when I pull the current index out of the loop into a local variable: class Test2 { void test() { VectorStub it = new VectorStub(); int max = 1000; int cur = it.index; while (it.index != max) { it = new VectorStub(); it.index = cur + 1; cur = it.index; } } } Browsing the hotspot source code revealed that encountering an AddP node whose inputs might stem from different allocation sites will mark these allocations as ArgEscape. Looking at the ideal graph representation of the above code shows that this is indeed what prevents scalar replacement: Allocate Allocate | | Initialize Initialize | | CheckCastPP | | / | CheckCastPP | / Phi | CastPP || AddP | LoadI ... Pushing the AddP through to beyond the Phi does the trick in this case, so my question is whether something can be done about in general. I've been talking about this briefly with Cliff Click at ECOOP yesterday, and he said it should not be too much work to fix it. So, is there a chance of seeing this improved in the not too distant future? Thanks in advance, - Tiark From Vladimir.Kozlov at Sun.COM Wed Jul 8 09:40:21 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 08 Jul 2009 09:40:21 -0700 Subject: Escape analysis/scalar replacement question In-Reply-To: <32294B9E-F4EA-49FF-B68E-4450DE6D7095@epfl.ch> References: <32294B9E-F4EA-49FF-B68E-4450DE6D7095@epfl.ch> Message-ID: <4A54CBF5.1080107@sun.com> Hi, Tiark What you are asking is split through Phi optimization for AddP and LoadI nodes. Currently this optimization is done during IGVN optimization after EA is done and only for referencing one non escaping allocation (for example, without the allocation inside the loop for your case). But I agree that such optimization could be done for your case. We have a plan for next few months to work on improvement of EA and we will consider your case also. Thanks, Vladimir Tiark Rompf wrote: > Hi, > > we're currently reworking parts of the Scala collections library and > there are a couple of places that would profit greatly from escape > analysis and scalar replacement. For some cases, -XX:+DoEscapeAnalysis > already gives very good speedups, but we're frequently encountering > situations where the hotspot compiler fails to eliminate allocations > although it should be safe to do so. Here is a simplified example: > > final class VectorStub { > int index; > } > > class Test1 { > void test() { > VectorStub it = new VectorStub(); > int max = 1000; > while (it.index != max) { > int cur = it.index; > it = new VectorStub(); > it.index = cur + 1; > } > } > } > > Clearly, none of the allocated objects can escape, but scalar > replacement does not take place. It does, however, when I pull the > current index out of the loop into a local variable: > > class Test2 { > void test() { > VectorStub it = new VectorStub(); > int max = 1000; > int cur = it.index; > while (it.index != max) { > it = new VectorStub(); > it.index = cur + 1; > cur = it.index; > } > } > } > > > Browsing the hotspot source code revealed that encountering an AddP node > whose inputs might stem from different allocation sites will mark these > allocations as ArgEscape. Looking at the ideal graph representation of > the above code shows that this is indeed what prevents scalar replacement: > > Allocate Allocate > | | > Initialize Initialize > | | > CheckCastPP | > | / > | CheckCastPP > | / > Phi > | > CastPP > || > AddP > | > LoadI > ... > > Pushing the AddP through to beyond the Phi does the trick in this case, > so my question is whether something can be done about in general. I've > been talking about this briefly with Cliff Click at ECOOP yesterday, and > he said it should not be too much work to fix it. > > So, is there a chance of seeing this improved in the not too distant > future? > > Thanks in advance, > - Tiark From Vladimir.Kozlov at Sun.COM Wed Jul 8 09:55:30 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 08 Jul 2009 09:55:30 -0700 Subject: Request for reviews (L): 6829187: compiler optimizations required for JSR 292 In-Reply-To: <4A54B01C.6060900@Sun.COM> References: <4A54B01C.6060900@Sun.COM> Message-ID: <4A54CF82.4040903@sun.com> Looks good Vladimir Christian Thalinger wrote: > Here is the inlining part of the invokedynamic compiler support: > > http://cr.openjdk.java.net/~twisti/6829187/webrev.01/ > > I'm using 6829187 here since inlining is part of the compiler support, > but I can open another CR if required. > > -- Christian From tiark.rompf at epfl.ch Thu Jul 9 00:09:41 2009 From: tiark.rompf at epfl.ch (Tiark Rompf) Date: Thu, 9 Jul 2009 09:09:41 +0200 Subject: Escape analysis/scalar replacement question In-Reply-To: <4A54CBF5.1080107@sun.com> References: <32294B9E-F4EA-49FF-B68E-4450DE6D7095@epfl.ch> <4A54CBF5.1080107@sun.com> Message-ID: Vladimir, thank you very much for your reply! Please keep me posted if there are any major EA improvement news. - Tiark On 08.07.2009, at 18:40, Vladimir Kozlov wrote: > Hi, Tiark > > What you are asking is split through Phi optimization > for AddP and LoadI nodes. Currently this optimization is > done during IGVN optimization after EA is done and only > for referencing one non escaping allocation (for example, > without the allocation inside the loop for your case). > But I agree that such optimization could be done for your case. > > We have a plan for next few months to work on improvement > of EA and we will consider your case also. > > Thanks, > Vladimir > > Tiark Rompf wrote: >> Hi, >> >> we're currently reworking parts of the Scala collections library and >> there are a couple of places that would profit greatly from escape >> analysis and scalar replacement. For some cases, -XX: >> +DoEscapeAnalysis >> already gives very good speedups, but we're frequently encountering >> situations where the hotspot compiler fails to eliminate allocations >> although it should be safe to do so. Here is a simplified example: >> >> final class VectorStub { >> int index; >> } >> >> class Test1 { >> void test() { >> VectorStub it = new VectorStub(); >> int max = 1000; >> while (it.index != max) { >> int cur = it.index; >> it = new VectorStub(); >> it.index = cur + 1; >> } >> } >> } >> >> Clearly, none of the allocated objects can escape, but scalar >> replacement does not take place. It does, however, when I pull the >> current index out of the loop into a local variable: >> >> class Test2 { >> void test() { >> VectorStub it = new VectorStub(); >> int max = 1000; >> int cur = it.index; >> while (it.index != max) { >> it = new VectorStub(); >> it.index = cur + 1; >> cur = it.index; >> } >> } >> } >> >> >> Browsing the hotspot source code revealed that encountering an AddP >> node >> whose inputs might stem from different allocation sites will mark >> these >> allocations as ArgEscape. Looking at the ideal graph representation >> of >> the above code shows that this is indeed what prevents scalar >> replacement: >> >> Allocate Allocate >> | | >> Initialize Initialize >> | | >> CheckCastPP | >> | / >> | CheckCastPP >> | / >> Phi >> | >> CastPP >> || >> AddP >> | >> LoadI >> ... >> >> Pushing the AddP through to beyond the Phi does the trick in this >> case, >> so my question is whether something can be done about in general. >> I've >> been talking about this briefly with Cliff Click at ECOOP >> yesterday, and >> he said it should not be too much work to fix it. >> >> So, is there a chance of seeing this improved in the not too distant >> future? >> >> Thanks in advance, >> - Tiark From Changpeng.Fang at Sun.COM Thu Jul 9 14:41:36 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Thu, 09 Jul 2009 14:41:36 -0700 Subject: Request for reviews (M): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> Message-ID: <4A566410.70200@sun.com> On 07/07/09 13:33, Tom Rodriguez wrote: > I think the term reexecute should be used in place of restart since > that terminology is used elsewhere. Actually I think should_reexecute > is better than is_reexecute as well. > I will use reexecute and should_reexecute throughout the change. Thanks. > I don't really like that the restart bit is associated with the bci. > It implies that any scope can be reexecuted when it fact it's only the > topmost one that can be. Given how these describing scopes is > structured I'm not sure I see a better way though. I don't see any > asserts to enforce this for the scopeDescs either. Do you mean assert like this : assert(!_reexecute || is_top(), "reexecute only applies to top scope"); If yes, then I must have something wrong in setting up the reexecute bit in JVMState in C2. > > The printing forms for ScopeDesc and JVMState should indicate if this > is a restarted bytecode or not. The SA also needs to be updated to > read these modified ScopeDescs. > There may be some bugs in JVMState::dump()! I will investigate it and add the reexecute bit. >>> We talked about using PreserveJVMState pjvms(this) instead >>> of restoring stack and restart flag in intrinsics? >>> Why you did not use it? >> Just as we discussed a moment ago, I added an assert restart false >> before >> we set it to true. > > I think manually toggling the restart bit back and forth should be > avoided. Preserve the original and pass on the modified one or have a > helper object that toggles the bit in it's constructor/destructor. > I prefer "Preserve the original and pass on the modified one". We can not use PreserveJVMState only for the purpose of preserving _sp (the map will be changed during the scope of preservation, and may cause undesired consequence). Thanks, Changpeng > tom > >> >> Here is the updated webrev link! >> http://cr.openjdk.java.net/~cfang/6833129/webrev.01/ >> >> Thanks, >> >> Changpeng >> >>> thanks, >>> Vladimir >>> >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.00/ >>>> >>>> Problem: >>>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>>> de-optimization occurs on the slow path for array/instance >>>> allocation, the Interpreter will continue execution in next bc >>>> after the slow allocation calls without actual copying. >>>> >>>> Solution: >>>> Add a restart bit in debuginfo to direct the deopt to restart >>>> execution of the bytecode that invokes Object.clone/Arrays.copyOf. >>>> The restart bit is set up in Inline Intrinsics of >>>> Object.clone/Arrays.copyOf. >>>> >>>> Tests: >>>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >> > From Christian.Thalinger at Sun.COM Fri Jul 10 07:41:47 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 10 Jul 2009 16:41:47 +0200 Subject: x86_32 OptoRuntime::generate_exception_blob() unnecessary second get_thread() call? Message-ID: <4A57532B.3030506@Sun.COM> Hi! While changing something in OptoRuntime::generate_exception_blob() in runtime_x86_32.cpp I noticed that there are two calls to get_thread() and the second call happens while the register from the first call still holds the value. I don't see any reason why this is necessary, even when the stack changes slightly in between and the _sp_map on Linux would be indexed with another value, the thread value has to be the same. Am I missing something here or could the second call be removed safely? -- Christian From Christian.Thalinger at Sun.COM Fri Jul 10 09:34:32 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 10 Jul 2009 18:34:32 +0200 Subject: Request for reviews (L): 6829187: compiler optimizations required for JSR 292 In-Reply-To: <4A54B01C.6060900@Sun.COM> References: <4A54B01C.6060900@Sun.COM> Message-ID: <4A576D98.605@Sun.COM> Christian Thalinger wrote: > Here is the inlining part of the invokedynamic compiler support: > > http://cr.openjdk.java.net/~twisti/6829187/webrev.01/ To review my own patch, I'm not sure this is correct: + // Currently we online support DirectMethodHandles which are + // bound to a methodOop. + if (!method_handle->does_dispatch()) { I think there is another check missing since the last MethodHandle in a chain can be a DirectMethodHandle which does not do a dispatch but I'm not taking care of the MethodHandles before, which could bind arguments or whatever. Maybe something like? !does_dispatch && !binds_arguments && !adapter -- Christian From John.Rose at Sun.COM Fri Jul 10 11:55:28 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 10 Jul 2009 11:55:28 -0700 Subject: x86_32 OptoRuntime::generate_exception_blob() unnecessary second get_thread() call? In-Reply-To: <4A57532B.3030506@Sun.COM> References: <4A57532B.3030506@Sun.COM> Message-ID: <48F4D60E-A46D-4501-95A3-938254AC7597@sun.com> On Jul 10, 2009, at 7:41 AM, Christian Thalinger wrote: > While changing something in OptoRuntime::generate_exception_blob() in > runtime_x86_32.cpp I noticed that there are two calls to get_thread() > and the second call happens while the register from the first call > still > holds the value. There are three calls to get_thread(rcx). The first and second are separated by a call to handle_exception_C, which presumably blows rcx. I think you are right that the third get_thread duplicates the result of the second. And this comment appears to be false: // rcx contains handler address -- John From Christian.Thalinger at Sun.COM Fri Jul 10 12:04:26 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 10 Jul 2009 21:04:26 +0200 Subject: x86_32 OptoRuntime::generate_exception_blob() unnecessary second get_thread() call? In-Reply-To: <48F4D60E-A46D-4501-95A3-938254AC7597@sun.com> References: <4A57532B.3030506@Sun.COM> <48F4D60E-A46D-4501-95A3-938254AC7597@sun.com> Message-ID: <4A5790BA.70405@Sun.COM> John Rose wrote: > On Jul 10, 2009, at 7:41 AM, Christian Thalinger wrote: > >> While changing something in OptoRuntime::generate_exception_blob() in >> runtime_x86_32.cpp I noticed that there are two calls to get_thread() >> and the second call happens while the register from the first call >> still >> holds the value. > > There are three calls to get_thread(rcx). The first and second are > separated by a call to handle_exception_C, which presumably blows rcx. > > I think you are right that the third get_thread duplicates the result > of the second. > > And this comment appears to be false: > // rcx contains handler address Right, I forgot that one in my email. Should we fix this in one of our invokedynamic patches or separately? -- Christian From John.Rose at Sun.COM Fri Jul 10 12:10:44 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 10 Jul 2009 12:10:44 -0700 Subject: x86_32 OptoRuntime::generate_exception_blob() unnecessary second get_thread() call? In-Reply-To: <4A5790BA.70405@Sun.COM> References: <4A57532B.3030506@Sun.COM> <48F4D60E-A46D-4501-95A3-938254AC7597@sun.com> <4A5790BA.70405@Sun.COM> Message-ID: Roll it in. If there's any doubt whatever about correctness, conditionalize the change on EnableMethodHandles. -- John On Jul 10, 2009, at 12:04 PM, Christian Thalinger wrote: > John Rose wrote: >> On Jul 10, 2009, at 7:41 AM, Christian Thalinger wrote: >> >>> While changing something in OptoRuntime::generate_exception_blob() >>> in >>> runtime_x86_32.cpp I noticed that there are two calls to >>> get_thread() >>> and the second call happens while the register from the first call >>> still >>> holds the value. >> >> There are three calls to get_thread(rcx). The first and second are >> separated by a call to handle_exception_C, which presumably blows >> rcx. >> >> I think you are right that the third get_thread duplicates the result >> of the second. >> >> And this comment appears to be false: >> // rcx contains handler address > > Right, I forgot that one in my email. Should we fix this in one of > our > invokedynamic patches or separately? > > -- Christian From Thomas.Rodriguez at Sun.COM Fri Jul 10 16:07:26 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 10 Jul 2009 16:07:26 -0700 Subject: review (XS) for 6859338 Message-ID: http://cr.openjdk.java.net/~never/6859338 From Vladimir.Kozlov at Sun.COM Fri Jul 10 16:37:12 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 10 Jul 2009 16:37:12 -0700 Subject: review (XS) for 6859338 In-Reply-To: References: Message-ID: <4A57D0A8.5080102@sun.com> Tom, Looks good. Could you add the assert_different_registers(ic_reg, receiver, rscratch1)? We may not needed it but it will not hurt. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6859338 From Thomas.Rodriguez at Sun.COM Fri Jul 10 17:45:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 10 Jul 2009 17:45:23 -0700 Subject: review (XS) for 6859338 In-Reply-To: <4A57D0A8.5080102@sun.com> References: <4A57D0A8.5080102@sun.com> Message-ID: <8C58FA8F-6719-4968-A595-DDACA8BE7B7E@Sun.COM> I've added that and corrected the bug id in the test. I was doing some renamed after running the test and got the bug id wrong. tom On Jul 10, 2009, at 4:37 PM, Vladimir Kozlov wrote: > Tom, > > Looks good. > Could you add the assert_different_registers(ic_reg, receiver, > rscratch1)? > We may not needed it but it will not hurt. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6859338 From Vladimir.Kozlov at Sun.COM Fri Jul 10 19:39:52 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 10 Jul 2009 19:39:52 -0700 Subject: review (XS) for 6859338 In-Reply-To: <8C58FA8F-6719-4968-A595-DDACA8BE7B7E@Sun.COM> References: <4A57D0A8.5080102@sun.com> <8C58FA8F-6719-4968-A595-DDACA8BE7B7E@Sun.COM> Message-ID: <4A57FB78.4030905@sun.com> Looks good. Thanks, Vladimir Tom Rodriguez wrote: > I've added that and corrected the bug id in the test. I was doing some > renamed after running the test and got the bug id wrong. > > tom > > On Jul 10, 2009, at 4:37 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Looks good. >> Could you add the assert_different_registers(ic_reg, receiver, >> rscratch1)? >> We may not needed it but it will not hurt. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6859338 > From Christian.Thalinger at Sun.COM Sun Jul 12 03:31:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 12 Jul 2009 12:31:57 +0200 Subject: review (XS) for 6859338 In-Reply-To: <8C58FA8F-6719-4968-A595-DDACA8BE7B7E@Sun.COM> References: <4A57D0A8.5080102@sun.com> <8C58FA8F-6719-4968-A595-DDACA8BE7B7E@Sun.COM> Message-ID: <4A59BB9D.8020103@Sun.COM> Tom Rodriguez wrote: > I've added that and corrected the bug id in the test. I was doing > some renamed after running the test and got the bug id wrong. Looks good. -- Christian From thomas.rodriguez at sun.com Mon Jul 13 18:31:10 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Tue, 14 Jul 2009 01:31:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090714013125.D1B7AE009@hg.openjdk.java.net> Changeset: fe95187e8882 Author: never Date: 2009-07-13 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe95187e8882 6859338: amd64 native unverified entry point pushes values before implicit null check Reviewed-by: kvn, twisti ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + test/compiler/6859338/Test6859338.java Changeset: 83906a156fc0 Author: never Date: 2009-07-13 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/83906a156fc0 Merge From Vladimir.Kozlov at Sun.COM Tue Jul 14 17:10:19 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 14 Jul 2009 17:10:19 -0700 Subject: Requestfor reviews (L) (updated) : 6851742: (EA) allocation elimination doesn't work with UseG1GC Message-ID: <4A5D1E6B.2060007@sun.com> After discussion with Tom I removed implementation of StoreOop node and used local elimination of G1 pre/post barriers in eliminate_card_mark(). http://cr.openjdk.java.net/~kvn/6851742/webrev.04 Fixed 6851742: (EA) allocation elimination doesn't work with UseG1GC Problem: EA expects only card mark store after oop store but barriers for G1 are much more complex. Solution: - Fix eliminate_card_mark() to eliminate of G1 pre/post barriers. - Used idealKit for write_barrier_post() method and moved it down in the file. Renamed some variables to distinguish them from methods names. - Check IGVN delay_transform flag in IdealKit when setting bottom_type for new nodes. - Don't clone memory around leaf call in IdealKit since it modifies only raw memory. - Explicitly remove the original merge region in IfNode split_if() otherwise it will not be removed if it has dead users and it will cause unique_ctrl_out() to return an incorrect result. - Fix IdealKit code in LibraryCallKit::inline_unsafe_access() which produced incorrect graph. - Fix EA to not generated duplicated Phi nodes for the same memory slice in ConnectionGraph::create_split_phi(). - Fix MachNode::adr_type for direct addressing modes to use ideal type if it is ptr. And remove rawptr cutout in mach node adr type verification code. Reviewed by: never Fix verified (y/n): y, bug's test Other testing: JPRT, CTW +G1 +EA 32-bit 64-bit From Vladimir.Kozlov at Sun.COM Tue Jul 14 18:37:28 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 14 Jul 2009 18:37:28 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase Message-ID: <4A5D32D8.60204@sun.com> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 Fixed 6860599: Relax nodes limit check for Output phase Problem: I got several CTW cases when without EA C2 "gracefully" bailout compilation when nodes limit check failed during macro nodes expansion. And with EA it passed macro nodes expansion but crashed with ASSERT during Output phase. One byte MachNop nodes are used in debug mode for loops and calls alignment in Output phase. As result for a big method the node limit could be reached. Solution: Increase nodes limit (double) for Output phase. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From rasbold at google.com Wed Jul 15 09:27:14 2009 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 15 Jul 2009 09:27:14 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post Message-ID: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 Fixed 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post Consult the control node of both inputs when deciding where to place new LShiftI node. Previously, we assumed the invar input should set the new node's control, and the scale input was irrelevant for control's sake. However, sometimes the invar input is a constant, allowing it to be higher in the dom tree than the scale. Fix provided by Hiroshi Yamauchi (yamauchi at google.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090715/67c007c2/attachment.html From Thomas.Rodriguez at Sun.COM Wed Jul 15 12:07:30 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 15 Jul 2009 12:07:30 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> Message-ID: The test is missing the copyright notice but otherwise this looks good. BTW, I ran a full ctw with this change both as is and as an assert that checked for cases where this would produce a different control and I only found 4 cases where it ever changed the answer and none of those triggered a failure in the way the test case does. Hiroshi, thanks for tracking this down and Chuck, thanks for distilling a test case. tom On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: > http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 > > Fixed 6860469: remix_address_expressions sets incorrect control > causing crash in split_if_with_block_post > > Consult the control node of both inputs when deciding where to place > new LShiftI node. > > Previously, we assumed the invar input should set the new node's > control, and the scale input was irrelevant for control's sake. > However, sometimes the invar input is a constant, allowing it to be > higher in the dom tree than the scale. > > Fix provided by Hiroshi Yamauchi (yamauchi at google.com) > From rasbold at google.com Wed Jul 15 12:24:02 2009 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 15 Jul 2009 12:24:02 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> Message-ID: <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> I presume that Sun will add the copyright notice when the code is committed, and of course, I'm OK with that. IANAL, but I'm reluctant to add the notice in advance, mostly because I am not employed by Sun. On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez wrote: > The test is missing the copyright notice but otherwise this looks good. > BTW, I ran a full ctw with this change both as is and as an assert that > checked for cases where this would produce a different control and I only > found 4 cases where it ever changed the answer and none of those triggered a > failure in the way the test case does. Hiroshi, thanks for tracking this > down and Chuck, thanks for distilling a test case. > > tom > > > On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: > > http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >> >> Fixed 6860469: remix_address_expressions sets incorrect control causing >> crash in split_if_with_block_post >> >> Consult the control node of both inputs when deciding where to place >> new LShiftI node. >> >> Previously, we assumed the invar input should set the new node's >> control, and the scale input was irrelevant for control's sake. >> However, sometimes the invar input is a constant, allowing it to be >> higher in the dom tree than the scale. >> >> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090715/7c536ab0/attachment.html From john.coomes at sun.com Wed Jul 15 12:44:52 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 15 Jul 2009 19:44:52 +0000 Subject: hg: jdk7/hotspot-comp: 11 new changesets Message-ID: <20090715194452.ED57FE1C5@hg.openjdk.java.net> Changeset: c50469cf63cd Author: herrick Date: 2009-06-11 15:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/c50469cf63cd 6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7 6845973: Update JDK7 with deployment changes in 6u13, 6u14 4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64 6825019: DownloadManager should not be loaded and referenced for full JRE 6738770: REGRESSION:JSException throws when use LiveConnect javascript facility 6772884: plugin2 : java.lang.OutOfMemoryError or crash 6707535: Crossing domain hole affecting multiple sites/domains using plug-in 6728071: Non-verification of Update files may allow unintended updates 6704154: Code loaded from local filesystem should not get access to localhost 6727081: Web Start security restrictions bypass using special extension jnlp 6727079: Java Web Start Socket() restriction bypass 6727071: Cache location/user name information disclosure in SingleInstanceImpl. 6716217: AppletClassLoader adds permissions based on codebase regardless of CS 6694892: Java Webstart inclusion via system properties override [CVE-2008-2086] 6704074: localhost socket access due to cache location exposed 6703909: Java webstart arbitrary file creation using nativelib 6665315: browser crashes when deployment.properties has more slashes ( / ) 6660121: Encoding values in JNLP files can cause buffer overflow 6606110: URLConnection.setProxiedHost for resources that are loaded via proxy 6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install 6609756: Buffer Overflow in Java ActiveX component 6608712: Bypassing the same origin policy in Java with crafted names 6534630: "gnumake clobber" doesn't 6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build 6849029: Need some JDK7 merge clean-up after comments on the webrev 6847582: Build problem on JDK7 with isSecureProperty in merge 6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk 6823215: latest merge fixes from 6u12 -> JDK7 6816153: further mergers for JDK7 deployment integration 6807074: Fix Java Kernel and JQS in initial JDK7 builds Summary: Initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/deploy-rules.gmk Changeset: c7c4850f1478 Author: herrick Date: 2009-06-15 13:07 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/c7c4850f1478 Merge Changeset: d28a8c422df1 Author: herrick Date: 2009-06-22 09:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/d28a8c422df1 Merge Changeset: 528e4cc7541b Author: herrick Date: 2009-06-29 12:00 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/528e4cc7541b Merge Changeset: 9f4fc871bf4d Author: herrick Date: 2009-07-06 15:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/9f4fc871bf4d Merge Changeset: 03119516abbc Author: herrick Date: 2009-07-06 14:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/03119516abbc Merge Changeset: 633840bd4c5b Author: jqzuo Date: 2009-07-07 10:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/633840bd4c5b Merge Changeset: 46c0f8989eb2 Author: herrick Date: 2009-07-06 17:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/46c0f8989eb2 Merge Changeset: 3e781aa606d4 Author: ohair Date: 2009-07-06 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3e781aa606d4 6857805: Fix openjdk builds to avoid building deploy repository Reviewed-by: xdono ! make/Defs-internal.gmk ! make/deploy-rules.gmk Changeset: 269c1ec4435d Author: jqzuo Date: 2009-07-07 10:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/269c1ec4435d Merge Changeset: d92b13b3c138 Author: xdono Date: 2009-07-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/d92b13b3c138 Added tag jdk7-b64 for changeset 269c1ec4435d ! .hgtags From john.coomes at sun.com Wed Jul 15 12:51:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 15 Jul 2009 19:51:06 +0000 Subject: hg: jdk7/hotspot-comp/corba: 8 new changesets Message-ID: <20090715195116.DC04BE1CA@hg.openjdk.java.net> Changeset: ffb590b42ed1 Author: herrick Date: 2009-06-11 15:16 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ffb590b42ed1 6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7 6845973: Update JDK7 with deployment changes in 6u13, 6u14 4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64 6825019: DownloadManager should not be loaded and referenced for full JRE 6738770: REGRESSION:JSException throws when use LiveConnect javascript facility 6772884: plugin2 : java.lang.OutOfMemoryError or crash 6707535: Crossing domain hole affecting multiple sites/domains using plug-in 6728071: Non-verification of Update files may allow unintended updates 6704154: Code loaded from local filesystem should not get access to localhost 6727081: Web Start security restrictions bypass using special extension jnlp 6727079: Java Web Start Socket() restriction bypass 6727071: Cache location/user name information disclosure in SingleInstanceImpl. 6716217: AppletClassLoader adds permissions based on codebase regardless of CS 6694892: Java Webstart inclusion via system properties override [CVE-2008-2086] 6704074: localhost socket access due to cache location exposed 6703909: Java webstart arbitrary file creation using nativelib 6665315: browser crashes when deployment.properties has more slashes ( / ) 6660121: Encoding values in JNLP files can cause buffer overflow 6606110: URLConnection.setProxiedHost for resources that are loaded via proxy 6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install 6609756: Buffer Overflow in Java ActiveX component 6608712: Bypassing the same origin policy in Java with crafted names 6534630: "gnumake clobber" doesn't 6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build 6849029: Need some JDK7 merge clean-up after comments on the webrev 6847582: Build problem on JDK7 with isSecureProperty in merge 6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk 6823215: latest merge fixes from 6u12 -> JDK7 6816153: further mergers for JDK7 deployment integration 6807074: Fix Java Kernel and JQS in initial JDK7 builds Summary: Initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/org/omg/idl/Makefile ! src/windows/resource/version.rc Changeset: 79d8fd9e74b9 Author: herrick Date: 2009-06-15 13:07 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/79d8fd9e74b9 Merge - make/README Changeset: 1b3e9fdc4fc5 Author: herrick Date: 2009-06-22 09:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/1b3e9fdc4fc5 Merge Changeset: 27f41fcf3d6a Author: herrick Date: 2009-06-29 12:00 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/27f41fcf3d6a Merge Changeset: f982791bb7d4 Author: herrick Date: 2009-07-06 15:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/f982791bb7d4 Merge Changeset: 863559dbbced Author: herrick Date: 2009-07-06 14:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/863559dbbced Merge Changeset: 047dd27fddb6 Author: herrick Date: 2009-07-06 17:11 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/047dd27fddb6 Merge Changeset: 97fd9b42f5c2 Author: xdono Date: 2009-07-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/97fd9b42f5c2 Added tag jdk7-b64 for changeset 047dd27fddb6 ! .hgtags From Vladimir.Kozlov at Sun.COM Wed Jul 15 12:57:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 15 Jul 2009 12:57:39 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> Message-ID: <4A5E34B3.7040506@sun.com> Looks good. Vladimir Chuck Rasbold wrote: > http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 > > > Fixed 6860469: remix_address_expressions sets incorrect control causing > crash in split_if_with_block_post > > Consult the control node of both inputs when deciding where to place > new LShiftI node. > > Previously, we assumed the invar input should set the new node's > control, and the scale input was irrelevant for control's sake. > However, sometimes the invar input is a constant, allowing it to be > higher in the dom tree than the scale. > > Fix provided by Hiroshi Yamauchi (yamauchi at google.com > ) > From john.coomes at sun.com Wed Jul 15 13:20:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 15 Jul 2009 20:20:12 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b64 for changeset a10eec7a1edf Message-ID: <20090715202014.AD5B8E1D8@hg.openjdk.java.net> Changeset: 008c662e0ee9 Author: xdono Date: 2009-07-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/008c662e0ee9 Added tag jdk7-b64 for changeset a10eec7a1edf ! .hgtags From john.coomes at sun.com Wed Jul 15 13:25:30 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 15 Jul 2009 20:25:30 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b64 for changeset aaa25dfd3de6 Message-ID: <20090715202533.1334CE1DF@hg.openjdk.java.net> Changeset: aa22a1be5866 Author: xdono Date: 2009-07-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/aa22a1be5866 Added tag jdk7-b64 for changeset aaa25dfd3de6 ! .hgtags From Thomas.Rodriguez at Sun.COM Wed Jul 15 13:37:23 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 15 Jul 2009 13:37:23 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> Message-ID: http://cr.openjdk.java.net/~never/6860469 is what I'm going to push with you and hiroshi marked as contributors. I added the copyright and fixed the test case run running with jtreg. The class needed to be public and the class name was missing from the @run line. tom On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: > I presume that Sun will add the copyright notice when the code is > committed, and of course, I'm OK with that. > > IANAL, but I'm reluctant to add the notice in advance, mostly > because I am not employed by Sun. > > On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez > wrote: > The test is missing the copyright notice but otherwise this looks > good. BTW, I ran a full ctw with this change both as is and as an > assert that checked for cases where this would produce a different > control and I only found 4 cases where it ever changed the answer > and none of those triggered a failure in the way the test case > does. Hiroshi, thanks for tracking this down and Chuck, thanks for > distilling a test case. > > tom > > > On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: > > http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 > > Fixed 6860469: remix_address_expressions sets incorrect control > causing crash in split_if_with_block_post > > Consult the control node of both inputs when deciding where to place > new LShiftI node. > > Previously, we assumed the invar input should set the new node's > control, and the scale input was irrelevant for control's sake. > However, sometimes the invar input is a constant, allowing it to be > higher in the dom tree than the scale. > > Fix provided by Hiroshi Yamauchi (yamauchi at google.com) > > > From rasbold at google.com Wed Jul 15 13:50:14 2009 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 15 Jul 2009 13:50:14 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> Message-ID: <4149a0430907151350t3d20ceb3h2dc4ef811b1eb3a1@mail.gmail.com> Looks good. Thanks. On Wed, Jul 15, 2009 at 1:37 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6860469is what I'm going to push with you and hiroshi marked as contributors. I > added the copyright and fixed the test case run running with jtreg. The > class needed to be public and the class name was missing from the @run line. > > tom > > > On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: > > I presume that Sun will add the copyright notice when the code is >> committed, and of course, I'm OK with that. >> >> IANAL, but I'm reluctant to add the notice in advance, mostly because I am >> not employed by Sun. >> >> On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez >> wrote: >> The test is missing the copyright notice but otherwise this looks good. >> BTW, I ran a full ctw with this change both as is and as an assert that >> checked for cases where this would produce a different control and I only >> found 4 cases where it ever changed the answer and none of those triggered a >> failure in the way the test case does. Hiroshi, thanks for tracking this >> down and Chuck, thanks for distilling a test case. >> >> tom >> >> >> On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: >> >> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >> >> Fixed 6860469: remix_address_expressions sets incorrect control causing >> crash in split_if_with_block_post >> >> Consult the control node of both inputs when deciding where to place >> new LShiftI node. >> >> Previously, we assumed the invar input should set the new node's >> control, and the scale input was irrelevant for control's sake. >> However, sometimes the invar input is a constant, allowing it to be >> higher in the dom tree than the scale. >> >> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090715/df79c8ae/attachment.html From john.coomes at sun.com Wed Jul 15 13:34:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 15 Jul 2009 20:34:41 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 78 new changesets Message-ID: <20090715205404.5D447E1F3@hg.openjdk.java.net> Changeset: 1299804aa6e7 Author: xuelei Date: 2009-06-16 20:46 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1299804aa6e7 6850783: InvalidityDateExtension returns reference to internal mutable state Summary: return cloned instead of referenced object Reviewed-by: weijun ! src/share/classes/sun/security/x509/CertificateVersion.java ! src/share/classes/sun/security/x509/InvalidityDateExtension.java Changeset: bc2c9dbdcc70 Author: weijun Date: 2009-06-17 15:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bc2c9dbdcc70 6849275: enhance krb5 reg tests Reviewed-by: xuelei ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/basic.sh Changeset: 863351d5d244 Author: weijun Date: 2009-06-18 11:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/863351d5d244 6712755: jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13 Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/emptymanifest.sh Changeset: e387bb1367a7 Author: mullan Date: 2009-06-18 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e387bb1367a7 6833839: RFE: improve ManifestDigester by instantiating StringBuilder constructor w/ initial value Reviewed-by: weijun ! src/share/classes/sun/security/util/ManifestDigester.java Changeset: 81c176909720 Author: mullan Date: 2009-06-18 10:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/81c176909720 Merge Changeset: 37ed72fe7561 Author: weijun Date: 2009-06-19 18:03 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/37ed72fe7561 6851973: ignore incoming channel binding if acceptor does not set one Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/InitialToken.java + test/sun/security/krb5/auto/IgnoreChannelBinding.java Changeset: ed38f9e6ad9a Author: jccollet Date: 2009-06-19 14:12 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ed38f9e6ad9a 6852108: Remove Preferences dependance from SocksSocketImpl Summary: Removed Preferences API use and fixed a few findbugs gotchas Reviewed-by: alanb ! src/share/classes/java/net/SocksSocketImpl.java Changeset: 77367060d119 Author: sherman Date: 2009-06-19 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/77367060d119 6299219: euro sign failed to be printed in Console on Localized Windows platform with GBK encoding 4891024: EUC-KR and JOHAB converters need to be updated to include two new characters 4287467: Character converter generator tool Summary: Migrated some of the doublebyte charsets to the new implementation. Reviewed-by: okutsu ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/EUC_CN.map + make/tools/CharsetMapping/EUC_KR.map + make/tools/CharsetMapping/GBK.map + make/tools/CharsetMapping/Johab.map + make/tools/CharsetMapping/MS932.c2b + make/tools/CharsetMapping/MS932.map + make/tools/CharsetMapping/MS932.nr + make/tools/CharsetMapping/MS936.map + make/tools/CharsetMapping/MS949.map + make/tools/CharsetMapping/MS950.map + make/tools/CharsetMapping/MS950.nr ! make/tools/CharsetMapping/dbcs ! make/tools/src/build/tools/charsetmapping/GenerateDBCS.java ! src/share/classes/sun/io/ByteToCharEUC_CN.java ! src/share/classes/sun/io/ByteToCharEUC_KR.java ! src/share/classes/sun/io/ByteToCharGBK.java ! src/share/classes/sun/io/ByteToCharJohab.java ! src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS932DB.java ! src/share/classes/sun/io/ByteToCharMS936.java ! src/share/classes/sun/io/ByteToCharMS949.java ! src/share/classes/sun/io/ByteToCharMS950.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/CharToByteEUC_CN.java ! src/share/classes/sun/io/CharToByteEUC_KR.java ! src/share/classes/sun/io/CharToByteGBK.java ! src/share/classes/sun/io/CharToByteJohab.java ! src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS932DB.java ! src/share/classes/sun/io/CharToByteMS936.java ! src/share/classes/sun/io/CharToByteMS949.java ! src/share/classes/sun/io/CharToByteMS950.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java ! src/share/classes/sun/nio/cs/ext/MS932_0213.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java ! src/solaris/classes/sun/awt/motif/X11GB2312.java ! src/solaris/classes/sun/awt/motif/X11GBK.java ! src/solaris/classes/sun/awt/motif/X11KSC5601.java + test/sun/nio/cs/OLD/DoubleByteDecoder.java + test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_CN_OLD.java + test/sun/nio/cs/OLD/EUC_KR_OLD.java + test/sun/nio/cs/OLD/GBK_OLD.java + test/sun/nio/cs/OLD/Johab_OLD.java + test/sun/nio/cs/OLD/MS932DB.java + test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/MS936_OLD.java + test/sun/nio/cs/OLD/MS949_OLD.java + test/sun/nio/cs/OLD/MS950_OLD.java ! test/sun/nio/cs/OLD/TestIBMDB.java + test/sun/nio/cs/OLD/TestX11CS.java + test/sun/nio/cs/OLD/X11GB2312_OLD.java + test/sun/nio/cs/OLD/X11GBK_OLD.java + test/sun/nio/cs/OLD/X11KSC5601_OLD.java Changeset: 28d4c9f5c9e9 Author: xlu Date: 2009-06-20 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/28d4c9f5c9e9 6850606: Regression from JDK 1.6.0_12 Summary: The returned result from multiply should be constructed by using valueOf to take care of the INFLATED case. Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/MultiplyTests.java Changeset: b0b249933c37 Author: martin Date: 2009-06-22 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b0b249933c37 6851653: (launcher) Make every java process 20 bytes smaller Summary: Carefully keep track of every byte Reviewed-by: ksrini, xlu ! src/share/bin/java.c Changeset: 7704895771b5 Author: sherman Date: 2009-06-22 19:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7704895771b5 6847092: (cs) CharsetEncoder.isLegalReplacement of US_ASCII behaves differently since Summary: Updated the US_ASCII and ISO-8859-1 to fix the failure. Reviewed-by: alanb, martin ! src/share/classes/sun/nio/cs/ISO_8859_1.java ! src/share/classes/sun/nio/cs/US_ASCII.java + test/sun/nio/cs/FindASCIIReplBugs.java Changeset: ce55eb6668d9 Author: martin Date: 2009-06-22 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce55eb6668d9 6834805: Improve jar -C performance Summary: Store "-C" directories in a HashSet, not List, to remove duplicates Reviewed-by: sherman Contributed-by: jeremymanson at google.com ! src/share/classes/sun/tools/jar/Main.java Changeset: ff32c270102a Author: martin Date: 2009-06-22 21:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ff32c270102a 6853806: Prefer (cd $dir && jar) to jar -C for performance reasons Summary: Eliminate (most) uses of jar -C Reviewed-by: ohair ! make/common/Release.gmk Changeset: b3444a42fd40 Author: tbell Date: 2009-06-23 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b3444a42fd40 Merge - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java Changeset: 70c0a927e21a Author: jccollet Date: 2009-06-25 18:56 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/70c0a927e21a 6811297: Add more logging to HTTP protocol handler Summary: Added extra logging to HttpURLConnection and HttpClient. Added a capture tool. Reviewed-by: chegar ! make/sun/net/FILES_java.gmk + src/share/classes/sun/net/www/http/HttpCapture.java + src/share/classes/sun/net/www/http/HttpCaptureInputStream.java + src/share/classes/sun/net/www/http/HttpCaptureOutputStream.java ! src/share/classes/sun/net/www/http/HttpClient.java + src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 5a3a5388756c Author: langel Date: 2009-06-25 17:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5a3a5388756c 6852607: MessageUtils JVM crash Summary: Fixes crash by checking null field Reviewed-by: alanb ! src/share/native/sun/misc/MessageUtils.c Changeset: 0b6571d4b4b5 Author: jccollet Date: 2009-06-26 16:50 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0b6571d4b4b5 6855297: Windows build breaks after 6811297 Summary: re-introduced the mistakenly taken out authObj member Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 9f243df213fa Author: tbell Date: 2009-06-26 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9f243df213fa Merge - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java Changeset: a5f7d97c3f82 Author: jjg Date: 2009-06-26 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a5f7d97c3f82 6843077: JSR 308: Annotations on types Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu ! src/share/classes/java/lang/annotation/ElementType.java Changeset: bd4f0613dd92 Author: tbell Date: 2009-06-28 00:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bd4f0613dd92 Merge Changeset: 5208d0c90d73 Author: alanb Date: 2009-06-27 21:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5208d0c90d73 6838333: New I/O: Update file system API to jsr203/nio2-b101 6844313: New I/O: File timestamps should be represented by a FileTime rather than a long+TimeUnit Reviewed-by: sherman ! make/java/java/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/java/io/File.java + src/share/classes/java/io/TempFileHelper.java ! src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/file/AccessMode.java ! src/share/classes/java/nio/file/DirectoryStream.java - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java ! src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/OpenOption.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/nio/file/StandardWatchEventKind.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/Attributes.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java ! src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java + src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java - src/share/classes/java/nio/file/spi/AbstractPath.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java ! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java + src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java + src/share/classes/sun/nio/fs/DynamicFileAttributeView.java ! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java - src/share/classes/sun/nio/fs/MimeType.java ! src/share/classes/sun/nio/fs/PollingWatchService.java + src/share/classes/sun/nio/fs/Util.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileKey.java ! src/solaris/classes/sun/nio/fs/UnixFileModeAttribute.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixMountEntry.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c ! test/java/nio/file/DirectoryStream/Basic.java - test/java/nio/file/DirectoryStream/Filters.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileSystem/Basic.java ! test/java/nio/file/Files/ContentType.java ! test/java/nio/file/Files/Misc.java - test/java/nio/file/Files/content_type.sh ! test/java/nio/file/Path/CopyAndMove.java + test/java/nio/file/Path/FileAttributes.java ! test/java/nio/file/Path/Links.java ! test/java/nio/file/Path/Misc.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/temporary_files.sh ! test/java/nio/file/TestUtil.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java - test/java/nio/file/attribute/Attributes/Basic.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/DosFileAttributeView/Basic.java ! test/java/nio/file/attribute/FileStoreAttributeView/Basic.java + test/java/nio/file/attribute/FileTime/Basic.java ! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java ! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: 77dd50ba670b Author: alanb Date: 2009-06-27 21:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/77dd50ba670b 6844054: (bf) Eliminate dependency on javax.management.ObjectName Reviewed-by: mchung ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/misc/JavaNioAccess.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java Changeset: dd20c662d463 Author: ohair Date: 2009-06-26 21:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd20c662d463 6855180: Fix classfile version check in java_crw_demo Reviewed-by: jjg ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/javavm/export/classfile_constants.h Changeset: cbb5964d97ef Author: ohair Date: 2009-06-28 11:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cbb5964d97ef Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 35b19adcb215 Author: tbell Date: 2009-06-28 23:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/35b19adcb215 Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 806c5e4d1265 Author: michaelm Date: 2009-06-29 13:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/806c5e4d1265 6513803: httpserver regression test Test13 failing and causing NullPointerException Summary: check for NPEs Reviewed-by: chegar ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test3.java ! test/com/sun/net/httpserver/Test4.java ! test/com/sun/net/httpserver/Test5.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/TestLogging.java Changeset: b6721df9ae0a Author: michaelm Date: 2009-06-29 13:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b6721df9ae0a Merge Changeset: a44009aba19f Author: chegar Date: 2009-06-29 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a44009aba19f 6855335: Several changes in the SCTP implementation. Reviewed-by: michaelm ! make/com/sun/nio/sctp/mapfile-vers ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpResultContainer.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/solaris/native/sun/nio/ch/Sctp.h ! src/solaris/native/sun/nio/ch/SctpChannelImpl.c ! src/solaris/native/sun/nio/ch/SctpNet.c ! test/com/sun/nio/sctp/SctpChannel/Connect.java ! test/com/sun/nio/sctp/SctpChannel/Shutdown.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java + test/com/sun/nio/sctp/SctpMultiChannel/Branch.java + test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java Changeset: 89b14d3740dc Author: michaelm Date: 2009-06-29 15:05 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/89b14d3740dc 6827999: 6827999: URLClassLoader.addURL(URL) adds URLs to closed class loader Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B6827999.java Changeset: 424420bf5917 Author: michaelm Date: 2009-06-29 15:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/424420bf5917 Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: d926534a1c17 Author: jjg Date: 2009-06-29 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d926534a1c17 6855069: rmic should support v51 class files. Reviewed-by: jrose ! src/share/classes/sun/tools/java/RuntimeConstants.java Changeset: cb20a8a1f22f Author: tbell Date: 2009-06-29 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cb20a8a1f22f Merge Changeset: 605d3fa6764e Author: weijun Date: 2009-06-30 11:55 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/605d3fa6764e 6855671: DerOutputStream encodes negative integer incorrectly Reviewed-by: xuelei ! src/share/classes/sun/security/util/DerOutputStream.java + test/sun/security/util/DerValue/NegInt.java Changeset: 1cc9eb0c952e Author: sherman Date: 2009-06-29 19:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1cc9eb0c952e 6707281: Adler32.update() JavaDoc is wrong 6553961: java.util.zip.{CRC32,Adler32}.update(int) doc errors 6646605: Missing method ZipFile.getComment() 6841232: ZipFile should implement Closeable 4985614: Failure on calls to ZipFile constructor 5032358: "java.util.zip.ZipException: The system cannot find the file specified" 6846616: java/util/zip/ZipFile/ReadAfterClose.java failed after fix for 6735255 Summary: some misc bug/rfe fixes for zipfile Reviewed-by: alanb ! make/java/java/mapfile-vers ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java Changeset: b144685f6694 Author: sherman Date: 2009-06-29 21:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b144685f6694 Merge Changeset: 861f23119072 Author: tbell Date: 2009-06-29 23:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/861f23119072 Merge Changeset: 4e4ff42f3140 Author: tbell Date: 2009-07-03 09:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4e4ff42f3140 Merge Changeset: 49e7d22262a9 Author: ant Date: 2009-06-18 11:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/49e7d22262a9 4788402: SortingFocusTraversalPolicy: prob with non-focusable focus Cycle Root as first Reviewed-by: dcherepanov ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! test/java/awt/Focus/FocusTraversalPolicy/DefaultFTPTest.java ! test/java/awt/Focus/FocusTraversalPolicy/LayoutFTPTest.java Changeset: 06f35d090a5e Author: langel Date: 2009-06-19 16:49 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/06f35d090a5e 6721086: Toolkit beep does not work consistently Summary: Flush out after bell is sounded Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: d1bdaf29e531 Author: dcherepanov Date: 2009-06-23 13:35 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d1bdaf29e531 6824169: Need to remove some AWT class dependencies Reviewed-by: art, anthony, igor, alexp ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/shell/ShellFolder.java - src/share/classes/sun/swing/AccessibleMethod.java + src/share/classes/sun/swing/SwingAccessor.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java Changeset: 61e25d428bfe Author: dcherepanov Date: 2009-06-23 15:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/61e25d428bfe 6736247: Component.printAll Invalid local JNI handle Reviewed-by: anthony ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java Changeset: e279dd2c5a2c Author: ant Date: 2009-06-23 15:53 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e279dd2c5a2c 6821291: assertion failure in awt_Frame.h Reviewed-by: dcherepanov, art ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h Changeset: 51e452ff726a Author: anthony Date: 2009-06-23 16:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/51e452ff726a 6851646: test/closed/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java can fail Summary: Added realSync() call. Made the test public. Reviewed-by: dcherepanov + test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.html + test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java Changeset: 5e880ea33ddc Author: yan Date: 2009-06-26 11:48 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e880ea33ddc 6711676: Numpad keys trigger more than one KeyEvent. Summary: Introduce a new sniffer based on server keymap. Reviewed-by: art ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 60290477fe73 Author: dav Date: 2009-06-26 19:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/60290477fe73 6848458: java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java fails Summary: consider gap between the component edge and container borders instead of just getX() and getY() Reviewed-by: dav Contributed-by: mwong at redhat.com ! test/java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java Changeset: 2df0d81c4201 Author: ant Date: 2009-06-30 12:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2df0d81c4201 6855713: jdk7: debug build failure in awt_Frame.cpp Reviewed-by: dcherepanov, yan ! src/windows/native/sun/windows/awt_Frame.cpp Changeset: 75497b840ed0 Author: yan Date: 2009-06-30 02:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75497b840ed0 Merge - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 4d7e08935d95 Author: yan Date: 2009-07-01 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4d7e08935d95 Merge - src/share/classes/sun/swing/AccessibleMethod.java Changeset: 743021a4938c Author: peterz Date: 2009-06-22 18:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/743021a4938c 6849277: Nimbus L&F: lots of painter classes were added to JDK7 as public Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/PainterImpl.template Changeset: ce347002bbd9 Author: peterz Date: 2009-06-23 12:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ce347002bbd9 6844273: jdk/make/docs/CORE_PKGS.gmk does not list Nimbus Reviewed-by: prr ! make/docs/CORE_PKGS.gmk ! src/share/classes/javax/swing/plaf/nimbus/package.html Changeset: b75fc6019d5f Author: malenkov Date: 2009-06-24 13:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b75fc6019d5f 6852574: EnumPersistenceDelegate fails to persist instances with blocks Reviewed-by: peterz ! src/share/classes/java/beans/MetaData.java + test/java/beans/XMLEncoder/Test6852574.java Changeset: 404a13b063f9 Author: malenkov Date: 2009-06-24 17:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/404a13b063f9 6737700: api/javax_swing/table/DefaultTableCellRenderer/index.html#getset:DefaultTableCellRenderer Reviewed-by: alexp ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java Changeset: e006119341de Author: peytoia Date: 2009-06-25 07:38 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e006119341de 6853792: test/java/text/Bidi/Bug6850113.java compilation error Reviewed-by: okutsu ! test/java/text/Bidi/Bug6850113.java Changeset: d6f2dd2bd8d0 Author: peytoia Date: 2009-06-25 17:37 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d6f2dd2bd8d0 6609750: [Fmt-De] SimpleDateFormat.format() doesn't handle pattern "y" correctly Reviewed-by: okutsu ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug6609750.java Changeset: d086e324775c Author: yan Date: 2009-06-25 00:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d086e324775c Merge - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java Changeset: 4d54d6e7bcef Author: yan Date: 2009-06-25 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4d54d6e7bcef Merge Changeset: e0707baa1593 Author: peytoia Date: 2009-06-25 21:55 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e0707baa1593 6792400: Avoid loading of Normalizer resources for simple uses Reviewed-by: okutsu ! src/share/classes/sun/text/normalizer/NormalizerBase.java Changeset: ae9e74a17059 Author: malenkov Date: 2009-06-25 18:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae9e74a17059 6848364: javax/swing/border/Test4856008.java regression test fails due to BorderedComponent package not found Reviewed-by: alexp ! test/javax/swing/border/Test4856008.java Changeset: f1f9d228800e Author: peterz Date: 2009-06-26 08:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f1f9d228800e 6827032: NIMBUS: Drag and drop throws a NPE in SwingSet2 ColorChooser Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java Changeset: e60d3354ab9f Author: malenkov Date: 2009-06-26 16:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e60d3354ab9f 6557223: Resize cursor stays after fast outline-resize of JInternalFrame with JScrollPane Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java Changeset: 1b40ddc3688c Author: malenkov Date: 2009-06-26 16:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1b40ddc3688c 6679840: provide a way to choose v-synced BufferStrategy Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 800082d9b8df Author: malenkov Date: 2009-06-26 17:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/800082d9b8df 6742850: Antialiasing for GTK L&F should be turned on by default if there is no embedded bitmap. Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java Changeset: 95f3fb73cf60 Author: peterz Date: 2009-06-26 21:43 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/95f3fb73cf60 6849805: Nimbus L&F: NimbusLookAndFeel.getDerivedColor() not always returns color2 for 1.0 midPoint Summary: Different rounding mode used for float->int conversion Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test6849805.java Changeset: 0bc2fa2d1938 Author: peytoia Date: 2009-06-30 09:38 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0bc2fa2d1938 6855715: Font2Dtest demo needs to be updated to support Unicode 5.1.0. Reviewed-by: okutsu ! src/share/demo/jfc/Font2DTest/RangeMenu.java Changeset: 9be953f877a8 Author: yan Date: 2009-07-01 00:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9be953f877a8 Merge ! src/share/classes/javax/swing/BufferStrategyPaintManager.java Changeset: 1a52b17a18d2 Author: yan Date: 2009-07-07 23:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1a52b17a18d2 Merge - src/share/classes/sun/swing/AccessibleMethod.java Changeset: 9053bcc8eef0 Author: herrick Date: 2009-06-12 14:56 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9053bcc8eef0 6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7 6845973: Update JDK7 with deployment changes in 6u13, 6u14 4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64 6825019: DownloadManager should not be loaded and referenced for full JRE 6738770: REGRESSION:JSException throws when use LiveConnect javascript facility 6772884: plugin2 : java.lang.OutOfMemoryError or crash 6707535: Crossing domain hole affecting multiple sites/domains using plug-in 6728071: Non-verification of Update files may allow unintended updates 6704154: Code loaded from local filesystem should not get access to localhost 6727081: Web Start security restrictions bypass using special extension jnlp 6727079: Java Web Start Socket() restriction bypass 6727071: Cache location/user name information disclosure in SingleInstanceImpl. 6716217: AppletClassLoader adds permissions based on codebase regardless of CS 6694892: Java Webstart inclusion via system properties override [CVE-2008-2086] 6704074: localhost socket access due to cache location exposed 6703909: Java webstart arbitrary file creation using nativelib 6665315: browser crashes when deployment.properties has more slashes ( / ) 6660121: Encoding values in JNLP files can cause buffer overflow 6606110: URLConnection.setProxiedHost for resources that are loaded via proxy 6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install 6609756: Buffer Overflow in Java ActiveX component 6608712: Bypassing the same origin policy in Java with crafted names 6534630: "gnumake clobber" doesn't 6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build 6849029: Need some JDK7 merge clean-up after comments on the webrev 6847582: Build problem on JDK7 with isSecureProperty in merge 6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk 6823215: latest merge fixes from 6u12 -> JDK7 6816153: further mergers for JDK7 deployment integration 6807074: Fix Java Kernel and JQS in initial JDK7 builds Summary: Initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk ! make/java/java/FILES_c.gmk ! make/java/redist/Makefile ! make/jpda/tty/Makefile ! make/sun/Makefile ! make/sun/applet/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/tzdata_jdk/jdk11_full_backward ! make/sun/jconsole/Makefile + make/sun/jkernel/FILES_c_windows.gmk + make/sun/jkernel/FILES_java.gmk + make/sun/jkernel/Makefile ! make/sun/native2ascii/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/serialver/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/sun/applet/AppletClassLoader.java ! src/share/classes/sun/applet/AppletPanel.java + src/share/classes/sun/jkernel/BackgroundDownloader.java + src/share/classes/sun/jkernel/Bundle.java + src/share/classes/sun/jkernel/BundleCheck.java + src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java + src/share/classes/sun/jkernel/DigestOutputStream.java + src/share/classes/sun/jkernel/DownloadManager.java + src/share/classes/sun/jkernel/KernelError.java + src/share/classes/sun/jkernel/Mutex.java + src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java + src/share/classes/sun/jkernel/StandaloneMessageDigest.java + src/share/classes/sun/jkernel/StandaloneSHA.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/PerformanceLogger.java ! src/share/classes/sun/misc/VM.java ! src/share/native/common/jni_util.c ! src/share/native/common/jni_util.h ! src/share/native/sun/misc/VM.c + src/solaris/native/common/jni_util_md.c ! src/windows/bin/java_md.c + src/windows/native/common/jni_util_md.c + src/windows/native/sun/jkernel/DownloadDialog.cpp + src/windows/native/sun/jkernel/DownloadDialog.h + src/windows/native/sun/jkernel/DownloadHelper.cpp + src/windows/native/sun/jkernel/DownloadHelper.h + src/windows/native/sun/jkernel/graphics/bullet.bmp + src/windows/native/sun/jkernel/graphics/cautionshield32.bmp + src/windows/native/sun/jkernel/graphics/java-icon.ico + src/windows/native/sun/jkernel/graphics/masthead.bmp + src/windows/native/sun/jkernel/graphics/warningmasthead.bmp + src/windows/native/sun/jkernel/kernel.cpp + src/windows/native/sun/jkernel/kernel.def + src/windows/native/sun/jkernel/kernel.h + src/windows/native/sun/jkernel/kernel.rc + src/windows/native/sun/jkernel/kernel_de.rc + src/windows/native/sun/jkernel/kernel_en.rc + src/windows/native/sun/jkernel/kernel_es.rc + src/windows/native/sun/jkernel/kernel_fr.rc + src/windows/native/sun/jkernel/kernel_it.rc + src/windows/native/sun/jkernel/kernel_ja.rc + src/windows/native/sun/jkernel/kernel_ko.rc + src/windows/native/sun/jkernel/kernel_sv.rc + src/windows/native/sun/jkernel/kernel_zh.rc + src/windows/native/sun/jkernel/kernel_zh_TW.rc + src/windows/native/sun/jkernel/resource.h + src/windows/native/sun/jkernel/stdafx.cpp + src/windows/native/sun/jkernel/stdafx.h + src/windows/native/sun/jkernel/version.rc ! src/windows/native/sun/windows/awt.rc + src/windows/resource/unpack200_proto.exe.manifest ! src/windows/resource/version.rc ! test/java/awt/Focus/NonFocusableWindowTest/NoEventsTest.java ! test/java/awt/Focus/RestoreFocusOnDisabledComponentTest/RestoreFocusOnDisabledComponentTest.java ! test/java/awt/font/Rotate/TranslatedOutlineTest.java ! test/java/awt/font/Threads/FontThread.java ! test/java/security/AccessControlContext/FailureDebugOption.java ! test/javax/swing/JPopupMenu/6691503/bug6691503.java ! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java Changeset: ea7620b05a58 Author: herrick Date: 2009-06-15 13:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ea7620b05a58 Merge ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 4f207797e185 Author: herrick Date: 2009-06-19 11:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4f207797e185 6852646: JDK 7 cannot build w/o ALT_HOTSPOT_KERNEL_PATH set. Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity.gmk Changeset: 23c7d780c1b3 Author: herrick Date: 2009-06-19 15:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/23c7d780c1b3 6853152: JDK 7 cannot build w/o ALT_HOTSPOT_KERNEL_PATH set. - still broken Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/common/shared/Defs-windows.gmk ! make/java/redist/Makefile Changeset: f509fe92a102 Author: herrick Date: 2009-06-22 09:16 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f509fe92a102 Merge Changeset: 9362d0114c3a Author: herrick Date: 2009-06-24 14:49 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9362d0114c3a 6633813: Add standard hotspot import path for Kernel VM Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/common/shared/Defs-windows.gmk ! make/java/redist/Makefile Changeset: dd0371861841 Author: herrick Date: 2009-06-29 12:06 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/dd0371861841 Merge ! make/common/Release.gmk ! make/sun/Makefile ! src/share/classes/java/lang/System.java - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 4caa574b3993 Author: herrick Date: 2009-06-29 17:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4caa574b3993 6855953: JDK7 - merger error of deployment changes with b62 -in jdk/make/sun/Makefile Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7 Reviewed-by: dgu, billyh ! make/sun/Makefile Changeset: 9710ed723163 Author: herrick Date: 2009-07-01 10:18 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9710ed723163 Merge ! src/share/classes/java/awt/color/ICC_Profile.java Changeset: c51ead46c547 Author: herrick Date: 2009-07-06 14:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c51ead46c547 Merge ! make/common/Release.gmk - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: a50217eb3ee1 Author: jqzuo Date: 2009-07-09 13:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a50217eb3ee1 Merge - src/share/classes/sun/swing/AccessibleMethod.java Changeset: 382a27aa78d3 Author: xdono Date: 2009-07-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/382a27aa78d3 Added tag jdk7-b64 for changeset a50217eb3ee1 ! .hgtags From john.coomes at sun.com Wed Jul 15 14:15:16 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 15 Jul 2009 21:15:16 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 25 new changesets Message-ID: <20090715211556.9235CE206@hg.openjdk.java.net> Changeset: a9c04a57a39f Author: mcimadamore Date: 2009-06-16 10:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a9c04a57a39f 6845686: basic and raw formatters do not display captured var id properly when javac runs in -XDoldDiags mode Summary: Basic and raw formatters do not override Printer methods properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! test/tools/javac/Diagnostics/6799605/T6799605.java ! test/tools/javac/Diagnostics/6799605/T6799605.out Changeset: 3d539f4123b8 Author: mcimadamore Date: 2009-06-16 10:45 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/3d539f4123b8 6835430: javac does not generate signature attributes for classes extending parameterized inner classes Summary: ClassWriter does not consider outer params of an inner class when emitting signature attributes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/6835430/A.java + test/tools/javac/6835430/T6835430.java Changeset: 3ac205ad1f05 Author: mcimadamore Date: 2009-06-16 10:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/3ac205ad1f05 6835428: regression: return-type inference rejects valid code Summary: Redundant subtyping test during type-inference ends up in rejecting legal code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/T6835428.java Changeset: 22872b24d38c Author: mcimadamore Date: 2009-06-16 10:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/22872b24d38c 6638712: Inference with wildcard types causes selection of inapplicable method Summary: Added global sanity check in order to make sure that return type inference does not violate bounds constraints Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/generics/inference/6302954/T6476073.java + test/tools/javac/generics/inference/6638712/T6638712a.java + test/tools/javac/generics/inference/6638712/T6638712a.out + test/tools/javac/generics/inference/6638712/T6638712b.java + test/tools/javac/generics/inference/6638712/T6638712b.out + test/tools/javac/generics/inference/6638712/T6638712c.java + test/tools/javac/generics/inference/6638712/T6638712c.out + test/tools/javac/generics/inference/6638712/T6638712d.java + test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/generics/inference/6638712/T6638712e.java + test/tools/javac/generics/inference/6638712/T6638712e.out Changeset: ed989c347b3c Author: jjg Date: 2009-06-19 11:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ed989c347b3c 6852856: javap changes to facilitate subclassing javap for variants Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java Changeset: fe077c71cd47 Author: tbell Date: 2009-06-23 22:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/fe077c71cd47 Merge Changeset: 18e0269f25e3 Author: mcimadamore Date: 2009-06-24 10:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/18e0269f25e3 6822637: ResolveError hierarchy needs to be refactored Summary: Break ResolveError class into a hierarchy representing different kinds of resolution errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java Changeset: 8ec37cf2b37e Author: mcimadamore Date: 2009-06-24 10:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/8ec37cf2b37e 6852595: Accessing scope using JSR199 API on erroneous tree causes Illegal Argument Exception Summary: Fixed problem with empty DiagnosticSource objects causing IAE in the JCDiagnostic constructor Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java + test/tools/javac/api/6852595/T6852595.java Changeset: 1d9e61e0a075 Author: mcimadamore Date: 2009-06-24 10:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/1d9e61e0a075 6852649: The Rich formatter printer should be an explicit class to facilitate overriding Summary: Improve reusabiliy of the rich formatter by removing anonymous inner classes/changing visibility of fields Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java Changeset: 812d5486a023 Author: tbell Date: 2009-06-24 17:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/812d5486a023 Merge Changeset: e71fd3fcebf5 Author: tbell Date: 2009-06-26 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e71fd3fcebf5 Merge Changeset: ca063536e4a6 Author: darcy Date: 2009-06-26 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ca063536e4a6 6593082: MirroredTypeException constructor does not throw NPE when type is null Reviewed-by: jjg ! src/share/classes/javax/lang/model/type/MirroredTypeException.java + test/tools/javac/processing/model/type/MirroredTypeEx/NpeTest.java Changeset: 03944ee4fac4 Author: jjg Date: 2009-06-26 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/03944ee4fac4 6843077: JSR 308: Annotations on types Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu ! src/share/bin/launcher.sh-template ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! test/tools/javac/6341866/T6341866.java ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/T6439826.java Changeset: 664edca41e34 Author: jjg Date: 2009-06-26 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/664edca41e34 6855544: add missing files Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu + src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java + src/share/classes/com/sun/source/util/AbstractTypeProcessor.java + src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/javac/code/TargetType.java + src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/tools/javac/api/TestTreePath.java + test/tools/javac/meth/InvokeMH_BAD68.java + test/tools/javac/meth/InvokeMH_BAD72.java + test/tools/javac/quid/QuotedIdent_BAD61.java + test/tools/javac/quid/QuotedIdent_BAD62.java + test/tools/javac/quid/QuotedIdent_BAD63.java + test/tools/javac/typeAnnotations/InnerClass.java + test/tools/javac/typeAnnotations/MultipleTargets.java + test/tools/javac/typeAnnotations/TypeParameterTarget.java + test/tools/javac/typeAnnotations/TypeUseTarget.java + test/tools/javac/typeAnnotations/attribution/Scopes.java + test/tools/javac/typeAnnotations/failures/AnnotationVersion.java + test/tools/javac/typeAnnotations/failures/AnnotationVersion.out + test/tools/javac/typeAnnotations/failures/IncompleteArray.java + test/tools/javac/typeAnnotations/failures/IncompleteArray.out + test/tools/javac/typeAnnotations/failures/IncompleteVararg.java + test/tools/javac/typeAnnotations/failures/IncompleteVararg.out + test/tools/javac/typeAnnotations/failures/IndexArray.java + test/tools/javac/typeAnnotations/failures/IndexArray.out + test/tools/javac/typeAnnotations/failures/LintCast.java + test/tools/javac/typeAnnotations/failures/LintCast.out + test/tools/javac/typeAnnotations/failures/OldArray.java + test/tools/javac/typeAnnotations/failures/OldArray.out + test/tools/javac/typeAnnotations/failures/Scopes.java + test/tools/javac/typeAnnotations/failures/Scopes.out + test/tools/javac/typeAnnotations/failures/StaticFields.java + test/tools/javac/typeAnnotations/failures/StaticFields.out + test/tools/javac/typeAnnotations/failures/StaticMethods.java + test/tools/javac/typeAnnotations/failures/StaticMethods.out + test/tools/javac/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out + test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java + test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out + test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java + test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out + test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java + test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out + test/tools/javac/typeAnnotations/failures/target/Constructor.java + test/tools/javac/typeAnnotations/failures/target/Constructor.out + test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java + test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out + test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java + test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out + test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java + test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out + test/tools/javac/typeAnnotations/failures/target/VoidMethod.java + test/tools/javac/typeAnnotations/failures/target/VoidMethod.out + test/tools/javac/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/typeAnnotations/newlocations/ClassExtends.java + test/tools/javac/typeAnnotations/newlocations/ClassLiterals.java + test/tools/javac/typeAnnotations/newlocations/ClassParameters.java + test/tools/javac/typeAnnotations/newlocations/ConstructorTypeArgs.java + test/tools/javac/typeAnnotations/newlocations/Expressions.java + test/tools/javac/typeAnnotations/newlocations/Fields.java + test/tools/javac/typeAnnotations/newlocations/LocalVariables.java + test/tools/javac/typeAnnotations/newlocations/MethodReturnType.java + test/tools/javac/typeAnnotations/newlocations/MethodTypeArgs.java + test/tools/javac/typeAnnotations/newlocations/MethodTypeParameters.java + test/tools/javac/typeAnnotations/newlocations/Parameters.java + test/tools/javac/typeAnnotations/newlocations/Receivers.java + test/tools/javac/typeAnnotations/newlocations/Throws.java + test/tools/javac/typeAnnotations/newlocations/TypeCasts.java + test/tools/javac/typeAnnotations/newlocations/TypeParameters.java + test/tools/javac/typeAnnotations/newlocations/Wildcards.java + test/tools/javap/typeAnnotations/ClassLiterals.java + test/tools/javap/typeAnnotations/JSR175Annotations.java + test/tools/javap/typeAnnotations/NewArray.java + test/tools/javap/typeAnnotations/Presence.java + test/tools/javap/typeAnnotations/PresenceInner.java + test/tools/javap/typeAnnotations/Visibility.java Changeset: 7c154fdc3547 Author: jjg Date: 2009-06-26 19:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7c154fdc3547 6854796: update JSR308 impl with latest code from type-annotations repo Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mernst at cs.washington.edu, mali at csail.mit.edu, mpapi at csail.mit.edu ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java Changeset: 464d58654324 Author: jjg Date: 2009-06-27 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/464d58654324 6855563: test broken after merge with latest parser Reviewed-by: jjg Contributed-by: mali at csail.mit.edu ! test/tools/javac/typeAnnotations/failures/OldArray.java - test/tools/javac/typeAnnotations/failures/OldArray.out Changeset: c391a167ac57 Author: tbell Date: 2009-06-28 00:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c391a167ac57 Merge Changeset: 7913e72a24b0 Author: jjg Date: 2009-06-29 17:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7913e72a24b0 6855993: fix comments in langtools launcher script Reviewed-by: ohair ! src/share/bin/launcher.sh-template Changeset: ec1acd3af057 Author: tbell Date: 2009-06-29 23:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ec1acd3af057 Merge Changeset: 24374861f91e Author: tbell Date: 2009-07-03 09:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/24374861f91e Merge Changeset: e4a1c76c1abb Author: peterz Date: 2009-06-23 12:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/e4a1c76c1abb 6844273: jdk/make/docs/CORE_PKGS.gmk does not list Nimbus Reviewed-by: prr ! src/share/classes/com/sun/tools/javac/resources/legacy.properties Changeset: ddef2ef424d8 Author: yan Date: 2009-06-25 00:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ddef2ef424d8 Merge - make/README - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java - test/tools/javac/code/ArrayClone.sh - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 09dc14c713f0 Author: yan Date: 2009-07-01 00:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/09dc14c713f0 Merge Changeset: d8f23a81d46f Author: yan Date: 2009-07-07 23:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/d8f23a81d46f Merge Changeset: 7e0056ded28c Author: xdono Date: 2009-07-13 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7e0056ded28c Added tag jdk7-b64 for changeset d8f23a81d46f ! .hgtags From yamauchi at google.com Wed Jul 15 16:38:02 2009 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 15 Jul 2009 16:38:02 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <4149a0430907151350t3d20ceb3h2dc4ef811b1eb3a1@mail.gmail.com> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> <4149a0430907151350t3d20ceb3h2dc4ef811b1eb3a1@mail.gmail.com> Message-ID: Looks good to me as well. Thanks! On Wed, Jul 15, 2009 at 1:50 PM, Chuck Rasbold wrote: > Looks good. Thanks. > > On Wed, Jul 15, 2009 at 1:37 PM, Tom Rodriguez > wrote: >> >> http://cr.openjdk.java.net/~never/6860469 is what I'm going to push with >> you and hiroshi marked as contributors. ?I added the copyright and fixed the >> test case run running with jtreg. ?The class needed to be public and the >> class name was missing from the @run line. >> >> tom >> >> On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: >> >>> I presume that Sun will add the copyright notice when the code is >>> committed, and of course, I'm OK with that. >>> >>> IANAL, but I'm reluctant to add the notice in advance, mostly because I >>> am not employed by Sun. >>> >>> On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez >>> wrote: >>> The test is missing the copyright notice but otherwise this looks good. >>> ?BTW, I ran a full ctw with this change both as is and as an assert that >>> checked for cases where this would produce a different control and I only >>> found 4 cases where it ever changed the answer and none of those triggered a >>> failure in the way the test case does. ?Hiroshi, thanks for tracking this >>> down and Chuck, thanks for distilling a test case. >>> >>> tom >>> >>> >>> On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: >>> >>> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >>> >>> Fixed 6860469: remix_address_expressions sets incorrect control causing >>> crash in split_if_with_block_post >>> >>> Consult the control node of both inputs when deciding where to place >>> new LShiftI node. >>> >>> Previously, we assumed the invar input should set the new node's >>> control, and the scale input was irrelevant for control's sake. >>> However, sometimes the invar input is a constant, allowing it to be >>> higher in the dom tree than the scale. >>> >>> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >>> >>> >>> >> > > From Vladimir.Kozlov at Sun.COM Wed Jul 15 16:40:50 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 15 Jul 2009 16:40:50 -0700 Subject: Request for reviews (S): 6851282: JIT miscompilation results in null entry in array when using CompressedOops Message-ID: <4A5E6902.6080600@sun.com> http://cr.openjdk.java.net/~kvn/6851282/webrev.00 Fixed 6851282: JIT miscompilation results in null entry in array when using CompressedOops Problem: PhiNode::Ideal() has optimization which pushes DecodeN node down through Phi. But it may set incorrect type (TOP) for new Phi node when it use DecodeN's input on dead path. Solution: Get type for new Phi from non dead path. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From thomas.rodriguez at sun.com Wed Jul 15 17:09:48 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 16 Jul 2009 00:09:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post Message-ID: <20090716000955.65B08E2DC@hg.openjdk.java.net> Changeset: fd50a67f97d1 Author: never Date: 2009-07-15 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fd50a67f97d1 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post Reviewed-by: never, kvn Contributed-by: yamauchi at google.com, rasbold at google.com ! src/share/vm/opto/loopopts.cpp + test/compiler/6860469/Test.java From martinrb at google.com Thu Jul 16 07:22:53 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 Jul 2009 07:22:53 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> Message-ID: <1ccfd1c10907160722i72c75b21m6fbc8da26a7b4576@mail.gmail.com> We're still working out legalities, but the precedent for legal notices for a source file that is non-Sun-authored is to not include the Sun copyright line Copyright 2009 Sun Microsystems, Inc. For example, here is a Google-authored file: http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/src/share/classes/java/util/TimSort.java.html (and files obtained from the public domain have no copyright line inside their legal notice at all) It's no big deal either way, especially for tests, as all contributors retain their rights under SCA. Martin On Wed, Jul 15, 2009 at 13:37, Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/6860469 is what I'm going to push with you and hiroshi marked as contributors. ?I added the copyright and fixed the test case run running with jtreg. ?The class needed to be public and the class name was missing from the @run line. > > tom > > On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: > >> I presume that Sun will add the copyright notice when the code is committed, and of course, I'm OK with that. >> >> IANAL, but I'm reluctant to add the notice in advance, mostly because I am not employed by Sun. >> >> On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez wrote: >> The test is missing the copyright notice but otherwise this looks good. ?BTW, I ran a full ctw with this change both as is and as an assert that checked for cases where this would produce a different control and I only found 4 cases where it ever changed the answer and none of those triggered a failure in the way the test case does. ?Hiroshi, thanks for tracking this down and Chuck, thanks for distilling a test case. >> >> tom >> >> >> On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: >> >> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >> >> Fixed 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post >> >> Consult the control node of both inputs when deciding where to place >> new LShiftI node. >> >> Previously, we assumed the invar input should set the new node's >> control, and the scale input was irrelevant for control's sake. >> However, sometimes the invar input is a constant, allowing it to be >> higher in the dom tree than the scale. >> >> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >> >> >> > From Thomas.Rodriguez at Sun.COM Thu Jul 16 11:42:29 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 16 Jul 2009 11:42:29 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <1ccfd1c10907160722i72c75b21m6fbc8da26a7b4576@mail.gmail.com> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> <1ccfd1c10907160722i72c75b21m6fbc8da26a7b4576@mail.gmail.com> Message-ID: Thanks for the explanation. I'm happy to correct it if you like. tom On Jul 16, 2009, at 7:22 AM, Martin Buchholz wrote: > We're still working out legalities, but the precedent for legal > notices > for a source file that is non-Sun-authored > is to not include the Sun copyright line > > Copyright 2009 Sun Microsystems, Inc. > > For example, here is a Google-authored file: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/src/share/classes/java/util/TimSort.java.html > > (and files obtained from the public domain have no copyright line > inside their legal notice at all) > > It's no big deal either way, especially for tests, > as all contributors retain their rights under SCA. > > Martin > > On Wed, Jul 15, 2009 at 13:37, Tom Rodriguez > wrote: >> >> http://cr.openjdk.java.net/~never/6860469 is what I'm going to push >> with you and hiroshi marked as contributors. I added the copyright >> and fixed the test case run running with jtreg. The class needed >> to be public and the class name was missing from the @run line. >> >> tom >> >> On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: >> >>> I presume that Sun will add the copyright notice when the code is >>> committed, and of course, I'm OK with that. >>> >>> IANAL, but I'm reluctant to add the notice in advance, mostly >>> because I am not employed by Sun. >>> >>> On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez >> > wrote: >>> The test is missing the copyright notice but otherwise this looks >>> good. BTW, I ran a full ctw with this change both as is and as an >>> assert that checked for cases where this would produce a different >>> control and I only found 4 cases where it ever changed the answer >>> and none of those triggered a failure in the way the test case >>> does. Hiroshi, thanks for tracking this down and Chuck, thanks >>> for distilling a test case. >>> >>> tom >>> >>> >>> On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: >>> >>> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >>> >>> Fixed 6860469: remix_address_expressions sets incorrect control >>> causing crash in split_if_with_block_post >>> >>> Consult the control node of both inputs when deciding where to place >>> new LShiftI node. >>> >>> Previously, we assumed the invar input should set the new node's >>> control, and the scale input was irrelevant for control's sake. >>> However, sometimes the invar input is a constant, allowing it to be >>> higher in the dom tree than the scale. >>> >>> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >>> >>> >>> >> From Thomas.Rodriguez at Sun.COM Thu Jul 16 12:51:19 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 16 Jul 2009 12:51:19 -0700 Subject: Request for reviews (S): 6851282: JIT miscompilation results in null entry in array when using CompressedOops In-Reply-To: <4A5E6902.6080600@sun.com> References: <4A5E6902.6080600@sun.com> Message-ID: <39C3BF3C-1CA2-400E-96EE-5766BE7FBA3C@sun.com> looks ok. tom On Jul 15, 2009, at 4:40 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6851282/webrev.00 > > Fixed 6851282: JIT miscompilation results in null entry in array > when using CompressedOops > > Problem: > PhiNode::Ideal() has optimization which pushes DecodeN node > down through Phi. But it may set incorrect type (TOP) for > new Phi node when it use DecodeN's input on dead path. > > Solution: > Get type for new Phi from non dead path. > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT > From rasbold at google.com Thu Jul 16 13:21:23 2009 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 16 Jul 2009 13:21:23 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> <1ccfd1c10907160722i72c75b21m6fbc8da26a7b4576@mail.gmail.com> Message-ID: <4149a0430907161321s2aae36aawdced7384bda9665b@mail.gmail.com> Let's follow the precedent. Please correct. If you are feeling generous, the Test in 6837094 could be fixed, too. Thanks. On Thu, Jul 16, 2009 at 11:42 AM, Tom Rodriguez wrote: > Thanks for the explanation. I'm happy to correct it if you like. > > tom > > > On Jul 16, 2009, at 7:22 AM, Martin Buchholz wrote: > > We're still working out legalities, but the precedent for legal notices >> for a source file that is non-Sun-authored >> is to not include the Sun copyright line >> >> Copyright 2009 Sun Microsystems, Inc. >> >> For example, here is a Google-authored file: >> >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/src/share/classes/java/util/TimSort.java.html >> >> (and files obtained from the public domain have no copyright line >> inside their legal notice at all) >> >> It's no big deal either way, especially for tests, >> as all contributors retain their rights under SCA. >> >> Martin >> >> On Wed, Jul 15, 2009 at 13:37, Tom Rodriguez >> wrote: >> >>> >>> http://cr.openjdk.java.net/~never/6860469is what I'm going to push with you and hiroshi marked as contributors. I >>> added the copyright and fixed the test case run running with jtreg. The >>> class needed to be public and the class name was missing from the @run line. >>> >>> tom >>> >>> On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: >>> >>> I presume that Sun will add the copyright notice when the code is >>>> committed, and of course, I'm OK with that. >>>> >>>> IANAL, but I'm reluctant to add the notice in advance, mostly because I >>>> am not employed by Sun. >>>> >>>> On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez < >>>> Thomas.Rodriguez at sun.com> wrote: >>>> The test is missing the copyright notice but otherwise this looks good. >>>> BTW, I ran a full ctw with this change both as is and as an assert that >>>> checked for cases where this would produce a different control and I only >>>> found 4 cases where it ever changed the answer and none of those triggered a >>>> failure in the way the test case does. Hiroshi, thanks for tracking this >>>> down and Chuck, thanks for distilling a test case. >>>> >>>> tom >>>> >>>> >>>> On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: >>>> >>>> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >>>> >>>> Fixed 6860469: remix_address_expressions sets incorrect control causing >>>> crash in split_if_with_block_post >>>> >>>> Consult the control node of both inputs when deciding where to place >>>> new LShiftI node. >>>> >>>> Previously, we assumed the invar input should set the new node's >>>> control, and the scale input was irrelevant for control's sake. >>>> However, sometimes the invar input is a constant, allowing it to be >>>> higher in the dom tree than the scale. >>>> >>>> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >>>> >>>> >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090716/6fa4afcb/attachment.html From Vladimir.Kozlov at Sun.COM Thu Jul 16 13:49:56 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 16 Jul 2009 13:49:56 -0700 Subject: Request for reviews (S): 6851282: JIT miscompilation results in null entry in array when using CompressedOops In-Reply-To: <39C3BF3C-1CA2-400E-96EE-5766BE7FBA3C@sun.com> References: <4A5E6902.6080600@sun.com> <39C3BF3C-1CA2-400E-96EE-5766BE7FBA3C@sun.com> Message-ID: <4A5F9274.306@sun.com> Thanks Tom Vladimir Tom Rodriguez wrote: > looks ok. > > tom > > On Jul 15, 2009, at 4:40 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6851282/webrev.00 >> >> Fixed 6851282: JIT miscompilation results in null entry in array when >> using CompressedOops >> >> Problem: >> PhiNode::Ideal() has optimization which pushes DecodeN node >> down through Phi. But it may set incorrect type (TOP) for >> new Phi node when it use DecodeN's input on dead path. >> >> Solution: >> Get type for new Phi from non dead path. >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test >> >> Other testing: >> JPRT >> > From Thomas.Rodriguez at Sun.COM Thu Jul 16 14:53:04 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 16 Jul 2009 14:53:04 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <4149a0430907161321s2aae36aawdced7384bda9665b@mail.gmail.com> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> <1ccfd1c10907160722i72c75b21m6fbc8da26a7b4576@mail.gmail.com> <4149a0430907161321s2aae36aawdced7384bda9665b@mail.gmail.com> Message-ID: <4AC1112E-7105-4214-90EA-7A9D93DECD4C@Sun.COM> Check out http://cr.openjdk.java.net/~never/6861513. tom On Jul 16, 2009, at 1:21 PM, Chuck Rasbold wrote: > Let's follow the precedent. Please correct. > > If you are feeling generous, the Test in 6837094 could be fixed, too. > > Thanks. > > On Thu, Jul 16, 2009 at 11:42 AM, Tom Rodriguez > wrote: > Thanks for the explanation. I'm happy to correct it if you like. > > tom > > > On Jul 16, 2009, at 7:22 AM, Martin Buchholz wrote: > > We're still working out legalities, but the precedent for legal > notices > for a source file that is non-Sun-authored > is to not include the Sun copyright line > > Copyright 2009 Sun Microsystems, Inc. > > For example, here is a Google-authored file: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/src/share/classes/java/util/TimSort.java.html > > (and files obtained from the public domain have no copyright line > inside their legal notice at all) > > It's no big deal either way, especially for tests, > as all contributors retain their rights under SCA. > > Martin > > On Wed, Jul 15, 2009 at 13:37, Tom Rodriguez > wrote: > > http://cr.openjdk.java.net/~never/6860469 is what I'm going to push > with you and hiroshi marked as contributors. I added the copyright > and fixed the test case run running with jtreg. The class needed to > be public and the class name was missing from the @run line. > > tom > > On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: > > I presume that Sun will add the copyright notice when the code is > committed, and of course, I'm OK with that. > > IANAL, but I'm reluctant to add the notice in advance, mostly > because I am not employed by Sun. > > On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez > wrote: > The test is missing the copyright notice but otherwise this looks > good. BTW, I ran a full ctw with this change both as is and as an > assert that checked for cases where this would produce a different > control and I only found 4 cases where it ever changed the answer > and none of those triggered a failure in the way the test case > does. Hiroshi, thanks for tracking this down and Chuck, thanks for > distilling a test case. > > tom > > > On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: > > http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 > > Fixed 6860469: remix_address_expressions sets incorrect control > causing crash in split_if_with_block_post > > Consult the control node of both inputs when deciding where to place > new LShiftI node. > > Previously, we assumed the invar input should set the new node's > control, and the scale input was irrelevant for control's sake. > However, sometimes the invar input is a constant, allowing it to be > higher in the dom tree than the scale. > > Fix provided by Hiroshi Yamauchi (yamauchi at google.com) > > > > > > From rasbold at google.com Thu Jul 16 15:19:19 2009 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 16 Jul 2009 15:19:19 -0700 Subject: Request for review (M): 6860469: remix_address_expressions sets incorrect control causing crash in split_if_with_block_post In-Reply-To: <4AC1112E-7105-4214-90EA-7A9D93DECD4C@Sun.COM> References: <4149a0430907150927s23b9b488w40a813a75281e670@mail.gmail.com> <4149a0430907151224t74468120i6438626236404a8b@mail.gmail.com> <1ccfd1c10907160722i72c75b21m6fbc8da26a7b4576@mail.gmail.com> <4149a0430907161321s2aae36aawdced7384bda9665b@mail.gmail.com> <4AC1112E-7105-4214-90EA-7A9D93DECD4C@Sun.COM> Message-ID: <4149a0430907161519h3246fd91v1e71010f31787be2@mail.gmail.com> Looks good. Thanks. On Thu, Jul 16, 2009 at 2:53 PM, Tom Rodriguez wrote: > Check out http://cr.openjdk.java.net/~never/6861513 > . > > tom > > > On Jul 16, 2009, at 1:21 PM, Chuck Rasbold wrote: > > Let's follow the precedent. Please correct. >> >> If you are feeling generous, the Test in 6837094 could be fixed, too. >> >> Thanks. >> >> On Thu, Jul 16, 2009 at 11:42 AM, Tom Rodriguez >> wrote: >> Thanks for the explanation. I'm happy to correct it if you like. >> >> tom >> >> >> On Jul 16, 2009, at 7:22 AM, Martin Buchholz wrote: >> >> We're still working out legalities, but the precedent for legal notices >> for a source file that is non-Sun-authored >> is to not include the Sun copyright line >> >> Copyright 2009 Sun Microsystems, Inc. >> >> For example, here is a Google-authored file: >> >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/src/share/classes/java/util/TimSort.java.html >> >> (and files obtained from the public domain have no copyright line >> inside their legal notice at all) >> >> It's no big deal either way, especially for tests, >> as all contributors retain their rights under SCA. >> >> Martin >> >> On Wed, Jul 15, 2009 at 13:37, Tom Rodriguez >> wrote: >> >> http://cr.openjdk.java.net/~never/6860469is what I'm going to push with you and hiroshi marked as contributors. I >> added the copyright and fixed the test case run running with jtreg. The >> class needed to be public and the class name was missing from the @run line. >> >> tom >> >> On Jul 15, 2009, at 12:24 PM, Chuck Rasbold wrote: >> >> I presume that Sun will add the copyright notice when the code is >> committed, and of course, I'm OK with that. >> >> IANAL, but I'm reluctant to add the notice in advance, mostly because I am >> not employed by Sun. >> >> On Wed, Jul 15, 2009 at 12:07 PM, Tom Rodriguez >> wrote: >> The test is missing the copyright notice but otherwise this looks good. >> BTW, I ran a full ctw with this change both as is and as an assert that >> checked for cases where this would produce a different control and I only >> found 4 cases where it ever changed the answer and none of those triggered a >> failure in the way the test case does. Hiroshi, thanks for tracking this >> down and Chuck, thanks for distilling a test case. >> >> tom >> >> >> On Jul 15, 2009, at 9:27 AM, Chuck Rasbold wrote: >> >> http://cr.openjdk.java.net/~rasbold/6860469/webrev.00 >> >> Fixed 6860469: remix_address_expressions sets incorrect control causing >> crash in split_if_with_block_post >> >> Consult the control node of both inputs when deciding where to place >> new LShiftI node. >> >> Previously, we assumed the invar input should set the new node's >> control, and the scale input was irrelevant for control's sake. >> However, sometimes the invar input is a constant, allowing it to be >> higher in the dom tree than the scale. >> >> Fix provided by Hiroshi Yamauchi (yamauchi at google.com) >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090716/fa2d0965/attachment.html From Changpeng.Fang at Sun.COM Thu Jul 16 17:16:32 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Thu, 16 Jul 2009 17:16:32 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> Message-ID: <4A5FC2E0.3010506@sun.com> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ Problem: The problem is in intrinsics Object.clone and Arrays.copyOf. When de-optimization occurs on the slow path for array/instance allocation, the Interpreter will continue execution in next bytecode after the slow allocation calls without actual copying. The fundamental problem is that the current vm does not have the logic for the compilers to specify reexecution for the interpreter if deoptimization happens for cases like intrinsics of Object.clone and Arrays.copyOf. Solution: We add such logic in the vm. (1) For C2, we add an "reexecute" field in JVMState to specify whether to reexecute this bytecode. This reexecute bit will be recorded as debug information through **describe_scope. At runtime, the deoptimizer will get the reexecution information at the time of unpack_frame through reading the scope. (2) There are some bytecodes that we have already known that the interpreter should re-execute them when deoptimization happens (e.g. _getfield and _putfield). For C2, we set the reexecute bit for the out JVMS (youngest one) for them at the time of adding safepoint edges. For C1, we simply set the reexecute bit for them at the time of ** **describe_scope. (3) For **Object.clone and Arrays.copyOf., we set the reexecute bit and pop off the argument when we intrinsify them. Tests: Passed specjvm98, JPRT and the test case of clone in the bug report. Since there are several previous email exchanges, I collect the questions from them and give a brief answer here: ============================ From kvn: ============================ >Also in src/share/vm/opto/callnode.hpp add an assert >to check that bci is no changed when _restart is set >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } I could not do this assertion here because sync_jvms() will set_bci and we have already set the restart (reexecute) before some sync_jvms calls. Do you think it ok for an assertion like assert(_bci== bci || !_restart, ""); whih means for a new bci the restart should be false? Thanks. =================== From jrose: =================== >Here's a nit: is_restart() in scopeDesc.hpp should be a const function. >I'd like to see comment in each case demonstrating why that the values captured in dummy_restart, and the throwaway restart in javaClasses.cpp (which should be called dummy_restart also) don't matter. Done! I appreciate if you can double check to see whether the comments are appropriate or not. Thanks. >I'd still like to see the restart decision made by continuation_for turned into an assert. At least compare it with is_restart(): > pc = Interpreter::continuation_for(method(), bcp, > callee_parameters, is_top_frame, use_next_mdp); > + assert(is_restart() == !use_next_mdp, ""); >If the assert fails, there may be a bug. Thanks for pointing out this. Now, after the redesign, continuation_for does not make decision whether to reexecute or continue. It is just used to compute the address for the continuation (next bytecode). I add a new function to compute the reexecution address Interpreter::deopt_reexecute_entry(...). What do you think of the new design? Thanks. ========================= From never: ========================= >I think the term reexecute should be used in place of restart since that terminology is used elsewhere. Actually I think should_reexecute is better than is_reexecute as well. Yes, reexecute better than restart here! Thanks. >I don't really like that the restart bit is associated with the bci. It implies that any scope can be reexecuted when it fact it's only the topmost one that can be. Given how these describing scopes is structured I'm not sure I see a better way though. I >don't see any asserts to enforce this for the scopeDescs either. Done ! Thanks The printing forms for ScopeDesc and JVMState should indicate if this is a restarted bytecode or not. The SA also needs to be updated to read these modified ScopeDescs. Done! Thanks. >I think manually toggling the restart bit back and forth should be avoided. Preserve the original and pass on the modified one or have a helper object that toggles the bit in it's constructor/destructor. I just design a new class "PreserveReexecuteAndSP" to save and restore the reexecute bit and sp. Thanks. Thank you so much for your help and inputs. Changpeng -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090716/1feb2d25/attachment.html From vladimir.kozlov at sun.com Thu Jul 16 17:18:59 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 17 Jul 2009 00:18:59 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6851742: (EA) allocation elimination doesn't work with UseG1GC Message-ID: <20090717001909.A4FD6E3EE@hg.openjdk.java.net> Changeset: fc4be448891f Author: kvn Date: 2009-07-16 14:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc4be448891f 6851742: (EA) allocation elimination doesn't work with UseG1GC Summary: Fix eliminate_card_mark() to eliminate G1 pre/post barriers. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.hpp From john.coomes at sun.com Thu Jul 16 23:16:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Jul 2009 06:16:31 +0000 Subject: hg: jdk7/hotspot-comp: 5 new changesets Message-ID: <20090717061632.2B1DDE45D@hg.openjdk.java.net> Changeset: 8ca3d95b1ea3 Author: xdono Date: 2009-06-22 10:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/8ca3d95b1ea3 6853596: Update Build README-build.html with new info regarding update for Solaris 10u2 and BOOTDIR update Reviewed-by: tbell, ohair ! README-builds.html Changeset: 38c6ee1015aa Author: xdono Date: 2009-06-29 22:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/38c6ee1015aa Merge ! README-builds.html Changeset: 9ed059501673 Author: xdono Date: 2009-07-08 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/9ed059501673 Merge Changeset: e01380cd1de4 Author: xdono Date: 2009-07-14 14:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/e01380cd1de4 Merge Changeset: 6bad5e3fe503 Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/6bad5e3fe503 Added tag jdk7-b65 for changeset e01380cd1de4 ! .hgtags From john.coomes at sun.com Thu Jul 16 23:21:33 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Jul 2009 06:21:33 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b65 for changeset 97fd9b42f5c2 Message-ID: <20090717062135.35AE4E464@hg.openjdk.java.net> Changeset: a821e059a961 Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/a821e059a961 Added tag jdk7-b65 for changeset 97fd9b42f5c2 ! .hgtags From john.coomes at sun.com Thu Jul 16 23:33:27 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Jul 2009 06:33:27 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b65 for changeset 008c662e0ee9 Message-ID: <20090717063329.7BC41E469@hg.openjdk.java.net> Changeset: 22f9d5d5b5fe Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/22f9d5d5b5fe Added tag jdk7-b65 for changeset 008c662e0ee9 ! .hgtags From john.coomes at sun.com Thu Jul 16 23:38:33 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Jul 2009 06:38:33 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b65 for changeset aa22a1be5866 Message-ID: <20090717063836.76340E46E@hg.openjdk.java.net> Changeset: fa8712c099ed Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/fa8712c099ed Added tag jdk7-b65 for changeset aa22a1be5866 ! .hgtags From john.coomes at sun.com Thu Jul 16 23:43:44 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Jul 2009 06:43:44 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b65 for changeset 382a27aa78d3 Message-ID: <20090717064426.6AD98E476@hg.openjdk.java.net> Changeset: 6ec0174d4f36 Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6ec0174d4f36 Added tag jdk7-b65 for changeset 382a27aa78d3 ! .hgtags From john.coomes at sun.com Thu Jul 16 23:59:25 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Jul 2009 06:59:25 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b65 for changeset 7e0056ded28c Message-ID: <20090717065929.9F246E47B@hg.openjdk.java.net> Changeset: 634f519d6f9a Author: xdono Date: 2009-07-16 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/634f519d6f9a Added tag jdk7-b65 for changeset 7e0056ded28c ! .hgtags From thomas.rodriguez at sun.com Fri Jul 17 00:48:58 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 17 Jul 2009 07:48:58 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6861513: correct copyright attribution in test for 6837094 and 6860469 Message-ID: <20090717074907.4A40BE54C@hg.openjdk.java.net> Changeset: 84770322b304 Author: never Date: 2009-07-16 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/84770322b304 6861513: correct copyright attribution in test for 6837094 and 6860469 Reviewed-by: rasbold ! test/compiler/6837094/Test.java ! test/compiler/6860469/Test.java From vladimir.kozlov at sun.com Fri Jul 17 01:07:40 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 17 Jul 2009 08:07:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090717080743.DE3DCE55D@hg.openjdk.java.net> Changeset: 64219d2a6493 Author: kvn Date: 2009-07-16 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/64219d2a6493 6851282: JIT miscompilation results in null entry in array when using CompressedOops Summary: Get type for new Phi from non dead path. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp + test/compiler/6851282/Test.java Changeset: 606c988ff684 Author: kvn Date: 2009-07-17 00:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/606c988ff684 Merge From Vladimir.Kozlov at Sun.COM Fri Jul 17 17:55:55 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 17 Jul 2009 17:55:55 -0700 Subject: CR 6826736/6-pool *Escalated* Updated, P3 hotspot/garbage_coll CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A60D52A.4050107@sun.com> References: <29744595.1247829423875.JavaMail.sbladm@swsblss4-new> <4A60ADAF.4090306@sun.com> <4A60B036.1050006@sun.com> <4A60B5D6.90504@sun.com> <4A60D52A.4050107@sun.com> Message-ID: <4A611D9B.8050808@sun.com> I spoke too soon. This behavior is intentional for performance. On sparc we generate code which produce live oop with narrow_oop_base_addr value when narrow oop is NULL : Load_narrow_oop memory, narrow_oop_reg decode_not_null narrow_oop_reg, base_reg // The problem is base_reg may be referenced by // debug info before the next implicit check: Load [base_reg + offset], val_reg NullCheck base_reg Also decode_not_null may flow above NULL check since it does not have control edge. I think, it is fine since all code users of a decoded value are below NULL check (or it has implicit NULL check). Except a debug info. The implicit NULL exception code checks for narrow_oop_base_addr value. I think we have to fix deoptimization code and GC also to check for such oops values and convert them to NULL. I will work on it. The alternative is disable narrow oop implicit NULL check on sparc and performance lost on all platforms. Thanks, Vladimir Vladimir Kozlov wrote: > Yahoo!!! I built a small test case which shows the problem: > GCM placed decode_not_null node above implicit null check. > > Vladimir > > Y. Srinivas Ramakrishna wrote: >> Thanks, Vladimir; no hurry! >> >> -- ramki >> >> Vladimir Kozlov wrote: >>> The fix for 6851282 did NOT fix the 6826736 problem. >>> >>> Yesterday I found the cause of 6826736 and I am trying to >>> prepare the fix about which I talked with Ramki. >>> Now I can reproduce the problem myself after >>> adding dynamic 0 assert check into decode mach node. >>> Give me few days. >>> >>> thanks, >>> Vladimir >>> >>> Y. Srinivas Ramakrishna wrote: >>>> >>>> Hi Poonam, Vladimir -- >>>> >>>> Poonam.Bajaj at Sun.COM wrote: >>>>> Sun Confidential: Internal only >>>>> >>>>> *Synopsis*: CMS: core dump with -XX:+UseCompressedOops >>>>> >>>>> >>>>> r12 contains oop being accessed : 0xfffffd7fe85ff000 >>>>> >>>>> And it is 4K (0xfffffd7fe8600000 - 0xfffffd7fe85ff000 = 0x1000) >>>>> below the start of eden space. >>>>> >>>>> Fix for 6851282 has been integrated. I am going to test with this >>>>> fix and see if it resolves this crash too. >>>>> >>>>> *** (#2 of 2): 2009-07-17 10:57:37 GMT+00:00 poonam.bajaj at sun.com >>>>> *** Last Edit: 2009-07-17 11:07:54 GMT+00:00 poonam.bajaj at sun.com >>>>> >>>> Thanks Poonam. Vladimir stopped by yesterday to ask whether I could >>>> test with the fix he had >>>> for the problem and that he would send me the fix. I am guessing he >>>> was referring to the fix he >>>> put back for 6851282, but i was not 100% sure because he was working >>>> on, i think, an >>>> additional issue as well. Anyway, I am cc'ing Vladimir to check with >>>> him that this was indeed >>>> the fix with which he wanted us to run/verify. >>>> >>>> Vladimir? >>>> >>>> thanks! >>>> -- ramki >>>>> ... >>>>> >>>>> === *Escalations* >>>>> ============================================================ >>>>> >>>>> Escalation Number 1-26544441 >>>>> Escalation Date 2009-07-14 10:46:06 GMT+00:00 >>>>> Status In Progress >>>>> Management Alert Customer Advocate apollo >>>>> Escalation Engineer poonam.bajaj at sun.com From Christian.Thalinger at Sun.COM Sun Jul 19 02:53:31 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Sun, 19 Jul 2009 11:53:31 +0200 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A5D32D8.60204@sun.com> References: <4A5D32D8.60204@sun.com> Message-ID: <4A62ED1B.10107@Sun.COM> Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6860599/webrev.00 > > Fixed 6860599: Relax nodes limit check for Output phase > > Problem: > I got several CTW cases when without EA C2 "gracefully" > bailout compilation when nodes limit check failed during > macro nodes expansion. And with EA it passed macro nodes > expansion but crashed with ASSERT during Output phase. > One byte MachNop nodes are used in debug mode for loops > and calls alignment in Output phase. As result for a big > method the node limit could be reached. > > Solution: > Increase nodes limit (double) for Output phase. What I don't understand with this patch is, it changes the node limit but this is done for every output. It's not limited to e.g. debug mode. Is this what you indented? -- Christian From Vladimir.Kozlov at Sun.COM Mon Jul 20 09:32:30 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 20 Jul 2009 09:32:30 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A62ED1B.10107@Sun.COM> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> Message-ID: <4A649C1E.4010406@sun.com> Christian, The only nodes limit check done in Output is in Node::verify_construction() and it is assert() which only works in debug mode. Did I understand your question correctly? Thanks, Vladimir Christian Thalinger wrote: > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >> >> Fixed 6860599: Relax nodes limit check for Output phase >> >> Problem: >> I got several CTW cases when without EA C2 "gracefully" >> bailout compilation when nodes limit check failed during >> macro nodes expansion. And with EA it passed macro nodes >> expansion but crashed with ASSERT during Output phase. >> One byte MachNop nodes are used in debug mode for loops >> and calls alignment in Output phase. As result for a big >> method the node limit could be reached. >> >> Solution: >> Increase nodes limit (double) for Output phase. > > What I don't understand with this patch is, it changes the node limit > but this is done for every output. It's not limited to e.g. debug mode. > Is this what you indented? > > -- Christian From Christian.Thalinger at Sun.COM Mon Jul 20 09:35:57 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 20 Jul 2009 18:35:57 +0200 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A649C1E.4010406@sun.com> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> Message-ID: <4A649CED.2040709@Sun.COM> Vladimir Kozlov wrote: > Christian, > > The only nodes limit check done in Output is in > Node::verify_construction() and it is assert() > which only works in debug mode. > Did I understand your question correctly? I was talking about the added increase_nodes_limit() call in Compile::Output(). This one is called on every compile and the limited is increased, right? -- Christian From Vladimir.Kozlov at Sun.COM Mon Jul 20 10:38:42 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 20 Jul 2009 10:38:42 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A649CED.2040709@Sun.COM> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> <4A649CED.2040709@Sun.COM> Message-ID: <4A64ABA2.3060604@sun.com> Yes, it is the purpose of this change. If we passed all previous checks we should not bail out (or assert) when we are already generating code. Yes, it is not only for debug mode. Compile object is constructed for each compilation and the limit is initialized by default value so we don't have geometric progression here. Vladimir Christian Thalinger wrote: > Vladimir Kozlov wrote: >> Christian, >> >> The only nodes limit check done in Output is in >> Node::verify_construction() and it is assert() >> which only works in debug mode. >> Did I understand your question correctly? > > I was talking about the added increase_nodes_limit() call in > Compile::Output(). This one is called on every compile and the limited > is increased, right? > > -- Christian From Thomas.Rodriguez at Sun.COM Mon Jul 20 10:52:13 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 20 Jul 2009 10:52:13 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A649C1E.4010406@sun.com> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> Message-ID: <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> If the intent is just to suppress the assert after a certain point in code generation, why don't you just add a flag in the Compile for that? Adding _node_limit and just doubling it seems arbitrary and doesn't really capture intent. tom On Jul 20, 2009, at 9:32 AM, Vladimir Kozlov wrote: > Christian, > > The only nodes limit check done in Output is in > Node::verify_construction() and it is assert() > which only works in debug mode. > Did I understand your question correctly? > > Thanks, > Vladimir > > > Christian Thalinger wrote: >> Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >>> >>> Fixed 6860599: Relax nodes limit check for Output phase >>> >>> Problem: >>> I got several CTW cases when without EA C2 "gracefully" >>> bailout compilation when nodes limit check failed during >>> macro nodes expansion. And with EA it passed macro nodes >>> expansion but crashed with ASSERT during Output phase. >>> One byte MachNop nodes are used in debug mode for loops >>> and calls alignment in Output phase. As result for a big >>> method the node limit could be reached. >>> >>> Solution: >>> Increase nodes limit (double) for Output phase. >> What I don't understand with this patch is, it changes the node limit >> but this is done for every output. It's not limited to e.g. debug >> mode. >> Is this what you indented? >> -- Christian From Vladimir.Kozlov at Sun.COM Mon Jul 20 12:53:02 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 20 Jul 2009 12:53:02 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> Message-ID: <4A64CB1E.5000203@sun.com> Tom, I do not want disable the assert since it may catch a situation when something goes wrong in Output(), I want relax it. I can use an other flag instread of doubling: void increase_nodes_limit() { _nodes_limit = CodeGenMaxNodeLimit; } And I can use nodes_limit() only in Node::verify_construction() if everybody don't want changes in other places where MaxNodeLimit is used. Thanks, Vladimir Tom Rodriguez wrote: > If the intent is just to suppress the assert after a certain point in > code generation, why don't you just add a flag in the Compile for that? > Adding _node_limit and just doubling it seems arbitrary and doesn't > really capture intent. > > tom > > On Jul 20, 2009, at 9:32 AM, Vladimir Kozlov wrote: > >> Christian, >> >> The only nodes limit check done in Output is in >> Node::verify_construction() and it is assert() >> which only works in debug mode. >> Did I understand your question correctly? >> >> Thanks, >> Vladimir >> >> >> Christian Thalinger wrote: >>> Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >>>> >>>> Fixed 6860599: Relax nodes limit check for Output phase >>>> >>>> Problem: >>>> I got several CTW cases when without EA C2 "gracefully" >>>> bailout compilation when nodes limit check failed during >>>> macro nodes expansion. And with EA it passed macro nodes >>>> expansion but crashed with ASSERT during Output phase. >>>> One byte MachNop nodes are used in debug mode for loops >>>> and calls alignment in Output phase. As result for a big >>>> method the node limit could be reached. >>>> >>>> Solution: >>>> Increase nodes limit (double) for Output phase. >>> What I don't understand with this patch is, it changes the node limit >>> but this is done for every output. It's not limited to e.g. debug mode. >>> Is this what you indented? >>> -- Christian > From Thomas.Rodriguez at Sun.COM Mon Jul 20 13:10:20 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 20 Jul 2009 13:10:20 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A64CB1E.5000203@sun.com> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> <4A64CB1E.5000203@sun.com> Message-ID: On Jul 20, 2009, at 12:53 PM, Vladimir Kozlov wrote: > Tom, > > I do not want disable the assert since it may catch a situation > when something goes wrong in Output(), I want relax it. Oh. Doubling it seems like disabling it to me. Relaxing it would be increasing it slightly or increasing the limit based on the amount we actually expect it to increase by. Isn't the real problem that the bailout limits aren't triggering when they should? I'd rather see proper bailout bounds instead of just moving the MaxNodeLimit around. tom > > I can use an other flag instread of doubling: > > void increase_nodes_limit() { _nodes_limit = CodeGenMaxNodeLimit; } > > And I can use nodes_limit() only in Node::verify_construction() > if everybody don't want changes in other places where MaxNodeLimit > is used. > Thanks, > Vladimir > > Tom Rodriguez wrote: >> If the intent is just to suppress the assert after a certain point >> in code generation, why don't you just add a flag in the Compile >> for that? Adding _node_limit and just doubling it seems arbitrary >> and doesn't really capture intent. >> tom >> On Jul 20, 2009, at 9:32 AM, Vladimir Kozlov wrote: >>> Christian, >>> >>> The only nodes limit check done in Output is in >>> Node::verify_construction() and it is assert() >>> which only works in debug mode. >>> Did I understand your question correctly? >>> >>> Thanks, >>> Vladimir >>> >>> >>> Christian Thalinger wrote: >>>> Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >>>>> >>>>> Fixed 6860599: Relax nodes limit check for Output phase >>>>> >>>>> Problem: >>>>> I got several CTW cases when without EA C2 "gracefully" >>>>> bailout compilation when nodes limit check failed during >>>>> macro nodes expansion. And with EA it passed macro nodes >>>>> expansion but crashed with ASSERT during Output phase. >>>>> One byte MachNop nodes are used in debug mode for loops >>>>> and calls alignment in Output phase. As result for a big >>>>> method the node limit could be reached. >>>>> >>>>> Solution: >>>>> Increase nodes limit (double) for Output phase. >>>> What I don't understand with this patch is, it changes the node >>>> limit >>>> but this is done for every output. It's not limited to e.g. >>>> debug mode. >>>> Is this what you indented? >>>> -- Christian From Vladimir.Kozlov at Sun.COM Mon Jul 20 14:57:29 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 20 Jul 2009 14:57:29 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> <4A64CB1E.5000203@sun.com> Message-ID: <4A64E849.90101@sun.com> There is no compilation bailout in Output() and I don't want to add one. I think, to have the assert is enough. And I don't think bailout limits are the problem. We should finish code generation if the compilation passed bailouts during optimizations and RA. I agree that instead of simple doubling I can use something like this: _nodes_limit = _nodes_limit + NodeLimitFudgeFactor + ncalls*3 + nloops*(OptoLoopAlignment-1))) Thanks, Vladimir Tom Rodriguez wrote: > > On Jul 20, 2009, at 12:53 PM, Vladimir Kozlov wrote: > >> Tom, >> >> I do not want disable the assert since it may catch a situation >> when something goes wrong in Output(), I want relax it. > > Oh. Doubling it seems like disabling it to me. Relaxing it would be > increasing it slightly or increasing the limit based on the amount we > actually expect it to increase by. Isn't the real problem that the > bailout limits aren't triggering when they should? I'd rather see > proper bailout bounds instead of just moving the MaxNodeLimit around. > > tom > >> >> I can use an other flag instread of doubling: >> >> void increase_nodes_limit() { _nodes_limit = CodeGenMaxNodeLimit; } >> >> And I can use nodes_limit() only in Node::verify_construction() >> if everybody don't want changes in other places where MaxNodeLimit >> is used. > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> If the intent is just to suppress the assert after a certain point in >>> code generation, why don't you just add a flag in the Compile for >>> that? Adding _node_limit and just doubling it seems arbitrary and >>> doesn't really capture intent. >>> tom >>> On Jul 20, 2009, at 9:32 AM, Vladimir Kozlov wrote: >>>> Christian, >>>> >>>> The only nodes limit check done in Output is in >>>> Node::verify_construction() and it is assert() >>>> which only works in debug mode. >>>> Did I understand your question correctly? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> Christian Thalinger wrote: >>>>> Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >>>>>> >>>>>> Fixed 6860599: Relax nodes limit check for Output phase >>>>>> >>>>>> Problem: >>>>>> I got several CTW cases when without EA C2 "gracefully" >>>>>> bailout compilation when nodes limit check failed during >>>>>> macro nodes expansion. And with EA it passed macro nodes >>>>>> expansion but crashed with ASSERT during Output phase. >>>>>> One byte MachNop nodes are used in debug mode for loops >>>>>> and calls alignment in Output phase. As result for a big >>>>>> method the node limit could be reached. >>>>>> >>>>>> Solution: >>>>>> Increase nodes limit (double) for Output phase. >>>>> What I don't understand with this patch is, it changes the node limit >>>>> but this is done for every output. It's not limited to e.g. debug >>>>> mode. >>>>> Is this what you indented? >>>>> -- Christian > From John.Rose at Sun.COM Tue Jul 21 03:03:06 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 21 Jul 2009 03:03:06 -0700 Subject: for review (S): 6862576: vmIntrinsics needs cleanup in order to support JSR 292 intrinsics Message-ID: <06FDF961-F940-4AAE-8FA2-F128B5E7FFF2@sun.com> http://cr.openjdk.java.net/~jrose/6862576/webrev.00/ From Vladimir.Kozlov at Sun.COM Tue Jul 21 11:11:24 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 21 Jul 2009 11:11:24 -0700 Subject: for review (S): 6862576: vmIntrinsics needs cleanup in order to support JSR 292 intrinsics In-Reply-To: <06FDF961-F940-4AAE-8FA2-F128B5E7FFF2@sun.com> References: <06FDF961-F940-4AAE-8FA2-F128B5E7FFF2@sun.com> Message-ID: <4A6604CC.3090405@sun.com> John, Changes look good. The intrinsic _fillInStackTrace is also special and should be moved after LAST_COMPILER_INLINE. Thanks, Vladimir John Rose wrote: > http://cr.openjdk.java.net/~jrose/6862576/webrev.00/ > From Thomas.Rodriguez at Sun.COM Tue Jul 21 13:00:31 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Jul 2009 13:00:31 -0700 Subject: review (S) for 6857159: local schedule failed with checkcast of Thread.currentThread() Message-ID: <3F361495-9BBE-4ABB-B127-237985995E4D@Sun.COM> http://cr.openjdk.java.net/~never/6857159 From Vladimir.Kozlov at Sun.COM Tue Jul 21 13:56:41 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 21 Jul 2009 13:56:41 -0700 Subject: review (S) for 6857159: local schedule failed with checkcast of Thread.currentThread() In-Reply-To: <3F361495-9BBE-4ABB-B127-237985995E4D@Sun.COM> References: <3F361495-9BBE-4ABB-B127-237985995E4D@Sun.COM> Message-ID: <4A662B89.1080806@sun.com> Tom, Can you use is_immutable_load() instead of uses_immutable_memory() since it is load from immutable memory? And change comment to include LoadRange: // node matches ideal 'LoadKlassNode' 'LoadNKlassNode' --- // node matches ideal 'LoadKlass' 'LoadNKlass' 'LoadRange' Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6857159 From Thomas.Rodriguez at Sun.COM Tue Jul 21 14:31:06 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Jul 2009 14:31:06 -0700 Subject: review (S) for 6857159: local schedule failed with checkcast of Thread.currentThread() In-Reply-To: <4A662B89.1080806@sun.com> References: <3F361495-9BBE-4ABB-B127-237985995E4D@Sun.COM> <4A662B89.1080806@sun.com> Message-ID: <0C06D022-8CC2-4BEF-A43C-A536E331E29F@Sun.COM> > Can you use is_immutable_load() instead of uses_immutable_memory() > since it is load from immutable memory? That's what I had originally and I changed it since it's technically not quite true. The LoadKlass that reads from the cache isn't actually reading immutable memory since the cache can be updated, though never by generated code. Neither name is really right. Maybe it should just be disable_antidep_check with a comment explaining why? > And change comment to include LoadRange: > > // node matches ideal 'LoadKlassNode' 'LoadNKlassNode' > > --- > > // node matches ideal 'LoadKlass' 'LoadNKlass' 'LoadRange' Ok. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6857159 From Thomas.Rodriguez at Sun.COM Tue Jul 21 16:03:17 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Jul 2009 16:03:17 -0700 Subject: review (S) for 6857159: local schedule failed with checkcast of Thread.currentThread() In-Reply-To: <0C06D022-8CC2-4BEF-A43C-A536E331E29F@Sun.COM> References: <3F361495-9BBE-4ABB-B127-237985995E4D@Sun.COM> <4A662B89.1080806@sun.com> <0C06D022-8CC2-4BEF-A43C-A536E331E29F@Sun.COM> Message-ID: <441C096F-021C-4690-B3E5-68DAC21DE7C1@sun.com> I changed the name to skip_antidep_check and put in a more extensive comment. tom On Jul 21, 2009, at 2:31 PM, Tom Rodriguez wrote: >> Can you use is_immutable_load() instead of uses_immutable_memory() >> since it is load from immutable memory? > > That's what I had originally and I changed it since it's technically > not quite true. The LoadKlass that reads from the cache isn't > actually reading immutable memory since the cache can be updated, > though never by generated code. Neither name is really right. > Maybe it should just be disable_antidep_check with a comment > explaining why? > >> And change comment to include LoadRange: >> >> // node matches ideal 'LoadKlassNode' 'LoadNKlassNode' >> >> --- >> >> // node matches ideal 'LoadKlass' 'LoadNKlass' 'LoadRange' > > Ok. > > tom > >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6857159 > From Vladimir.Kozlov at Sun.COM Tue Jul 21 16:09:34 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 21 Jul 2009 16:09:34 -0700 Subject: review (S) for 6857159: local schedule failed with checkcast of Thread.currentThread() In-Reply-To: <441C096F-021C-4690-B3E5-68DAC21DE7C1@sun.com> References: <3F361495-9BBE-4ABB-B127-237985995E4D@Sun.COM> <4A662B89.1080806@sun.com> <0C06D022-8CC2-4BEF-A43C-A536E331E29F@Sun.COM> <441C096F-021C-4690-B3E5-68DAC21DE7C1@sun.com> Message-ID: <4A664AAE.9080402@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > I changed the name to skip_antidep_check and put in a more extensive > comment. > > tom > > On Jul 21, 2009, at 2:31 PM, Tom Rodriguez wrote: > >>> Can you use is_immutable_load() instead of uses_immutable_memory() >>> since it is load from immutable memory? >> >> That's what I had originally and I changed it since it's technically >> not quite true. The LoadKlass that reads from the cache isn't >> actually reading immutable memory since the cache can be updated, >> though never by generated code. Neither name is really right. Maybe >> it should just be disable_antidep_check with a comment explaining why? >> >>> And change comment to include LoadRange: >>> >>> // node matches ideal 'LoadKlassNode' 'LoadNKlassNode' >>> >>> --- >>> >>> // node matches ideal 'LoadKlass' 'LoadNKlass' 'LoadRange' >> >> Ok. >> >> tom >> >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6857159 >> > From Changpeng.Fang at Sun.COM Tue Jul 21 16:56:59 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Tue, 21 Jul 2009 16:56:59 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A5FC2E0.3010506@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> Message-ID: <4A6655CB.8080203@sun.com> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ Please take a final look at the implementation of reexecute bit. Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : (1) In C2 JVMState, use a three state field (instead of a boolean) to represent the reexecute bit: * class JVMState : public ResourceObj {* *+ public:* *+ typedef enum {* *+ RE_Undefined = -1, // not defined -- will be translated into false later* *+ RE_False = 0, // false -- do not reexecute* *+ RE_True = 1 // true -- reexecute the bytecode* *+ } REBit; //ReExecution Bit* *+ * In this way, we can keep the original defined reexecute bit (true or false) when we are going to determine the reexecute bit by bytecode. *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && //don't touch defined values* *+ should_reexecute_implied_by_bytecode(out_jvms)) {* *+ out_jvms->set_reexecute(JVMState::RE_True);* *+ }* *+ * (2) Renamed Intepreter::continuation_for to be Interpreter:: deopt_continue_after_entry. Renamed Interpreter::bytecodes_to_reexecute to Interpreter::bytecode_should_reexecute Thanks, Changpeng On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ > > Problem: > The problem is in intrinsics Object.clone and Arrays.copyOf. When > de-optimization occurs on the slow path for array/instance > allocation, the Interpreter will continue execution in next bytecode > after the slow allocation calls without actual copying. The > fundamental problem is that the current vm does not have the logic for > the compilers to specify reexecution for the interpreter > if deoptimization happens for cases like intrinsics of Object.clone > and Arrays.copyOf. > > Solution: > We add such logic in the vm. > (1) For C2, we add an "reexecute" field in JVMState to specify whether > to reexecute this bytecode. This reexecute bit will be > recorded as debug information through **describe_scope. At > runtime, the deoptimizer will get the reexecution information > at the time of unpack_frame through reading the scope. > (2) There are some bytecodes that we have already known that the > interpreter should re-execute them when deoptimization > happens (e.g. _getfield and _putfield). For C2, we set the > reexecute bit for the out JVMS (youngest one) for them at the > time of adding safepoint edges. For C1, we simply set the reexecute > bit for them at the time of ** **describe_scope. > (3) For **Object.clone and Arrays.copyOf., we set the reexecute bit > and pop off the argument when we intrinsify them. > > Tests: > Passed specjvm98, JPRT and the test case of clone in the bug report. > > > Since there are several previous email exchanges, I collect the > questions from them and give a brief answer here: > > ============================ > >From kvn: > ============================ > >Also in src/share/vm/opto/callnode.hpp add an assert > >to check that bci is no changed when _restart is set > >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } > > I could not do this assertion here because sync_jvms() will set_bci > and we have already set the restart (reexecute) before > some sync_jvms calls. Do you think it ok for an assertion like > assert(_bci== bci || !_restart, ""); whih means for a new bci the restart > should be false? Thanks. > > =================== > From jrose: > =================== > >Here's a nit: is_restart() in scopeDesc.hpp should be a const function. > >I'd like to see comment in each case demonstrating why that the > values captured in dummy_restart, and the throwaway restart in > javaClasses.cpp (which should be called dummy_restart also) don't matter. > Done! I appreciate if you can double check to see whether the comments > are appropriate or not. Thanks. > > >I'd still like to see the restart decision made by continuation_for > turned into an assert. At least compare it with is_restart(): >> pc = Interpreter::continuation_for(method(), bcp, >> callee_parameters, is_top_frame, use_next_mdp); >> + assert(is_restart() == !use_next_mdp, ""); > >If the assert fails, there may be a bug. > Thanks for pointing out this. Now, after the redesign, > continuation_for does not make decision whether to reexecute or > continue. It is just used to compute the address > for the continuation (next bytecode). I add a new function to compute > the reexecution address Interpreter::deopt_reexecute_entry(...). What > do you think of the new > design? Thanks. > > ========================= > >From never: > ========================= > >I think the term reexecute should be used in place of restart since > that terminology is used elsewhere. Actually I think should_reexecute > is better than is_reexecute as well. > Yes, reexecute better than restart here! Thanks. > > >I don't really like that the restart bit is associated with the bci. > It implies that any scope can be reexecuted when it fact it's only the > topmost one that can be. Given how these describing scopes is > structured I'm not sure I see a better way though. I >don't see any > asserts to enforce this for the scopeDescs either. > Done ! Thanks > The printing forms for ScopeDesc and JVMState should indicate if this > is a restarted bytecode or not. The SA also needs to be updated to > read these modified ScopeDescs. > Done! Thanks. > > >I think manually toggling the restart bit back and forth should be > avoided. Preserve the original and pass on the modified one or have a > helper object that toggles the bit in it's constructor/destructor. > I just design a new class "PreserveReexecuteAndSP" to save and restore > the reexecute bit and sp. Thanks. > > > Thank you so much for your help and inputs. > > Changpeng > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090721/02b68294/attachment.html From Thomas.Rodriguez at Sun.COM Tue Jul 21 16:57:28 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 21 Jul 2009 16:57:28 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <4A64E849.90101@sun.com> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> <4A64CB1E.5000203@sun.com> <4A64E849.90101@sun.com> Message-ID: <0EFE4288-03E9-4F40-B361-0F39BFFB7BD0@Sun.COM> On Jul 20, 2009, at 2:57 PM, Vladimir Kozlov wrote: > There is no compilation bailout in Output() and I don't > want to add one. I think, to have the assert is enough. > > And I don't think bailout limits are the problem. > We should finish code generation if the compilation passed > bailouts during optimizations and RA. I interpret that as meaning we're missing appropriate bailouts before we start to ensure that we can complete code generation. > > I agree that instead of simple doubling I can use something like this: > > _nodes_limit = _nodes_limit + NodeLimitFudgeFactor + > ncalls*3 + nloops*(OptoLoopAlignment-1))) Can't you just a put in a check_node_count call before we start Output to check that we have this margin left? tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Jul 20, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> I do not want disable the assert since it may catch a situation >>> when something goes wrong in Output(), I want relax it. >> Oh. Doubling it seems like disabling it to me. Relaxing it would >> be increasing it slightly or increasing the limit based on the >> amount we actually expect it to increase by. Isn't the real >> problem that the bailout limits aren't triggering when they >> should? I'd rather see proper bailout bounds instead of just >> moving the MaxNodeLimit around. >> tom >>> >>> I can use an other flag instread of doubling: >>> >>> void increase_nodes_limit() { _nodes_limit = CodeGenMaxNodeLimit; } >>> >>> And I can use nodes_limit() only in Node::verify_construction() >>> if everybody don't want changes in other places where MaxNodeLimit >>> is used. >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> If the intent is just to suppress the assert after a certain >>>> point in code generation, why don't you just add a flag in the >>>> Compile for that? Adding _node_limit and just doubling it seems >>>> arbitrary and doesn't really capture intent. >>>> tom >>>> On Jul 20, 2009, at 9:32 AM, Vladimir Kozlov wrote: >>>>> Christian, >>>>> >>>>> The only nodes limit check done in Output is in >>>>> Node::verify_construction() and it is assert() >>>>> which only works in debug mode. >>>>> Did I understand your question correctly? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> Christian Thalinger wrote: >>>>>> Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >>>>>>> >>>>>>> Fixed 6860599: Relax nodes limit check for Output phase >>>>>>> >>>>>>> Problem: >>>>>>> I got several CTW cases when without EA C2 "gracefully" >>>>>>> bailout compilation when nodes limit check failed during >>>>>>> macro nodes expansion. And with EA it passed macro nodes >>>>>>> expansion but crashed with ASSERT during Output phase. >>>>>>> One byte MachNop nodes are used in debug mode for loops >>>>>>> and calls alignment in Output phase. As result for a big >>>>>>> method the node limit could be reached. >>>>>>> >>>>>>> Solution: >>>>>>> Increase nodes limit (double) for Output phase. >>>>>> What I don't understand with this patch is, it changes the node >>>>>> limit >>>>>> but this is done for every output. It's not limited to e.g. >>>>>> debug mode. >>>>>> Is this what you indented? >>>>>> -- Christian From Vladimir.Kozlov at Sun.COM Tue Jul 21 18:28:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 21 Jul 2009 18:28:07 -0700 Subject: Request for reviews (S): 6860599: Relax nodes limit check for Output phase In-Reply-To: <0EFE4288-03E9-4F40-B361-0F39BFFB7BD0@Sun.COM> References: <4A5D32D8.60204@sun.com> <4A62ED1B.10107@Sun.COM> <4A649C1E.4010406@sun.com> <3380D260-830D-4DEE-A06C-E76F73EB31E7@sun.com> <4A64CB1E.5000203@sun.com> <4A64E849.90101@sun.com> <0EFE4288-03E9-4F40-B361-0F39BFFB7BD0@Sun.COM> Message-ID: <4A666B27.2070904@sun.com> Tom Rodriguez wrote: >> >> I agree that instead of simple doubling I can use something like this: >> >> _nodes_limit = _nodes_limit + NodeLimitFudgeFactor + >> ncalls*3 + nloops*(OptoLoopAlignment-1))) > > Can't you just a put in a check_node_count call before we start Output > to check that we have this margin left? I am too greedy :) I wanted a method to be compiled as it happens in product version but then I realized that we bailout from Macro expansion phase at the same situation. So it is fine to bailout from Output also. Yes, I will use check_node_count to bailout from Output. Thanks, Vladimir > > tom > >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> On Jul 20, 2009, at 12:53 PM, Vladimir Kozlov wrote: >>>> Tom, >>>> >>>> I do not want disable the assert since it may catch a situation >>>> when something goes wrong in Output(), I want relax it. >>> Oh. Doubling it seems like disabling it to me. Relaxing it would be >>> increasing it slightly or increasing the limit based on the amount we >>> actually expect it to increase by. Isn't the real problem that the >>> bailout limits aren't triggering when they should? I'd rather see >>> proper bailout bounds instead of just moving the MaxNodeLimit around. >>> tom >>>> >>>> I can use an other flag instread of doubling: >>>> >>>> void increase_nodes_limit() { _nodes_limit = CodeGenMaxNodeLimit; } >>>> >>>> And I can use nodes_limit() only in Node::verify_construction() >>>> if everybody don't want changes in other places where MaxNodeLimit >>>> is used. >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> If the intent is just to suppress the assert after a certain point >>>>> in code generation, why don't you just add a flag in the Compile >>>>> for that? Adding _node_limit and just doubling it seems arbitrary >>>>> and doesn't really capture intent. >>>>> tom >>>>> On Jul 20, 2009, at 9:32 AM, Vladimir Kozlov wrote: >>>>>> Christian, >>>>>> >>>>>> The only nodes limit check done in Output is in >>>>>> Node::verify_construction() and it is assert() >>>>>> which only works in debug mode. >>>>>> Did I understand your question correctly? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> >>>>>> Christian Thalinger wrote: >>>>>>> Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/6860599/webrev.00 >>>>>>>> >>>>>>>> Fixed 6860599: Relax nodes limit check for Output phase >>>>>>>> >>>>>>>> Problem: >>>>>>>> I got several CTW cases when without EA C2 "gracefully" >>>>>>>> bailout compilation when nodes limit check failed during >>>>>>>> macro nodes expansion. And with EA it passed macro nodes >>>>>>>> expansion but crashed with ASSERT during Output phase. >>>>>>>> One byte MachNop nodes are used in debug mode for loops >>>>>>>> and calls alignment in Output phase. As result for a big >>>>>>>> method the node limit could be reached. >>>>>>>> >>>>>>>> Solution: >>>>>>>> Increase nodes limit (double) for Output phase. >>>>>>> What I don't understand with this patch is, it changes the node >>>>>>> limit >>>>>>> but this is done for every output. It's not limited to e.g. >>>>>>> debug mode. >>>>>>> Is this what you indented? >>>>>>> -- Christian > From thomas.rodriguez at sun.com Tue Jul 21 20:19:07 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 22 Jul 2009 03:19:07 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6857159: local schedule failed with checkcast of Thread.currentThread() Message-ID: <20090722031916.DAE51EAFE@hg.openjdk.java.net> Changeset: f9094a5e1c8a Author: never Date: 2009-07-21 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f9094a5e1c8a 6857159: local schedule failed with checkcast of Thread.currentThread() Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp + test/compiler/6857159/Test6857159.java + test/compiler/6857159/Test6857159.sh From john.rose at sun.com Wed Jul 22 01:06:28 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 22 Jul 2009 08:06:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090722080639.E9909EB8C@hg.openjdk.java.net> Changeset: 75596850f863 Author: jrose Date: 2009-07-21 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75596850f863 6862576: vmIntrinsics needs cleanup in order to support JSR 292 intrinsics Summary: remove useless lazy evaluation of intrinsics; add LAST_COMPILER_INLINE to help categorize them Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp Changeset: 17173cb6e48d Author: jrose Date: 2009-07-21 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/17173cb6e48d Merge From John.Rose at Sun.COM Wed Jul 22 01:53:36 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 22 Jul 2009 01:53:36 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 Message-ID: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> In order to inline method handles at invokedynamic instructions, it is necessary to manipulate MethodHandle and CallSite constants from generated code. Since these objects are created by ordinary user code and subject to usual GC, they are not preallocated in the perm gen. Currently compiled code requires that any oop embedded as an instruction constant or any other nmethod part must be OopDesc::is_perm. For example, internal method objects and classes and interned strings are permanent so that they can be manipulated from compiled code. This restriction is a bug for JSR 292. Luckily, there is a simple fix. http://cr.openjdk.java.net/~jrose/6862576/webrev.00/ From Vladimir.Kozlov at Sun.COM Wed Jul 22 12:35:28 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 22 Jul 2009 12:35:28 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops Message-ID: <4A676A00.7070606@sun.com> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops Problem: Compiled code may produce decoded oop = narrow_oop_base when a narrow oop implicit null check is used. The narrow_oop_base could be NULL or be the address of the page below heap depending on the used mode of compressed oops. Such decoded oop could live across a safepoint and as result referenced in oopMap and debug info. The implicit NULL exception code checks for such oop value but deoptimization code and GC does not. And this cause the problem. Solution: Fix deoptimization code and GC to check for such oops values. During deoptimization convert them to NULL. And ignore them for GC (like NULL values are ignored). Added the regression test which shows the problem. Reviewed by: Fix verified (y/n): y, regression test Other testing: JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot From Paul.Hohensee at Sun.COM Wed Jul 22 12:51:14 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 22 Jul 2009 15:51:14 -0400 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A676A00.7070606@sun.com> References: <4A676A00.7070606@sun.com> Message-ID: <4A676DB2.9080700@sun.com> You've got 4 uses of this expression Universe::narrow_oop_base() == (address)(void*)(*foo) You might write a new method in Universe to factor it out, vis bool is_narrow_oop_base(void* addr) { return narrow_oop_base() == (address)addr); } Paul Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6826736/webrev.01 > > Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops > > Problem: > Compiled code may produce decoded oop = narrow_oop_base > when a narrow oop implicit null check is used. > The narrow_oop_base could be NULL or be the address > of the page below heap depending on the used mode of > compressed oops. Such decoded oop could live across > a safepoint and as result referenced in oopMap and debug info. > The implicit NULL exception code checks for such oop value > but deoptimization code and GC does not. And this cause > the problem. > > Solution: > Fix deoptimization code and GC to check for such oops values. > During deoptimization convert them to NULL. > And ignore them for GC (like NULL values are ignored). > > Added the regression test which shows the problem. > > Reviewed by: > > Fix verified (y/n): y, regression test > > Other testing: > JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot > From Vladimir.Kozlov at Sun.COM Wed Jul 22 13:33:14 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 22 Jul 2009 13:33:14 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A676DB2.9080700@sun.com> References: <4A676A00.7070606@sun.com> <4A676DB2.9080700@sun.com> Message-ID: <4A67778A.40107@sun.com> Thanks, Paul I will do that. Thanks, Vladimir Paul Hohensee wrote: > You've got 4 uses of this expression > > Universe::narrow_oop_base() == (address)(void*)(*foo) > > You might write a new method in Universe to factor it out, vis > > bool is_narrow_oop_base(void* addr) { > return narrow_oop_base() == (address)addr); > } > > Paul > > Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 >> >> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops >> >> Problem: >> Compiled code may produce decoded oop = narrow_oop_base >> when a narrow oop implicit null check is used. >> The narrow_oop_base could be NULL or be the address >> of the page below heap depending on the used mode of >> compressed oops. Such decoded oop could live across >> a safepoint and as result referenced in oopMap and debug info. >> The implicit NULL exception code checks for such oop value >> but deoptimization code and GC does not. And this cause >> the problem. >> >> Solution: >> Fix deoptimization code and GC to check for such oops values. >> During deoptimization convert them to NULL. >> And ignore them for GC (like NULL values are ignored). >> >> Added the regression test which shows the problem. >> >> Reviewed by: >> >> Fix verified (y/n): y, regression test >> >> Other testing: >> JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot >> From Vladimir.Kozlov at Sun.COM Wed Jul 22 13:41:15 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 22 Jul 2009 13:41:15 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A6655CB.8080203@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> Message-ID: <4A67796B.5050604@sun.com> I would use REState name instead of REBit. Also why you did not add the assert we talked about in set_bci()? Otherwise looks good. Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ > > Please take a final look at the implementation of reexecute bit. > > Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : > > (1) In C2 JVMState, use a three state field (instead of a boolean) to > represent the reexecute bit: > > * class JVMState : public ResourceObj {* > *+ public:* > *+ typedef enum {* > *+ RE_Undefined = -1, // not defined -- will be translated into false later* > *+ RE_False = 0, // false -- do not reexecute* > *+ RE_True = 1 // true -- reexecute the bytecode* > *+ } REBit; //ReExecution Bit* > *+ * > > In this way, we can keep the original defined reexecute bit (true or > false) when we are going to determine > the reexecute bit by bytecode. > > *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && //don't touch defined values* > *+ should_reexecute_implied_by_bytecode(out_jvms)) {* > *+ out_jvms->set_reexecute(JVMState::RE_True);* > *+ }* > *+ * > > (2) Renamed Intepreter::continuation_for to be Interpreter:: > deopt_continue_after_entry. > Renamed Interpreter::bytecodes_to_reexecute to > Interpreter::bytecode_should_reexecute > > > Thanks, > > Changpeng > > > On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara > United States wrote: >> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >> >> Problem: >> The problem is in intrinsics Object.clone and Arrays.copyOf. When >> de-optimization occurs on the slow path for array/instance >> allocation, the Interpreter will continue execution in next bytecode >> after the slow allocation calls without actual copying. The >> fundamental problem is that the current vm does not have the logic for >> the compilers to specify reexecution for the interpreter >> if deoptimization happens for cases like intrinsics of Object.clone >> and Arrays.copyOf. >> >> Solution: >> We add such logic in the vm. >> (1) For C2, we add an "reexecute" field in JVMState to specify whether >> to reexecute this bytecode. This reexecute bit will be >> recorded as debug information through **describe_scope. At >> runtime, the deoptimizer will get the reexecution information >> at the time of unpack_frame through reading the scope. >> (2) There are some bytecodes that we have already known that the >> interpreter should re-execute them when deoptimization >> happens (e.g. _getfield and _putfield). For C2, we set the >> reexecute bit for the out JVMS (youngest one) for them at the >> time of adding safepoint edges. For C1, we simply set the reexecute >> bit for them at the time of ** **describe_scope. >> (3) For **Object.clone and Arrays.copyOf., we set the reexecute bit >> and pop off the argument when we intrinsify them. >> >> Tests: >> Passed specjvm98, JPRT and the test case of clone in the bug report. >> >> >> Since there are several previous email exchanges, I collect the >> questions from them and give a brief answer here: >> >> ============================ >> >From kvn: >> ============================ >> >Also in src/share/vm/opto/callnode.hpp add an assert >> >to check that bci is no changed when _restart is set >> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >> >> I could not do this assertion here because sync_jvms() will set_bci >> and we have already set the restart (reexecute) before >> some sync_jvms calls. Do you think it ok for an assertion like >> assert(_bci== bci || !_restart, ""); whih means for a new bci the restart >> should be false? Thanks. >> >> =================== >> From jrose: >> =================== >> >Here's a nit: is_restart() in scopeDesc.hpp should be a const function. >> >I'd like to see comment in each case demonstrating why that the >> values captured in dummy_restart, and the throwaway restart in >> javaClasses.cpp (which should be called dummy_restart also) don't matter. >> Done! I appreciate if you can double check to see whether the comments >> are appropriate or not. Thanks. >> >> >I'd still like to see the restart decision made by continuation_for >> turned into an assert. At least compare it with is_restart(): >>> pc = Interpreter::continuation_for(method(), bcp, >>> callee_parameters, is_top_frame, use_next_mdp); >>> + assert(is_restart() == !use_next_mdp, ""); >> >If the assert fails, there may be a bug. >> Thanks for pointing out this. Now, after the redesign, >> continuation_for does not make decision whether to reexecute or >> continue. It is just used to compute the address >> for the continuation (next bytecode). I add a new function to compute >> the reexecution address Interpreter::deopt_reexecute_entry(...). What >> do you think of the new >> design? Thanks. >> >> ========================= >> >From never: >> ========================= >> >I think the term reexecute should be used in place of restart since >> that terminology is used elsewhere. Actually I think should_reexecute >> is better than is_reexecute as well. >> Yes, reexecute better than restart here! Thanks. >> >> >I don't really like that the restart bit is associated with the bci. >> It implies that any scope can be reexecuted when it fact it's only the >> topmost one that can be. Given how these describing scopes is >> structured I'm not sure I see a better way though. I >don't see any >> asserts to enforce this for the scopeDescs either. >> Done ! Thanks >> The printing forms for ScopeDesc and JVMState should indicate if this >> is a restarted bytecode or not. The SA also needs to be updated to >> read these modified ScopeDescs. >> Done! Thanks. >> >> >I think manually toggling the restart bit back and forth should be >> avoided. Preserve the original and pass on the modified one or have a >> helper object that toggles the bit in it's constructor/destructor. >> I just design a new class "PreserveReexecuteAndSP" to save and restore >> the reexecute bit and sp. Thanks. >> >> >> Thank you so much for your help and inputs. >> >> Changpeng >> >> > From John.Coomes at sun.com Wed Jul 22 13:44:50 2009 From: John.Coomes at sun.com (John Coomes) Date: Wed, 22 Jul 2009 13:44:50 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A676A00.7070606@sun.com> References: <4A676A00.7070606@sun.com> Message-ID: <19047.31298.280175.604186@sun.com> Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: > > http://cr.openjdk.java.net/~kvn/6826736/webrev.01 > > Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops > > Problem: > Compiled code may produce decoded oop = narrow_oop_base > when a narrow oop implicit null check is used. > ... > Solution: > Fix deoptimization code and GC to check for such oops values. > During deoptimization convert them to NULL. > And ignore them for GC (like NULL values are ignored). Looks reasonable to me, but I don't know this code. Spotted a couple of typos: 412 // is interesting in NULL. Change to interesting to interested. 432 assert((*loc) == (oop)NULL || Universe::narrow_oop_base() != (address)(void*)(*loc), 433 "found non valid value pointer"); Change "non valid" to invalid. FWIW, I also like Paul's suggestion of is_narrow_oop_base(void*). -John From Vladimir.Kozlov at Sun.COM Wed Jul 22 13:42:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 22 Jul 2009 13:42:39 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <19047.31298.280175.604186@sun.com> References: <4A676A00.7070606@sun.com> <19047.31298.280175.604186@sun.com> Message-ID: <4A6779BF.7090009@sun.com> Thank you, John I will fix comments. Vladimir John Coomes wrote: > Vladimir Kozlov (Vladimir.Kozlov at Sun.COM) wrote: >> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 >> >> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops >> >> Problem: >> Compiled code may produce decoded oop = narrow_oop_base >> when a narrow oop implicit null check is used. >> ... >> Solution: >> Fix deoptimization code and GC to check for such oops values. >> During deoptimization convert them to NULL. >> And ignore them for GC (like NULL values are ignored). > > Looks reasonable to me, but I don't know this code. Spotted a couple > of typos: > > 412 // is interesting in NULL. > > Change to interesting to interested. > > > > 432 assert((*loc) == (oop)NULL || Universe::narrow_oop_base() != (address)(void*)(*loc), > 433 "found non valid value pointer"); > > Change "non valid" to invalid. > > FWIW, I also like Paul's suggestion of is_narrow_oop_base(void*). > > -John > From Y.S.Ramakrishna at Sun.COM Wed Jul 22 14:02:41 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 22 Jul 2009 14:02:41 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A676DB2.9080700@sun.com> References: <4A676A00.7070606@sun.com> <4A676DB2.9080700@sun.com> Message-ID: <4A677E71.2090805@Sun.COM> Hi Vladimir -- i am fine with the fix. I worry just a little bit about the decision to filter/suppress these "null-equivalent" oop locations by the oop-map code for some future use case where we want to apply a closure to all oop-holding locations irrespective of whether the value is null; i do not however have a ready use case in mind at the moment. Would it be beneficial, for the future and/or the unwary, to add appropriate documentation about this filtering in the header file where the all_do() and oops_do() methods are declared? Rest looks good; thanks! -- ramki On 07/22/09 12:51, Paul Hohensee wrote: > You've got 4 uses of this expression > > Universe::narrow_oop_base() == (address)(void*)(*foo) > > You might write a new method in Universe to factor it out, vis > > bool is_narrow_oop_base(void* addr) { > return narrow_oop_base() == (address)addr); > } > > Paul > > Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 >> >> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops >> >> Problem: >> Compiled code may produce decoded oop = narrow_oop_base >> when a narrow oop implicit null check is used. >> The narrow_oop_base could be NULL or be the address >> of the page below heap depending on the used mode of >> compressed oops. Such decoded oop could live across >> a safepoint and as result referenced in oopMap and debug info. >> The implicit NULL exception code checks for such oop value >> but deoptimization code and GC does not. And this cause >> the problem. >> >> Solution: >> Fix deoptimization code and GC to check for such oops values. >> During deoptimization convert them to NULL. >> And ignore them for GC (like NULL values are ignored). >> >> Added the regression test which shows the problem. >> >> Reviewed by: >> >> Fix verified (y/n): y, regression test >> >> Other testing: >> JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot >> From Thomas.Rodriguez at Sun.COM Wed Jul 22 14:06:37 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 22 Jul 2009 14:06:37 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A676A00.7070606@sun.com> References: <4A676A00.7070606@sun.com> Message-ID: <11960083-634A-4BC6-880C-FF153247A328@sun.com> Looks good. tom On Jul 22, 2009, at 12:35 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6826736/webrev.01 > > Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops > > Problem: > Compiled code may produce decoded oop = narrow_oop_base > when a narrow oop implicit null check is used. > The narrow_oop_base could be NULL or be the address > of the page below heap depending on the used mode of > compressed oops. Such decoded oop could live across > a safepoint and as result referenced in oopMap and debug info. > The implicit NULL exception code checks for such oop value > but deoptimization code and GC does not. And this cause > the problem. > > Solution: > Fix deoptimization code and GC to check for such oops values. > During deoptimization convert them to NULL. > And ignore them for GC (like NULL values are ignored). > > Added the regression test which shows the problem. > > Reviewed by: > > Fix verified (y/n): y, regression test > > Other testing: > JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot > From Vladimir.Kozlov at Sun.COM Wed Jul 22 14:16:36 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 22 Jul 2009 14:16:36 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A677E71.2090805@Sun.COM> References: <4A676A00.7070606@sun.com> <4A676DB2.9080700@sun.com> <4A677E71.2090805@Sun.COM> Message-ID: <4A6781B4.2080209@sun.com> Thanks, Ramki There is oops verification code in OopMapSet::all_do() before the call closure->do_oop() which the bug fail. This is why I used filter before oops verification. I will add a comment into oopMap.hpp. Thanks, Vladimir Y.S.Ramakrishna at Sun.COM wrote: > Hi Vladimir -- i am fine with the fix. I worry just a little bit > about the decision to filter/suppress these "null-equivalent" oop locations > by the oop-map code for some future use case where we want to > apply a closure to all oop-holding locations irrespective of > whether the value is null; i do not however have a ready use case > in mind at the moment. Would it be beneficial, for the future and/or the > unwary, to add appropriate documentation about this filtering > in the header file where the all_do() and oops_do() methods > are declared? > > Rest looks good; thanks! > -- ramki > > On 07/22/09 12:51, Paul Hohensee wrote: >> You've got 4 uses of this expression >> >> Universe::narrow_oop_base() == (address)(void*)(*foo) >> >> You might write a new method in Universe to factor it out, vis >> >> bool is_narrow_oop_base(void* addr) { >> return narrow_oop_base() == (address)addr); >> } >> >> Paul >> >> Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 >>> >>> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops >>> >>> Problem: >>> Compiled code may produce decoded oop = narrow_oop_base >>> when a narrow oop implicit null check is used. >>> The narrow_oop_base could be NULL or be the address >>> of the page below heap depending on the used mode of >>> compressed oops. Such decoded oop could live across >>> a safepoint and as result referenced in oopMap and debug info. >>> The implicit NULL exception code checks for such oop value >>> but deoptimization code and GC does not. And this cause >>> the problem. >>> >>> Solution: >>> Fix deoptimization code and GC to check for such oops values. >>> During deoptimization convert them to NULL. >>> And ignore them for GC (like NULL values are ignored). >>> >>> Added the regression test which shows the problem. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, regression test >>> >>> Other testing: >>> JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot >>> > From Thomas.Rodriguez at Sun.COM Wed Jul 22 14:24:15 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 22 Jul 2009 14:24:15 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A677E71.2090805@Sun.COM> References: <4A676A00.7070606@sun.com> <4A676DB2.9080700@sun.com> <4A677E71.2090805@Sun.COM> Message-ID: <33CBCCEF-ED4B-4EA0-AD3B-5621E156F392@sun.com> If we do that then I think we should suppress NULL uniformly instead of only under certain conditions. tom On Jul 22, 2009, at 2:02 PM, Y.S.Ramakrishna at Sun.COM wrote: > Hi Vladimir -- i am fine with the fix. I worry just a little bit > about the decision to filter/suppress these "null-equivalent" oop > locations > by the oop-map code for some future use case where we want to > apply a closure to all oop-holding locations irrespective of > whether the value is null; i do not however have a ready use case > in mind at the moment. Would it be beneficial, for the future and/or > the > unwary, to add appropriate documentation about this filtering > in the header file where the all_do() and oops_do() methods > are declared? > > Rest looks good; thanks! > -- ramki > > On 07/22/09 12:51, Paul Hohensee wrote: >> You've got 4 uses of this expression >> Universe::narrow_oop_base() == (address)(void*)(*foo) >> You might write a new method in Universe to factor it out, vis >> bool is_narrow_oop_base(void* addr) { >> return narrow_oop_base() == (address)addr); >> } >> Paul >> Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 >>> >>> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops >>> >>> Problem: >>> Compiled code may produce decoded oop = narrow_oop_base >>> when a narrow oop implicit null check is used. >>> The narrow_oop_base could be NULL or be the address >>> of the page below heap depending on the used mode of >>> compressed oops. Such decoded oop could live across >>> a safepoint and as result referenced in oopMap and debug info. >>> The implicit NULL exception code checks for such oop value >>> but deoptimization code and GC does not. And this cause >>> the problem. >>> >>> Solution: >>> Fix deoptimization code and GC to check for such oops values. >>> During deoptimization convert them to NULL. >>> And ignore them for GC (like NULL values are ignored). >>> >>> Added the regression test which shows the problem. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, regression test >>> >>> Other testing: >>> JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot >>> > From Y.S.Ramakrishna at Sun.COM Wed Jul 22 14:12:55 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 22 Jul 2009 14:12:55 -0700 Subject: Request for reviews (S): 6826736: CMS: core dump with -XX:+UseCompressedOops In-Reply-To: <4A677E71.2090805@Sun.COM> References: <4A676A00.7070606@sun.com> <4A676DB2.9080700@sun.com> <4A677E71.2090805@Sun.COM> Message-ID: <4A6780D7.5090901@Sun.COM> Never mind. I realized that the old code already filters null-holding locations, so my fears about new behaviours this introduces are ill-founded. Sorry for the noise. -- ramki On 07/22/09 14:02, Y.S.Ramakrishna at Sun.COM wrote: > Hi Vladimir -- i am fine with the fix. I worry just a little bit > about the decision to filter/suppress these "null-equivalent" oop locations > by the oop-map code for some future use case where we want to > apply a closure to all oop-holding locations irrespective of > whether the value is null; i do not however have a ready use case > in mind at the moment. Would it be beneficial, for the future and/or the > unwary, to add appropriate documentation about this filtering > in the header file where the all_do() and oops_do() methods > are declared? > > Rest looks good; thanks! > -- ramki > > On 07/22/09 12:51, Paul Hohensee wrote: >> You've got 4 uses of this expression >> >> Universe::narrow_oop_base() == (address)(void*)(*foo) >> >> You might write a new method in Universe to factor it out, vis >> >> bool is_narrow_oop_base(void* addr) { >> return narrow_oop_base() == (address)addr); >> } >> >> Paul >> >> Vladimir Kozlov wrote: >>> >>> http://cr.openjdk.java.net/~kvn/6826736/webrev.01 >>> >>> Fixed 6826736: CMS: core dump with -XX:+UseCompressedOops >>> >>> Problem: >>> Compiled code may produce decoded oop = narrow_oop_base >>> when a narrow oop implicit null check is used. >>> The narrow_oop_base could be NULL or be the address >>> of the page below heap depending on the used mode of >>> compressed oops. Such decoded oop could live across >>> a safepoint and as result referenced in oopMap and debug info. >>> The implicit NULL exception code checks for such oop value >>> but deoptimization code and GC does not. And this cause >>> the problem. >>> >>> Solution: >>> Fix deoptimization code and GC to check for such oops values. >>> During deoptimization convert them to NULL. >>> And ignore them for GC (like NULL values are ignored). >>> >>> Added the regression test which shows the problem. >>> >>> Reviewed by: >>> >>> Fix verified (y/n): y, regression test >>> >>> Other testing: >>> JPRT, CTW with/without UseCompressedOops and +/- ScavengeALot >>> > > From vladimir.kozlov at sun.com Wed Jul 22 19:05:43 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 23 Jul 2009 02:05:43 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6826736: CMS: core dump with -XX:+UseCompressedOops Message-ID: <20090723020552.47818EC78@hg.openjdk.java.net> Changeset: 5314d85ffd54 Author: kvn Date: 2009-07-22 15:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5314d85ffd54 6826736: CMS: core dump with -XX:+UseCompressedOops Summary: Fix deoptimization code and OopMapSet::all_do() to check for oop = narrow_oop_base. Reviewed-by: jcoomes, phh, ysr, never ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/stackValue.cpp + test/compiler/6826736/Test.java From Christian.Thalinger at Sun.COM Thu Jul 23 02:21:30 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 23 Jul 2009 11:21:30 +0200 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A67796B.5050604@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> Message-ID: <4A682B9A.9060602@Sun.COM> Vladimir Kozlov wrote: > I would use REState name instead of REBit. I always like names that tell you what they are for. Could we use ReexecuteState (and Reexecute_Undefined, ...) instead? If I would read REState in the code, I would think of regex stuff... -- Christian From John.Rose at Sun.COM Thu Jul 23 02:24:09 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 23 Jul 2009 02:24:09 -0700 Subject: for review (L): 6858164: invokedynamic code needs some cleanup (post-6655638) Message-ID: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> http://cr.openjdk.java.net/~jrose/6858164/vm-webrev.01/ Summary: These are fixes for method handles proper. - correctly raises exceptions - supports safe bitwise "raw" conversions (e.g., int -> void) - fixes bugs (various, small) revealed by VerifyMethodHandles - dead code is removed - debugging support is improved Still to follow: - more bug fixes to the invokedynamic instruction - runtime simplification for invokedynamic - compiler support for invokedynamic - inlining of method handles - API adjustments that affect the JVM (mainly, removing private supertypes) From Changpeng.Fang at Sun.COM Thu Jul 23 08:23:13 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Thu, 23 Jul 2009 08:23:13 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A682B9A.9060602@Sun.COM> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A682B9A.9060602@Sun.COM> Message-ID: <4A688061.1030602@sun.com> On 07/23/09 02:21, Christian Thalinger wrote: > Vladimir Kozlov wrote: > >> I would use REState name instead of REBit. >> > > I always like names that tell you what they are for. Could we use > ReexecuteState (and Reexecute_Undefined, ...) instead? If I would read > REState in the code, I would think of regex stuff... > > Sure, I will change to ReexecuteState (and Reexecute_Undefined, ...) Thanks, Changpeng > -- Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20090723/970ba23a/attachment.html From Vladimir.Kozlov at Sun.COM Thu Jul 23 09:48:10 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 23 Jul 2009 09:48:10 -0700 Subject: Request for reviews (updated)(M): 6860599: nodes limit could be reached in Output phase Message-ID: <4A68944A.2030708@sun.com> I updated changes based on the discussion. I also changed the subject of the bug. http://cr.openjdk.java.net/~kvn/6860599/webrev.02 Fixed 6860599: nodes limit could be reached in Output phase Problem: I got several CTW cases when without EA C2 "gracefully" bailout compilation when nodes limit check failed during macro nodes expansion. And with EA it passed macro nodes expansion but crashed with ASSERT during Output phase. One byte MachNop nodes are used in debug mode for loops and calls alignment in Output phase. As result for a big method the node limit could be reached. Solution: Bailout compilation if nodes limit could be reached during Output phase. Remove unneeded MachNop nodes creation (after each block) used only to get its size. Collect additional information (inner loops and java calls counts) during final_graph_reshaping. Rename Final_Reshape_Counts fpu variable to frc since now it contains more information. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT, CTW From Thomas.Rodriguez at Sun.COM Thu Jul 23 13:47:22 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 23 Jul 2009 13:47:22 -0700 Subject: Request for reviews (updated)(M): 6860599: nodes limit could be reached in Output phase In-Reply-To: <4A68944A.2030708@sun.com> References: <4A68944A.2030708@sun.com> Message-ID: <704D09C8-A12F-4C9E-A82F-CAD549923EF6@sun.com> Looks ok to me. tom On Jul 23, 2009, at 9:48 AM, Vladimir Kozlov wrote: > I updated changes based on the discussion. > I also changed the subject of the bug. > > http://cr.openjdk.java.net/~kvn/6860599/webrev.02 > > Fixed 6860599: nodes limit could be reached in Output phase > > Problem: > I got several CTW cases when without EA C2 "gracefully" > bailout compilation when nodes limit check failed during > macro nodes expansion. And with EA it passed macro nodes > expansion but crashed with ASSERT during Output phase. > One byte MachNop nodes are used in debug mode for loops > and calls alignment in Output phase. As result for a big > method the node limit could be reached. > > Solution: > Bailout compilation if nodes limit could be reached > during Output phase. Remove unneeded MachNop nodes creation > (after each block) used only to get its size. > Collect additional information (inner loops and java calls > counts) during final_graph_reshaping. > Rename Final_Reshape_Counts fpu variable to frc since now > it contains more information. > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT, CTW > From vladimir.kozlov at sun.com Thu Jul 23 18:24:54 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 24 Jul 2009 01:24:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6860599: nodes limit could be reached during Output phase Message-ID: <20090724012503.C3D97EF0B@hg.openjdk.java.net> Changeset: ea3f9723b5cf Author: kvn Date: 2009-07-23 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ea3f9723b5cf 6860599: nodes limit could be reached during Output phase Summary: Bailout compilation if nodes limit could be reached during Output phase. Reviewed-by: never, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp From Changpeng.Fang at Sun.COM Fri Jul 24 10:41:13 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Fri, 24 Jul 2009 10:41:13 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A67796B.5050604@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> Message-ID: <4A69F239.3050601@sun.com> http://cr.openjdk.java.net/~cfang/6833129/webrev.05/ I updated the change with the addition of the assert of undefined reexecute state in set_bci(). This assert caught the problem of reexecute state leaking to the exception path. Here I propose to clear the reexecute state when the control goes to the exception path because the parser will stop parsing the current bytecode (it will either parses the catch block or goes to process exit). Thanks, Changpeng On 07/22/09 13:41, Vladimir Kozlov wrote: > I would use REState name instead of REBit. > Also why you did not add the assert we talked about in set_bci()? > Otherwise looks good. > > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ >> >> Please take a final look at the implementation of reexecute bit. >> >> Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : >> >> (1) In C2 JVMState, use a three state field (instead of a boolean) >> to represent the reexecute bit: >> * class JVMState : public ResourceObj {* >> *+ public:* >> *+ typedef enum {* >> *+ RE_Undefined = -1, // not defined -- will be translated into >> false later* >> *+ RE_False = 0, // false -- do not reexecute* >> *+ RE_True = 1 // true -- reexecute the bytecode* >> *+ } REBit; //ReExecution Bit* >> *+ * >> >> In this way, we can keep the original defined reexecute bit (true or >> false) when we are going to determine >> the reexecute bit by bytecode. >> >> *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && >> //don't touch defined values* >> *+ should_reexecute_implied_by_bytecode(out_jvms)) {* >> *+ out_jvms->set_reexecute(JVMState::RE_True);* >> *+ }* >> *+ * >> >> (2) Renamed Intepreter::continuation_for to be Interpreter:: >> deopt_continue_after_entry. >> Renamed Interpreter::bytecodes_to_reexecute to >> Interpreter::bytecode_should_reexecute >> >> >> Thanks, >> >> Changpeng >> >> >> On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara >> United States wrote: >>> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >>> >>> Problem: >>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>> de-optimization occurs on the slow path for array/instance >>> allocation, the Interpreter will continue execution in next bytecode >>> after the slow allocation calls without actual copying. The >>> fundamental problem is that the current vm does not have the logic >>> for the compilers to specify reexecution for the interpreter >>> if deoptimization happens for cases like intrinsics of Object.clone >>> and Arrays.copyOf. >>> >>> Solution: >>> We add such logic in the vm. >>> (1) For C2, we add an "reexecute" field in JVMState to specify >>> whether to reexecute this bytecode. This reexecute bit will be >>> recorded as debug information through **describe_scope. At >>> runtime, the deoptimizer will get the reexecution information >>> at the time of unpack_frame through reading the scope. >>> (2) There are some bytecodes that we have already known that the >>> interpreter should re-execute them when deoptimization >>> happens (e.g. _getfield and _putfield). For C2, we set the >>> reexecute bit for the out JVMS (youngest one) for them at the >>> time of adding safepoint edges. For C1, we simply set the >>> reexecute bit for them at the time of ** **describe_scope. >>> (3) For **Object.clone and Arrays.copyOf., we set the reexecute bit >>> and pop off the argument when we intrinsify them. >>> >>> Tests: >>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>> >>> >>> Since there are several previous email exchanges, I collect the >>> questions from them and give a brief answer here: >>> >>> ============================ >>> >From kvn: >>> ============================ >>> >Also in src/share/vm/opto/callnode.hpp add an assert >>> >to check that bci is no changed when _restart is set >>> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >>> >>> I could not do this assertion here because sync_jvms() will set_bci >>> and we have already set the restart (reexecute) before >>> some sync_jvms calls. Do you think it ok for an assertion like >>> assert(_bci== bci || !_restart, ""); whih means for a new bci the >>> restart >>> should be false? Thanks. >>> >>> =================== >>> From jrose: >>> =================== >>> >Here's a nit: is_restart() in scopeDesc.hpp should be a const >>> function. >>> >I'd like to see comment in each case demonstrating why that the >>> values captured in dummy_restart, and the throwaway restart in >>> javaClasses.cpp (which should be called dummy_restart also) don't >>> matter. >>> Done! I appreciate if you can double check to see whether the >>> comments are appropriate or not. Thanks. >>> >>> >I'd still like to see the restart decision made by continuation_for >>> turned into an assert. At least compare it with is_restart(): >>>> pc = Interpreter::continuation_for(method(), bcp, >>>> callee_parameters, is_top_frame, use_next_mdp); >>>> + assert(is_restart() == !use_next_mdp, ""); >>> >If the assert fails, there may be a bug. >>> Thanks for pointing out this. Now, after the redesign, >>> continuation_for does not make decision whether to reexecute or >>> continue. It is just used to compute the address >>> for the continuation (next bytecode). I add a new function to >>> compute the reexecution address >>> Interpreter::deopt_reexecute_entry(...). What do you think of the new >>> design? Thanks. >>> >>> ========================= >>> >From never: >>> ========================= >>> >I think the term reexecute should be used in place of restart since >>> that terminology is used elsewhere. Actually I think >>> should_reexecute is better than is_reexecute as well. >>> Yes, reexecute better than restart here! Thanks. >>> >>> >I don't really like that the restart bit is associated with the >>> bci. It implies that any scope can be reexecuted when it fact it's >>> only the topmost one that can be. Given how these describing scopes >>> is structured I'm not sure I see a better way though. I >don't see >>> any asserts to enforce this for the scopeDescs either. >>> Done ! Thanks >>> The printing forms for ScopeDesc and JVMState should indicate if >>> this is a restarted bytecode or not. The SA also needs to be >>> updated to read these modified ScopeDescs. >>> Done! Thanks. >>> >>> >I think manually toggling the restart bit back and forth should be >>> avoided. Preserve the original and pass on the modified one or have >>> a helper object that toggles the bit in it's constructor/destructor. >>> I just design a new class "PreserveReexecuteAndSP" to save and >>> restore the reexecute bit and sp. Thanks. >>> >>> >>> Thank you so much for your help and inputs. >>> >>> Changpeng >>> >>> >> From Vladimir.Kozlov at Sun.COM Fri Jul 24 10:56:47 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 24 Jul 2009 10:56:47 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A69F239.3050601@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A69F239.3050601@sun.com> Message-ID: <4A69F5DF.1080206@sun.com> Looks good. Did you verified that jvms in GraphKit::make_exception_state() is different from jvms (with Reexecute_True) of new_instance call in clone intrinsic ? Thanks, Vladimir changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.05/ > > I updated the change with the addition of the assert of undefined > reexecute state > in set_bci(). This assert caught the problem of reexecute state leaking > to the exception > path. Here I propose to clear the reexecute state when the control goes > to the exception > path because the parser will stop parsing the current bytecode (it will > either parses > the catch block or goes to process exit). > > Thanks, > > Changpeng > > > > > On 07/22/09 13:41, Vladimir Kozlov wrote: >> I would use REState name instead of REBit. >> Also why you did not add the assert we talked about in set_bci()? >> Otherwise looks good. >> >> Vladimir >> >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ >>> >>> Please take a final look at the implementation of reexecute bit. >>> >>> Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : >>> >>> (1) In C2 JVMState, use a three state field (instead of a boolean) >>> to represent the reexecute bit: * class JVMState : public >>> ResourceObj {* >>> *+ public:* >>> *+ typedef enum {* >>> *+ RE_Undefined = -1, // not defined -- will be translated into >>> false later* >>> *+ RE_False = 0, // false -- do not reexecute* >>> *+ RE_True = 1 // true -- reexecute the bytecode* >>> *+ } REBit; //ReExecution Bit* >>> *+ * >>> >>> In this way, we can keep the original defined reexecute bit (true or >>> false) when we are going to determine >>> the reexecute bit by bytecode. >>> >>> *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && >>> //don't touch defined values* >>> *+ should_reexecute_implied_by_bytecode(out_jvms)) {* >>> *+ out_jvms->set_reexecute(JVMState::RE_True);* >>> *+ }* >>> *+ * >>> >>> (2) Renamed Intepreter::continuation_for to be Interpreter:: >>> deopt_continue_after_entry. >>> Renamed Interpreter::bytecodes_to_reexecute to >>> Interpreter::bytecode_should_reexecute >>> >>> >>> Thanks, >>> >>> Changpeng >>> >>> >>> On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara >>> United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >>>> >>>> Problem: >>>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>>> de-optimization occurs on the slow path for array/instance >>>> allocation, the Interpreter will continue execution in next bytecode >>>> after the slow allocation calls without actual copying. The >>>> fundamental problem is that the current vm does not have the logic >>>> for the compilers to specify reexecution for the interpreter >>>> if deoptimization happens for cases like intrinsics of Object.clone >>>> and Arrays.copyOf. >>>> >>>> Solution: >>>> We add such logic in the vm. >>>> (1) For C2, we add an "reexecute" field in JVMState to specify >>>> whether to reexecute this bytecode. This reexecute bit will be >>>> recorded as debug information through **describe_scope. At >>>> runtime, the deoptimizer will get the reexecution information >>>> at the time of unpack_frame through reading the scope. >>>> (2) There are some bytecodes that we have already known that the >>>> interpreter should re-execute them when deoptimization >>>> happens (e.g. _getfield and _putfield). For C2, we set the >>>> reexecute bit for the out JVMS (youngest one) for them at the >>>> time of adding safepoint edges. For C1, we simply set the >>>> reexecute bit for them at the time of ** **describe_scope. >>>> (3) For **Object.clone and Arrays.copyOf., we set the reexecute bit >>>> and pop off the argument when we intrinsify them. >>>> >>>> Tests: >>>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>>> >>>> >>>> Since there are several previous email exchanges, I collect the >>>> questions from them and give a brief answer here: >>>> >>>> ============================ >>>> >From kvn: >>>> ============================ >>>> >Also in src/share/vm/opto/callnode.hpp add an assert >>>> >to check that bci is no changed when _restart is set >>>> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >>>> >>>> I could not do this assertion here because sync_jvms() will set_bci >>>> and we have already set the restart (reexecute) before >>>> some sync_jvms calls. Do you think it ok for an assertion like >>>> assert(_bci== bci || !_restart, ""); whih means for a new bci the >>>> restart >>>> should be false? Thanks. >>>> >>>> =================== >>>> From jrose: >>>> =================== >>>> >Here's a nit: is_restart() in scopeDesc.hpp should be a const >>>> function. >>>> >I'd like to see comment in each case demonstrating why that the >>>> values captured in dummy_restart, and the throwaway restart in >>>> javaClasses.cpp (which should be called dummy_restart also) don't >>>> matter. >>>> Done! I appreciate if you can double check to see whether the >>>> comments are appropriate or not. Thanks. >>>> >>>> >I'd still like to see the restart decision made by continuation_for >>>> turned into an assert. At least compare it with is_restart(): >>>>> pc = Interpreter::continuation_for(method(), bcp, >>>>> callee_parameters, is_top_frame, use_next_mdp); >>>>> + assert(is_restart() == !use_next_mdp, ""); >>>> >If the assert fails, there may be a bug. >>>> Thanks for pointing out this. Now, after the redesign, >>>> continuation_for does not make decision whether to reexecute or >>>> continue. It is just used to compute the address >>>> for the continuation (next bytecode). I add a new function to >>>> compute the reexecution address >>>> Interpreter::deopt_reexecute_entry(...). What do you think of the new >>>> design? Thanks. >>>> >>>> ========================= >>>> >From never: >>>> ========================= >>>> >I think the term reexecute should be used in place of restart since >>>> that terminology is used elsewhere. Actually I think >>>> should_reexecute is better than is_reexecute as well. >>>> Yes, reexecute better than restart here! Thanks. >>>> >>>> >I don't really like that the restart bit is associated with the >>>> bci. It implies that any scope can be reexecuted when it fact it's >>>> only the topmost one that can be. Given how these describing scopes >>>> is structured I'm not sure I see a better way though. I >don't see >>>> any asserts to enforce this for the scopeDescs either. >>>> Done ! Thanks >>>> The printing forms for ScopeDesc and JVMState should indicate if >>>> this is a restarted bytecode or not. The SA also needs to be >>>> updated to read these modified ScopeDescs. >>>> Done! Thanks. >>>> >>>> >I think manually toggling the restart bit back and forth should be >>>> avoided. Preserve the original and pass on the modified one or have >>>> a helper object that toggles the bit in it's constructor/destructor. >>>> I just design a new class "PreserveReexecuteAndSP" to save and >>>> restore the reexecute bit and sp. Thanks. >>>> >>>> >>>> Thank you so much for your help and inputs. >>>> >>>> Changpeng >>>> >>>> >>> > From Changpeng.Fang at Sun.COM Fri Jul 24 11:28:27 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Fri, 24 Jul 2009 11:28:27 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A69F5DF.1080206@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A69F239.3050601@sun.com> <4A69F5DF.1080206@sun.com> Message-ID: <4A69FD4B.2080005@sun.com> On 07/24/09 10:56, Vladimir Kozlov wrote: > Looks good. > Did you verified that jvms in GraphKit::make_exception_state() > is different from jvms (with Reexecute_True) of new_instance call > in clone intrinsic ? Yes, they are different. In new_instance call (or other calls), we always use the cloned jvms when we add safepoint edges. The jvms() in GraphKit::make_exception_state is the main jvms, and is going to be saved in the exception map before it is killed. The saved jvms will later be used to handle the exception. Thanks, Changpeng > > Thanks, > Vladimir > > changpeng fang - Sun Microsystems - Santa Clara United States wrote: >> http://cr.openjdk.java.net/~cfang/6833129/webrev.05/ >> >> I updated the change with the addition of the assert of undefined >> reexecute state >> in set_bci(). This assert caught the problem of reexecute state >> leaking to the exception >> path. Here I propose to clear the reexecute state when the control >> goes to the exception >> path because the parser will stop parsing the current bytecode (it >> will either parses >> the catch block or goes to process exit). >> >> Thanks, >> >> Changpeng >> >> >> >> >> On 07/22/09 13:41, Vladimir Kozlov wrote: >>> I would use REState name instead of REBit. >>> Also why you did not add the assert we talked about in set_bci()? >>> Otherwise looks good. >>> >>> Vladimir >>> >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ >>>> >>>> Please take a final look at the implementation of reexecute bit. >>>> >>>> Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : >>>> >>>> (1) In C2 JVMState, use a three state field (instead of a >>>> boolean) to represent the reexecute bit: * class JVMState : >>>> public ResourceObj {* >>>> *+ public:* >>>> *+ typedef enum {* >>>> *+ RE_Undefined = -1, // not defined -- will be translated into >>>> false later* >>>> *+ RE_False = 0, // false -- do not reexecute* >>>> *+ RE_True = 1 // true -- reexecute the bytecode* >>>> *+ } REBit; //ReExecution Bit* >>>> *+ * >>>> >>>> In this way, we can keep the original defined reexecute bit (true >>>> or false) when we are going to determine >>>> the reexecute bit by bytecode. >>>> >>>> *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && >>>> //don't touch defined values* >>>> *+ should_reexecute_implied_by_bytecode(out_jvms)) {* >>>> *+ out_jvms->set_reexecute(JVMState::RE_True);* >>>> *+ }* >>>> *+ * >>>> >>>> (2) Renamed Intepreter::continuation_for to be Interpreter:: >>>> deopt_continue_after_entry. >>>> Renamed Interpreter::bytecodes_to_reexecute to >>>> Interpreter::bytecode_should_reexecute >>>> >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>>> >>>> On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara >>>> United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >>>>> >>>>> Problem: >>>>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>>>> de-optimization occurs on the slow path for array/instance >>>>> allocation, the Interpreter will continue execution in next >>>>> bytecode after the slow allocation calls without actual copying. The >>>>> fundamental problem is that the current vm does not have the logic >>>>> for the compilers to specify reexecution for the interpreter >>>>> if deoptimization happens for cases like intrinsics of >>>>> Object.clone and Arrays.copyOf. >>>>> >>>>> Solution: >>>>> We add such logic in the vm. >>>>> (1) For C2, we add an "reexecute" field in JVMState to specify >>>>> whether to reexecute this bytecode. This reexecute bit will be >>>>> recorded as debug information through **describe_scope. At >>>>> runtime, the deoptimizer will get the reexecution information >>>>> at the time of unpack_frame through reading the scope. >>>>> (2) There are some bytecodes that we have already known that the >>>>> interpreter should re-execute them when deoptimization >>>>> happens (e.g. _getfield and _putfield). For C2, we set the >>>>> reexecute bit for the out JVMS (youngest one) for them at the >>>>> time of adding safepoint edges. For C1, we simply set the >>>>> reexecute bit for them at the time of ** **describe_scope. >>>>> (3) For **Object.clone and Arrays.copyOf., we set the reexecute >>>>> bit and pop off the argument when we intrinsify them. >>>>> >>>>> Tests: >>>>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>>>> >>>>> >>>>> Since there are several previous email exchanges, I collect the >>>>> questions from them and give a brief answer here: >>>>> >>>>> ============================ >>>>> >From kvn: >>>>> ============================ >>>>> >Also in src/share/vm/opto/callnode.hpp add an assert >>>>> >to check that bci is no changed when _restart is set >>>>> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >>>>> >>>>> I could not do this assertion here because sync_jvms() will >>>>> set_bci and we have already set the restart (reexecute) before >>>>> some sync_jvms calls. Do you think it ok for an assertion like >>>>> assert(_bci== bci || !_restart, ""); whih means for a new bci the >>>>> restart >>>>> should be false? Thanks. >>>>> >>>>> =================== >>>>> From jrose: >>>>> =================== >>>>> >Here's a nit: is_restart() in scopeDesc.hpp should be a const >>>>> function. >>>>> >I'd like to see comment in each case demonstrating why that the >>>>> values captured in dummy_restart, and the throwaway restart in >>>>> javaClasses.cpp (which should be called dummy_restart also) don't >>>>> matter. >>>>> Done! I appreciate if you can double check to see whether the >>>>> comments are appropriate or not. Thanks. >>>>> >>>>> >I'd still like to see the restart decision made by >>>>> continuation_for turned into an assert. At least compare it with >>>>> is_restart(): >>>>>> pc = Interpreter::continuation_for(method(), bcp, >>>>>> callee_parameters, is_top_frame, use_next_mdp); >>>>>> + assert(is_restart() == !use_next_mdp, ""); >>>>> >If the assert fails, there may be a bug. >>>>> Thanks for pointing out this. Now, after the redesign, >>>>> continuation_for does not make decision whether to reexecute or >>>>> continue. It is just used to compute the address >>>>> for the continuation (next bytecode). I add a new function to >>>>> compute the reexecution address >>>>> Interpreter::deopt_reexecute_entry(...). What do you think of the new >>>>> design? Thanks. >>>>> >>>>> ========================= >>>>> >From never: >>>>> ========================= >>>>> >I think the term reexecute should be used in place of restart >>>>> since that terminology is used elsewhere. Actually I think >>>>> should_reexecute is better than is_reexecute as well. >>>>> Yes, reexecute better than restart here! Thanks. >>>>> >>>>> >I don't really like that the restart bit is associated with the >>>>> bci. It implies that any scope can be reexecuted when it fact >>>>> it's only the topmost one that can be. Given how these describing >>>>> scopes is structured I'm not sure I see a better way though. I >>>>> >don't see any asserts to enforce this for the scopeDescs either. >>>>> Done ! Thanks >>>>> The printing forms for ScopeDesc and JVMState should indicate if >>>>> this is a restarted bytecode or not. The SA also needs to be >>>>> updated to read these modified ScopeDescs. >>>>> Done! Thanks. >>>>> >>>>> >I think manually toggling the restart bit back and forth should >>>>> be avoided. Preserve the original and pass on the modified one or >>>>> have a helper object that toggles the bit in it's >>>>> constructor/destructor. >>>>> I just design a new class "PreserveReexecuteAndSP" to save and >>>>> restore the reexecute bit and sp. Thanks. >>>>> >>>>> >>>>> Thank you so much for your help and inputs. >>>>> >>>>> Changpeng >>>>> >>>>> >>>> >> From vladimir.kozlov at sun.com Fri Jul 24 12:31:55 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 24 Jul 2009 19:31:55 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 11 new changesets Message-ID: <20090724193232.91507E568@hg.openjdk.java.net> Changeset: 0316eac49d5a Author: tonyp Date: 2009-07-07 14:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0316eac49d5a 6855834: G1: minimize the output when -XX:+PrintHeapAtGC is set Summary: Changing the behavior of -XX:+PrintHeapAtGC for G1 from printing lengthy, per-region information to instead printing a concise summary. Reviewed-by: ysr, apetrusenko, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/globals.hpp Changeset: bb18957ad21e Author: ysr Date: 2009-07-10 16:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bb18957ad21e Merge Changeset: ba36394eb84b Author: xdono Date: 2009-07-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ba36394eb84b Added tag jdk7-b63 for changeset 32c83fb84370 ! .hgtags Changeset: 45c4b1fe45e4 Author: trims Date: 2009-07-10 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/45c4b1fe45e4 6859411: Bump the HS16 build number to 06 Summary: Update the HS16 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 218f6b67f9c5 Author: trims Date: 2009-07-11 03:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/218f6b67f9c5 Merge Changeset: 92b5fbbe8477 Author: xdono Date: 2009-07-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/92b5fbbe8477 Added tag jdk7-b64 for changeset ba36394eb84b ! .hgtags Changeset: ba313800759b Author: trims Date: 2009-07-14 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ba313800759b Merge Changeset: df6caf649ff7 Author: ysr Date: 2009-07-14 15:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/df6caf649ff7 6700789: G1: Enable use of compressed oops with G1 heaps Summary: Modifications to G1 so as to allow the use of compressed oops. Reviewed-by: apetrusenko, coleenp, jmasa, kvn, never, phh, tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 42d84bbbecf4 Author: tonyp Date: 2009-07-15 12:22 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/42d84bbbecf4 6859911: G1: assert(Heap_lock->owner() = NULL, "Should be owned on this thread's behalf") Summary: The used() method assumes that the heap lock is held when it is called. However, when used() is called from print_on(), this is not the case. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: f0a1cbbaf3c0 Author: ysr Date: 2009-07-16 12:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f0a1cbbaf3c0 Merge Changeset: 433f394ab509 Author: kvn Date: 2009-07-24 09:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/433f394ab509 Merge ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/cfgnode.cpp From Vladimir.Kozlov at Sun.COM Fri Jul 24 15:43:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 24 Jul 2009 15:43:07 -0700 Subject: Request for reviews (XS): 6851386: assert(b->find_node(def) < j,"uses must follow definitions") Message-ID: <4A6A38FB.4090808@sun.com> http://cr.openjdk.java.net/~kvn/6851386/webrev.00 Fixed 6851386: assert(b->find_node(def) < j,"uses must follow definitions") Problem: The assert added for 6791852 misses the case when the head of a tight loop is not LoopNode. In the bugs case it is RegionNode with 4 input edges. Solution: Add additional check for a tight loop. Reviewed by: Fix verified (y/n): y, bug's test Other testing: JPRT From Thomas.Rodriguez at Sun.COM Fri Jul 24 15:58:53 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 24 Jul 2009 15:58:53 -0700 Subject: Request for reviews (XS): 6851386: assert(b->find_node(def) < j,"uses must follow definitions") In-Reply-To: <4A6A38FB.4090808@sun.com> References: <4A6A38FB.4090808@sun.com> Message-ID: Shouldn't the search start at 1 instead of 0? Otherwise it looks fine. tom On Jul 24, 2009, at 3:43 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6851386/webrev.00 > > Fixed 6851386: assert(b->find_node(def) < j,"uses must follow > definitions") > > Problem: > The assert added for 6791852 misses the case when > the head of a tight loop is not LoopNode. > In the bugs case it is RegionNode with 4 input edges. > > Solution: > Add additional check for a tight loop. > > Reviewed by: > > Fix verified (y/n): y, bug's test > > Other testing: > JPRT > From Vladimir.Kozlov at Sun.COM Fri Jul 24 16:04:42 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 24 Jul 2009 16:04:42 -0700 Subject: Request for reviews (XS): 6851386: assert(b->find_node(def) < j,"uses must follow definitions") In-Reply-To: References: <4A6A38FB.4090808@sun.com> Message-ID: <4A6A3E0A.9080504@sun.com> Thanks, Tom Yes, you are right. I will change it to 1. Vladimir Tom Rodriguez wrote: > Shouldn't the search start at 1 instead of 0? Otherwise it looks fine. > > tom > > On Jul 24, 2009, at 3:43 PM, Vladimir Kozlov wrote: > >> >> http://cr.openjdk.java.net/~kvn/6851386/webrev.00 >> >> Fixed 6851386: assert(b->find_node(def) < j,"uses must follow >> definitions") >> >> Problem: >> The assert added for 6791852 misses the case when >> the head of a tight loop is not LoopNode. >> In the bugs case it is RegionNode with 4 input edges. >> >> Solution: >> Add additional check for a tight loop. >> >> Reviewed by: >> >> Fix verified (y/n): y, bug's test >> >> Other testing: >> JPRT >> > From thomas.rodriguez at sun.com Fri Jul 24 16:20:34 2009 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 24 Jul 2009 23:20:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6861984: solaris version of libsaproc.so should support SA_ALTROOT directly Message-ID: <20090724232045.16CF8E590@hg.openjdk.java.net> Changeset: a94af87c3357 Author: never Date: 2009-07-24 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a94af87c3357 6861984: solaris version of libsaproc.so should support SA_ALTROOT directly Reviewed-by: kvn, twisti ! agent/make/saenv.sh ! agent/make/saenv64.sh ! agent/src/os/solaris/proc/Makefile ! agent/src/os/solaris/proc/mapfile ! agent/src/os/solaris/proc/saproc.cpp + agent/src/os/solaris/proc/saproc_audit.cpp From john.coomes at sun.com Sat Jul 25 04:22:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 25 Jul 2009 11:22:31 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b66 for changeset 6bad5e3fe503 Message-ID: <20090725112231.4CE49E6BC@hg.openjdk.java.net> Changeset: 5dc862ec024e Author: xdono Date: 2009-07-24 13:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/5dc862ec024e Added tag jdk7-b66 for changeset 6bad5e3fe503 ! .hgtags From john.coomes at sun.com Sat Jul 25 04:28:00 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 25 Jul 2009 11:28:00 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b66 for changeset a821e059a961 Message-ID: <20090725112801.D6997E6C1@hg.openjdk.java.net> Changeset: d5e36cb83d8c Author: xdono Date: 2009-07-24 13:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/d5e36cb83d8c Added tag jdk7-b66 for changeset a821e059a961 ! .hgtags From john.coomes at sun.com Sat Jul 25 04:38:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 25 Jul 2009 11:38:21 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b66 for changeset 22f9d5d5b5fe Message-ID: <20090725113824.154F4E6C6@hg.openjdk.java.net> Changeset: f8f9c0186d87 Author: xdono Date: 2009-07-24 13:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/f8f9c0186d87 Added tag jdk7-b66 for changeset 22f9d5d5b5fe ! .hgtags From john.coomes at sun.com Sat Jul 25 04:43:35 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 25 Jul 2009 11:43:35 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b66 for changeset fa8712c099ed Message-ID: <20090725114338.22E95E6CB@hg.openjdk.java.net> Changeset: 58f51e3cc0fa Author: xdono Date: 2009-07-24 13:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/58f51e3cc0fa Added tag jdk7-b66 for changeset fa8712c099ed ! .hgtags From john.coomes at sun.com Sat Jul 25 04:50:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 25 Jul 2009 11:50:42 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 36 new changesets Message-ID: <20090725115826.81BE4E6D2@hg.openjdk.java.net> Changeset: b22f9e823be7 Author: alanb Date: 2009-06-30 11:11 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b22f9e823be7 6843003: Windows Server 2008 R2 system recognition Reviewed-by: ohair, sherman ! src/windows/native/java/lang/java_props_md.c Changeset: d57c10cf07c5 Author: alanb Date: 2009-06-30 11:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d57c10cf07c5 Merge Changeset: c2baa2f0415e Author: xuelei Date: 2009-07-03 11:13 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c2baa2f0415e 6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check Summary: allocate memory dynamically, keep reading until EOF. Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/timestamp/HttpTimestamper.java Changeset: 803db6c94a3b Author: martin Date: 2009-07-03 07:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/803db6c94a3b 6857287: (file) Clarifications for symbolic link related javadoc Summary: Fix up jsr203 file javadoc related to symbolic links Reviewed-by: alanb ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/NotLinkException.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/attribute/Attributes.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java Changeset: 75459b125461 Author: tbell Date: 2009-07-03 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/75459b125461 Merge Changeset: fa488e4ff685 Author: jccollet Date: 2009-07-06 15:13 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fa488e4ff685 6856856: NPE in HTTP protocol handler logging Summary: Fixed the NPE and Moved the java.util.logging dependency to a single class and used reflection to make it a soft one. Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpCapture.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 0cabe1192c8b Author: martin Date: 2009-07-06 11:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0cabe1192c8b 6854795: Miscellaneous improvements to "jar" Summary: cleanup of jar/Main.java (Initial patch by tobyr at google.com, additional review by jeremymanson at google.com, ulf.zibis at gmx.de) Reviewed-by: sherman, alanb ! src/share/classes/sun/tools/jar/Main.java ! test/tools/jar/index/MetaInf.java Changeset: 0a294c066e7a Author: darcy Date: 2009-07-07 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0a294c066e7a 6857803: Missing links to exceptions in javadoc for Class.getGeneric{Superclass, Interfaces} Reviewed-by: chegar ! src/share/classes/java/lang/Class.java Changeset: 1175f872a968 Author: weijun Date: 2009-07-08 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1175f872a968 6857802: GSS getRemainingInitLifetime method returns milliseconds not seconds Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java + test/sun/security/krb5/auto/LifeTimeInSeconds.java Changeset: 1df67a3ecce8 Author: weijun Date: 2009-07-08 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1df67a3ecce8 6857795: krb5.conf ignored if system properties on realm and kdc are provided Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java + test/sun/security/krb5/ConfPlusProp.java + test/sun/security/krb5/confplusprop.conf + test/sun/security/krb5/confplusprop2.conf Changeset: d133d4052378 Author: ohair Date: 2009-07-08 09:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d133d4052378 6858127: Missing -DNDEBUG on Linux and Windows native code compiles Reviewed-by: tbell, dcubed ! make/common/Defs-linux.gmk ! make/common/Defs-windows.gmk Changeset: d3a08f8c3c86 Author: ohair Date: 2009-07-08 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d3a08f8c3c86 6855551: java -Xrunhprof crashes when running with classes compiled with targed=7 Reviewed-by: tbell, dcubed ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! test/demo/jvmti/hprof/HelloWorld.java ! test/demo/jvmti/hprof/StackMapTableTest.java Changeset: ae60bb671e54 Author: darcy Date: 2009-07-09 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ae60bb671e54 6628737: Specification of wrapper class valueOf static factories should require caching Reviewed-by: mr ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java Changeset: 6f26e2e5f4f3 Author: xuelei Date: 2009-07-10 17:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6f26e2e5f4f3 6852744: PIT b61: PKI test suite fails because self signed certificates are beingrejected Summary: make the builder aware of SKID/AKID, break the internal circular dependences Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + test/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java + test/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java + test/java/security/cert/CertPathBuilder/selfIssued/README + test/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java + test/java/security/cert/CertPathBuilder/selfIssued/generate.sh + test/java/security/cert/CertPathBuilder/selfIssued/openssl.cnf Changeset: 880896883a47 Author: andrew Date: 2009-07-11 16:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/880896883a47 6562614: Compiler warnings for gettimeofday in Inet4/Inet6AddressImpl.c Summary: Add missing header to remove compiler warnings. Reviewed-by: martin Contributed-by: Matthew Flaschen ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: d0ce095004b2 Author: xuelei Date: 2009-07-13 23:01 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d0ce095004b2 6453837: PartialCompositeContext.allEmpty is buggy Reviewed-by: weijun ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java Changeset: beb5e5cad3ae Author: valeriep Date: 2009-07-13 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/beb5e5cad3ae 6832540: IllegalArgumentException in ClassLoader.definePackage when classes are loaded in parallel Summary: Modified to handle race condition for parallel-capable classloaders by re-trying/re-verifying package Reviewed-by: alanb ! src/share/classes/java/net/URLClassLoader.java Changeset: 53b27ac4f706 Author: tbell Date: 2009-07-13 23:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/53b27ac4f706 Merge ! make/common/Defs-windows.gmk Changeset: 51ccb32e6d14 Author: tbell Date: 2009-07-16 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/51ccb32e6d14 Merge Changeset: 043c7100a752 Author: anthony Date: 2009-07-07 17:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/043c7100a752 6853916: java.awt.Window.setBackground(null) throws NullPointerException Summary: Window.setBackground() should check for null. Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Window.java + test/java/awt/Window/SetBackgroundNPE/SetBackgroundNPE.java Changeset: 99cdc0268e4b Author: dcherepanov Date: 2009-07-09 15:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/99cdc0268e4b 6855323: Robot(GraphicsDevice) constructor initializes LEGAL_BUTTON_MASK variable improperly Reviewed-by: art ! src/share/classes/java/awt/Robot.java + test/java/awt/Robot/CtorTest/CtorTest.java Changeset: 9b1e640af25e Author: dcherepanov Date: 2009-07-09 15:18 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9b1e640af25e 6759726: TrayIcon constructor throws NPE instead of documented IAE Reviewed-by: art ! src/share/classes/java/awt/TrayIcon.java + test/java/awt/TrayIcon/CtorTest/CtorTest.java Changeset: df34ec9f3e26 Author: dcherepanov Date: 2009-07-09 15:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/df34ec9f3e26 6847958: MouseWheel event is getting triggered for the disabled Textarea in jdk7 b60 pit build. Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XBaseWindow.java + test/java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java Changeset: c27d7c1d1918 Author: dcherepanov Date: 2009-07-09 15:53 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c27d7c1d1918 6847149: test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java fails Reviewed-by: art ! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 6d92ce5fe15b Author: yan Date: 2009-07-12 23:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/6d92ce5fe15b Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: 4cd623432e7d Author: anthony Date: 2009-07-14 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/4cd623432e7d 6837446: Introduce Window.isOpaque() method Reviewed-by: art, alexp ! src/share/classes/com/sun/awt/AWTUtilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: fc869bc0cd63 Author: yan Date: 2009-07-14 22:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/fc869bc0cd63 Merge Changeset: bccc4d5e8d6a Author: malenkov Date: 2009-07-02 19:48 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bccc4d5e8d6a 6380849: RFE: Automatic discovery of PersistanceDelegates Reviewed-by: rupashka, alexp + src/share/classes/com/sun/beans/finder/BeanInfoFinder.java + src/share/classes/com/sun/beans/finder/InstanceFinder.java + src/share/classes/com/sun/beans/finder/PersistenceDelegateFinder.java + src/share/classes/com/sun/beans/finder/PropertyEditorFinder.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + test/java/beans/Introspector/6380849/TestBeanInfo.java + test/java/beans/Introspector/6380849/beans/FirstBean.java + test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java + test/java/beans/Introspector/6380849/beans/SecondBean.java + test/java/beans/Introspector/6380849/beans/ThirdBean.java + test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java + test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java + test/java/beans/PropertyEditor/6380849/FirstBean.java + test/java/beans/PropertyEditor/6380849/FirstBeanEditor.java + test/java/beans/PropertyEditor/6380849/SecondBean.java + test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java + test/java/beans/PropertyEditor/6380849/ThirdBean.java + test/java/beans/PropertyEditor/6380849/editors/SecondBeanEditor.java + test/java/beans/PropertyEditor/6380849/editors/ThirdBeanEditor.java + test/java/beans/XMLEncoder/6380849/Bean.java + test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java + test/java/beans/XMLEncoder/6380849/TestPersistenceDelegate.java Changeset: 7720d6c079ca Author: malenkov Date: 2009-07-03 16:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/7720d6c079ca 6329581: RFE: LTP: java.beans.XMLEncoder does not manage ClassLoader. Reviewed-by: rupashka, alexp ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/Statement.java + test/java/beans/XMLEncoder/6329581/Test6329581.java Changeset: ef20a15b3569 Author: malenkov Date: 2009-07-06 14:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ef20a15b3569 6723447: Introspector doesn't check return type for indexed property setters Reviewed-by: rupashka ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test6723447.java Changeset: 0407df5a768e Author: rupashka Date: 2009-07-07 14:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0407df5a768e 6489447: Apply the more robust fix for 6449933 to dolphin and 6ux Reviewed-by: malenkov ! src/windows/native/sun/windows/ShellFolder2.cpp Changeset: 913ad033bb37 Author: yan Date: 2009-07-12 06:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/913ad033bb37 Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: c8da3750c7ca Author: yan Date: 2009-07-14 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c8da3750c7ca Merge Changeset: f88379effbcf Author: yan Date: 2009-07-21 23:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f88379effbcf Merge Changeset: bd31b30a5b21 Author: dcherepanov Date: 2009-07-23 11:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/bd31b30a5b21 6857870: Regression tests are failing with ExceptionInInitializerError Reviewed-by: art ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 11a8f0936228 Author: xdono Date: 2009-07-24 13:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/11a8f0936228 Added tag jdk7-b66 for changeset bd31b30a5b21 ! .hgtags From john.coomes at sun.com Sat Jul 25 05:09:43 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Sat, 25 Jul 2009 12:09:43 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b66 for changeset 634f519d6f9a Message-ID: <20090725120946.C04ACE6DD@hg.openjdk.java.net> Changeset: 0695e8ebae88 Author: xdono Date: 2009-07-24 13:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0695e8ebae88 Added tag jdk7-b66 for changeset 634f519d6f9a ! .hgtags From vladimir.kozlov at sun.com Sun Jul 26 15:42:47 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Sun, 26 Jul 2009 22:42:47 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6851386: assert(b->find_node(def) < j, "uses must follow definitions") Message-ID: <20090726224254.8D840E780@hg.openjdk.java.net> Changeset: dd0a4e1e219b Author: kvn Date: 2009-07-26 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dd0a4e1e219b 6851386: assert(b->find_node(def) < j,"uses must follow definitions") Summary: Add additional check for a tight loop. Reviewed-by: never ! src/share/vm/opto/block.cpp From vladimir.kozlov at sun.com Sun Jul 26 21:48:20 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Mon, 27 Jul 2009 04:48:20 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6863420: os::javaTimeNanos() go backward on Solaris x86 Message-ID: <20090727044830.3A2CEE818@hg.openjdk.java.net> Changeset: 665be97e8704 Author: kvn Date: 2009-07-26 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/665be97e8704 6863420: os::javaTimeNanos() go backward on Solaris x86 Summary: Use new atomic long load method Atomic::load() to load max_hrtime. Reviewed-by: never, ysr, johnc, phh, dcubed, acorn ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/share/vm/runtime/atomic.hpp + test/compiler/6863420/Test.java From Christian.Thalinger at Sun.COM Mon Jul 27 02:26:28 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 27 Jul 2009 11:26:28 +0200 Subject: Request for reviews (XS): 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) Message-ID: <4A6D72C4.9060401@Sun.COM> http://cr.openjdk.java.net/~twisti/6863155/webrev.01/ From Christian.Thalinger at Sun.COM Mon Jul 27 04:10:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 27 Jul 2009 13:10:53 +0200 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> Message-ID: <4A6D8B3D.6060704@Sun.COM> John Rose wrote: > In order to inline method handles at invokedynamic instructions, it is > necessary to manipulate MethodHandle and CallSite constants from > generated code. Since these objects are created by ordinary user code > and subject to usual GC, they are not preallocated in the perm gen. > > Currently compiled code requires that any oop embedded as an > instruction constant or any other nmethod part must be > OopDesc::is_perm. For example, internal method objects and classes > and interned strings are permanent so that they can be manipulated > from compiled code. > > This restriction is a bug for JSR 292. Luckily, there is a simple fix. > > http://cr.openjdk.java.net/~jrose/6862576/webrev.00/ > It seems there is a problem with returns: +bool nmethod::detect_non_perm_oops() { + DetectNonPerm detect_non_perm; + if (PrintRelocations) NOT_PRODUCT(detect_non_perm._print_nm = this); + oops_do(&detect_non_perm); + return detect_non_perm.detected_non_perm(); + return false; + return true; +} Shouldn't the compiler complain about that? -- Christian From Christian.Thalinger at Sun.COM Mon Jul 27 05:12:18 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 27 Jul 2009 14:12:18 +0200 Subject: for review (L): 6858164: invokedynamic code needs some cleanup (post-6655638) In-Reply-To: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> Message-ID: <4A6D99A2.60104@Sun.COM> John Rose wrote: > http://cr.openjdk.java.net/~jrose/6858164/vm-webrev.01/ Looks good, but I think that one does not compile with newer GCCs: + printf("MH %s mh="PTR_FORMAT" sp=("PTR_FORMAT"+"INTX_FORMAT") stack_size="INTX_FORMAT" bp="PTR_FORMAT"\n", + adaptername, mh, entry_sp, (saved_sp - entry_sp), (base_sp - last_sp), saved_bp); -- Christian From Changpeng.Fang at Sun.COM Mon Jul 27 09:16:51 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Mon, 27 Jul 2009 09:16:51 -0700 Subject: Request for reviews (XS): 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) In-Reply-To: <4A6D72C4.9060401@Sun.COM> References: <4A6D72C4.9060401@Sun.COM> Message-ID: <4A6DD2F3.2040103@sun.com> On 07/27/09 02:26, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6863155/webrev.01/ > Looks good! Changpeng From Thomas.Rodriguez at Sun.COM Mon Jul 27 11:33:51 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 27 Jul 2009 11:33:51 -0700 Subject: Request for reviews (XS): 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) In-Reply-To: <4A6D72C4.9060401@Sun.COM> References: <4A6D72C4.9060401@Sun.COM> Message-ID: <43C8F883-C376-4B66-B779-5EAB1EE066F5@sun.com> Don't you just want to replace the existing mask with 0xffffffff80000000 to test for this? Testing separately is unneeded. tom On Jul 27, 2009, at 2:26 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6863155/webrev.01/ From Christian.Thalinger at Sun.COM Mon Jul 27 12:07:34 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 27 Jul 2009 19:07:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20090727190744.7358FE91A@hg.openjdk.java.net> Changeset: 94b6d06fd759 Author: twisti Date: 2009-07-20 08:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/94b6d06fd759 6860920: serialize.cpp shouldn't use objArrayOopDesc::base_offset_in_bytes(T_BYTE) Summary: serialize.cpp currently uses objArrayOopDesc::base_offset_in_bytes(T_BYTE), which seems to be wrong. Reviewed-by: coleenp, kvn ! src/share/vm/memory/serialize.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/library_call.cpp Changeset: 1cef5ec3ca56 Author: twisti Date: 2009-07-27 06:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1cef5ec3ca56 Merge ! src/share/vm/opto/library_call.cpp From Christian.Thalinger at Sun.COM Mon Jul 27 12:10:00 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 27 Jul 2009 21:10:00 +0200 Subject: Request for reviews (XS): 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) In-Reply-To: <43C8F883-C376-4B66-B779-5EAB1EE066F5@sun.com> References: <4A6D72C4.9060401@Sun.COM> <43C8F883-C376-4B66-B779-5EAB1EE066F5@sun.com> Message-ID: <4A6DFB88.8040406@Sun.COM> Tom Rodriguez wrote: > Don't you just want to replace the existing mask with > 0xffffffff80000000 to test for this? Testing separately is unneeded. Yeah, Vladimir also asked me that question. I wanted to do that, but I thought it's easier to understand when kept separated. But I think I change it and write a good comment. -- Christian From Christian.Thalinger at Sun.COM Mon Jul 27 13:10:05 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 27 Jul 2009 22:10:05 +0200 Subject: Request for reviews .02 (XS): 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) In-Reply-To: <4A6DFB88.8040406@Sun.COM> References: <4A6D72C4.9060401@Sun.COM> <43C8F883-C376-4B66-B779-5EAB1EE066F5@sun.com> <4A6DFB88.8040406@Sun.COM> Message-ID: <4A6E099D.70606@Sun.COM> Christian Thalinger wrote: > Tom Rodriguez wrote: >> Don't you just want to replace the existing mask with >> 0xffffffff80000000 to test for this? Testing separately is unneeded. > > Yeah, Vladimir also asked me that question. I wanted to do that, but I > thought it's easier to understand when kept separated. But I think I > change it and write a good comment. Here is the updated webrev: http://cr.openjdk.java.net/~twisti/6863155/webrev.02/ -- Christian From Thomas.Rodriguez at Sun.COM Tue Jul 28 09:11:58 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 28 Jul 2009 09:11:58 -0700 Subject: Request for reviews .02 (XS): 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) In-Reply-To: <4A6E099D.70606@Sun.COM> References: <4A6D72C4.9060401@Sun.COM> <43C8F883-C376-4B66-B779-5EAB1EE066F5@sun.com> <4A6DFB88.8040406@Sun.COM> <4A6E099D.70606@Sun.COM> Message-ID: <8D5B9E5E-23F2-4E25-8ADD-BB6D7A2736B9@Sun.COM> Looks good. tom On Jul 27, 2009, at 1:10 PM, Christian Thalinger wrote: > Christian Thalinger wrote: >> Tom Rodriguez wrote: >>> Don't you just want to replace the existing mask with >>> 0xffffffff80000000 to test for this? Testing separately is >>> unneeded. >> >> Yeah, Vladimir also asked me that question. I wanted to do that, >> but I >> thought it's easier to understand when kept separated. But I think I >> change it and write a good comment. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~twisti/6863155/webrev.02/ > > -- Christian From John.Rose at Sun.COM Tue Jul 28 19:08:07 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 28 Jul 2009 19:08:07 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4A6D8B3D.6060704@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <4A6D8B3D.6060704@Sun.COM> Message-ID: On Jul 27, 2009, at 4:10 AM, Christian Thalinger wrote: > It seems there is a problem with returns: Right; it was an incomplete code change. Thanks. -- John From John.Rose at Sun.COM Tue Jul 28 19:26:19 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 28 Jul 2009 19:26:19 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <4A6D8B3D.6060704@Sun.COM> Message-ID: I have updated the webrev slightly, and fixed the URL: http://cr.openjdk.java.net/~jrose/6863023/webrev.01/ Someone observed that the pruning logic might not be exercised, since non-perms do not become perm. But it does get exercised when nmethods are deallocated. (And that caused a bug I had to fix...) -- John On Jul 28, 2009, at 7:08 PM, John Rose wrote: > On Jul 27, 2009, at 4:10 AM, Christian Thalinger wrote: > >> It seems there is a problem with returns: > > Right; it was an incomplete code change. Thanks. -- John From John.Rose at Sun.COM Wed Jul 29 01:50:05 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 29 Jul 2009 01:50:05 -0700 Subject: for review (L): 6858164: invokedynamic cleanups (part B) In-Reply-To: <4A6D99A2.60104@Sun.COM> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> <4A6D99A2.60104@Sun.COM> Message-ID: As I mentioned in the previous review request, JSR 292 code for the JavaOne Preview needs two batches of fixes. Here is the second batch, for invokedynamic (on top of method handles). The diffs of this review request are new, although I erroneously mentioned its bug number in a previous review request. http://cr.openjdk.java.net/~jrose/6858164/webrev.02/ 6858164: invokedynamic code needs some cleanup (post-6655638) 467 lines changed: 100 ins; 287 del; 80 mod; 42741 unchg Summary: - fix several crashers - remove needless paths for boxed-style bootstrap method call - refactor & simplify APIs for rewriter constantPoolOop - remove sun.dyn.CallSiteImpl Testing: These changes have been in use by several users of the mlvm patch repo., as a base for further development. They correctly run all current invokedynamic test code. Still to follow: - compiler support for invokedynamic - inlining of method handles - API adjustments that affect the JVM (mainly, removing private supertypes) - ports to x64, SPARC - compressed oop support From John.Rose at Sun.COM Wed Jul 29 02:35:11 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 29 Jul 2009 02:35:11 -0700 Subject: for review (L): 6815692: method handle cleanups (part A) In-Reply-To: <4A6D99A2.60104@Sun.COM> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> <4A6D99A2.60104@Sun.COM> Message-ID: <32C3BCAA-2F03-47AF-98E6-F48F653DBB86@Sun.COM> The JSR 292 code for the JavaOne Preview needs a number of low-level fixes and tweaks. They are organized in two batches. Here is the first batch, for method handles (not invokedynamic). My previous review request sent out essentially the same webrev, but erroneously tied to the sister bug 6858164 for invokedynamic. http://cr.openjdk.java.net/~jrose/6815692/webrev.01/ 6815692: method handle code needs some cleanup (post-6655638) 285 lines changed: 166 ins; 12 del; 107 mod; 13569 unchg Summary: These are fixes for method handles proper. - correctly raise exceptions - support safe bitwise "raw" conversions (e.g., int -> void) - fix bugs (various, small) revealed by VerifyMethodHandles - remove dead code - improve debugging support Still to follow: - more bug fixes to the invokedynamic instruction - compiler support for invokedynamic - inlining of method handles - API adjustments that affect the JVM (mainly, removing private supertypes) - ports to x64, SPARC - compressed oop support From John.Rose at Sun.COM Wed Jul 29 01:51:05 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 29 Jul 2009 01:51:05 -0700 Subject: for review (L): 6815692: method handle cleanups (part A) In-Reply-To: <4A6D99A2.60104@Sun.COM> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> <4A6D99A2.60104@Sun.COM> Message-ID: The JSR 292 code for the JavaOne Preview needs a number of low-level fixes and tweaks. They are organized in two batches. Here is the first batch, for method handles (not invokedynamic). My previous review request sent out essentially the same webrev, but erroneously tied to the sister bug 6858164 for invokedynamic. http://cr.openjdk.java.net/~jrose/6815692/webrev.01/ 6815692: method handle code needs some cleanup (post-6655638) 285 lines changed: 166 ins; 12 del; 107 mod; 13569 unchg Summary: These are fixes for method handles proper. - correctly raise exceptions - support safe bitwise "raw" conversions (e.g., int -> void) - fix bugs (various, small) revealed by VerifyMethodHandles - remove dead code - improve debugging support Testing: These changes have been in use by several users of the mlvm patch repo., as a base for further development. They pass thorough JSR 292 unit tests. Still to follow: - more bug fixes to the invokedynamic instruction (see next message) - compiler support for invokedynamic - inlining of method handles - API adjustments that affect the JVM (mainly, removing private supertypes) - ports to x64, SPARC - compressed oop support From Christian.Thalinger at Sun.COM Wed Jul 29 07:15:41 2009 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 29 Jul 2009 14:15:41 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) Message-ID: <20090729141551.DA343EB77@hg.openjdk.java.net> Changeset: 52898b0c43e9 Author: twisti Date: 2009-07-28 09:02 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/52898b0c43e9 6863155: Server compiler generates incorrect code (x86, long, bitshift, bitmask) Summary: Code compiled with server compiler generates an incorrect result. Reviewed-by: cfang, never, kvn ! src/share/vm/opto/mulnode.cpp + test/compiler/6863155/Test6863155.java From Changpeng.Fang at Sun.COM Wed Jul 29 19:04:54 2009 From: Changpeng.Fang at Sun.COM (Changpeng Fang) Date: Wed, 29 Jul 2009 19:04:54 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A69F239.3050601@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A69F239.3050601@sun.com> Message-ID: <4A70FFC6.6000207@sun.com> http://cr.openjdk.java.net/~cfang/6833129/webrev.06/ Hopefully this is the last version of update! It seems we clear the reexecute bit too earlier on the execution path in the last update (webrev.05). My original intention is not to let the reexecute state for the current bytecode to leak into the exception block. But I do this in the wrong place (**GraphKit::make_exception_state**). Later in the parser, when we "do_exception", we still need the current bci and associated reexecute bit before handling the catch block. webrev.06 does the reexecute bit clean up in two places: (1) Block::set_start_map() -- reexecute bit should always be initialized or reset the undefined at the block start For the case of exception, we will prevent the reexecute bit of the current map leaking into the catch block. (2) The place after make_runtime_call of rethrow in Parse::catch_inline_exceptions where we are sure that the reexecute bit is no longer needed. Thanks, Changpeng On 07/24/09 10:41, changpeng fang - Sun Microsystems - Santa Clara United States wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.05/ > > I updated the change with the addition of the assert of undefined > reexecute state > in set_bci(). This assert caught the problem of reexecute state > leaking to the exception > path. Here I propose to clear the reexecute state when the control > goes to the exception > path because the parser will stop parsing the current bytecode (it > will either parses > the catch block or goes to process exit). > > Thanks, > > Changpeng > > > > > On 07/22/09 13:41, Vladimir Kozlov wrote: >> I would use REState name instead of REBit. >> Also why you did not add the assert we talked about in set_bci()? >> Otherwise looks good. >> >> Vladimir >> >> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ >>> >>> Please take a final look at the implementation of reexecute bit. >>> >>> Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : >>> >>> (1) In C2 JVMState, use a three state field (instead of a boolean) >>> to represent the reexecute bit: * class JVMState : public >>> ResourceObj {* >>> *+ public:* >>> *+ typedef enum {* >>> *+ RE_Undefined = -1, // not defined -- will be translated into >>> false later* >>> *+ RE_False = 0, // false -- do not reexecute* >>> *+ RE_True = 1 // true -- reexecute the bytecode* >>> *+ } REBit; //ReExecution Bit* >>> *+ * >>> >>> In this way, we can keep the original defined reexecute bit (true >>> or false) when we are going to determine >>> the reexecute bit by bytecode. >>> >>> *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && >>> //don't touch defined values* >>> *+ should_reexecute_implied_by_bytecode(out_jvms)) {* >>> *+ out_jvms->set_reexecute(JVMState::RE_True);* >>> *+ }* >>> *+ * >>> >>> (2) Renamed Intepreter::continuation_for to be Interpreter:: >>> deopt_continue_after_entry. >>> Renamed Interpreter::bytecodes_to_reexecute to >>> Interpreter::bytecode_should_reexecute >>> >>> >>> Thanks, >>> >>> Changpeng >>> >>> >>> On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara >>> United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >>>> >>>> Problem: >>>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>>> de-optimization occurs on the slow path for array/instance >>>> allocation, the Interpreter will continue execution in next >>>> bytecode after the slow allocation calls without actual copying. The >>>> fundamental problem is that the current vm does not have the logic >>>> for the compilers to specify reexecution for the interpreter >>>> if deoptimization happens for cases like intrinsics of >>>> Object.clone and Arrays.copyOf. >>>> >>>> Solution: >>>> We add such logic in the vm. >>>> (1) For C2, we add an "reexecute" field in JVMState to specify >>>> whether to reexecute this bytecode. This reexecute bit will be >>>> recorded as debug information through **describe_scope. At >>>> runtime, the deoptimizer will get the reexecution information >>>> at the time of unpack_frame through reading the scope. >>>> (2) There are some bytecodes that we have already known that the >>>> interpreter should re-execute them when deoptimization >>>> happens (e.g. _getfield and _putfield). For C2, we set the >>>> reexecute bit for the out JVMS (youngest one) for them at the >>>> time of adding safepoint edges. For C1, we simply set the >>>> reexecute bit for them at the time of ** **describe_scope. >>>> (3) For **Object.clone and Arrays.copyOf., we set the reexecute bit >>>> and pop off the argument when we intrinsify them. >>>> >>>> Tests: >>>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>>> >>>> >>>> Since there are several previous email exchanges, I collect the >>>> questions from them and give a brief answer here: >>>> >>>> ============================ >>>> >From kvn: >>>> ============================ >>>> >Also in src/share/vm/opto/callnode.hpp add an assert >>>> >to check that bci is no changed when _restart is set >>>> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >>>> >>>> I could not do this assertion here because sync_jvms() will >>>> set_bci and we have already set the restart (reexecute) before >>>> some sync_jvms calls. Do you think it ok for an assertion like >>>> assert(_bci== bci || !_restart, ""); whih means for a new bci the >>>> restart >>>> should be false? Thanks. >>>> >>>> =================== >>>> From jrose: >>>> =================== >>>> >Here's a nit: is_restart() in scopeDesc.hpp should be a const >>>> function. >>>> >I'd like to see comment in each case demonstrating why that the >>>> values captured in dummy_restart, and the throwaway restart in >>>> javaClasses.cpp (which should be called dummy_restart also) don't >>>> matter. >>>> Done! I appreciate if you can double check to see whether the >>>> comments are appropriate or not. Thanks. >>>> >>>> >I'd still like to see the restart decision made by >>>> continuation_for turned into an assert. At least compare it with >>>> is_restart(): >>>>> pc = Interpreter::continuation_for(method(), bcp, >>>>> callee_parameters, is_top_frame, use_next_mdp); >>>>> + assert(is_restart() == !use_next_mdp, ""); >>>> >If the assert fails, there may be a bug. >>>> Thanks for pointing out this. Now, after the redesign, >>>> continuation_for does not make decision whether to reexecute or >>>> continue. It is just used to compute the address >>>> for the continuation (next bytecode). I add a new function to >>>> compute the reexecution address >>>> Interpreter::deopt_reexecute_entry(...). What do you think of the new >>>> design? Thanks. >>>> >>>> ========================= >>>> >From never: >>>> ========================= >>>> >I think the term reexecute should be used in place of restart >>>> since that terminology is used elsewhere. Actually I think >>>> should_reexecute is better than is_reexecute as well. >>>> Yes, reexecute better than restart here! Thanks. >>>> >>>> >I don't really like that the restart bit is associated with the >>>> bci. It implies that any scope can be reexecuted when it fact it's >>>> only the topmost one that can be. Given how these describing >>>> scopes is structured I'm not sure I see a better way though. I >>>> >don't see any asserts to enforce this for the scopeDescs either. >>>> Done ! Thanks >>>> The printing forms for ScopeDesc and JVMState should indicate if >>>> this is a restarted bytecode or not. The SA also needs to be >>>> updated to read these modified ScopeDescs. >>>> Done! Thanks. >>>> >>>> >I think manually toggling the restart bit back and forth should be >>>> avoided. Preserve the original and pass on the modified one or >>>> have a helper object that toggles the bit in it's >>>> constructor/destructor. >>>> I just design a new class "PreserveReexecuteAndSP" to save and >>>> restore the reexecute bit and sp. Thanks. >>>> >>>> >>>> Thank you so much for your help and inputs. >>>> >>>> Changpeng >>>> >>>> >>> > > From Thomas.Rodriguez at Sun.COM Thu Jul 30 11:53:25 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 30 Jul 2009 11:53:25 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <4A70FFC6.6000207@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A69F239.3050601@sun.com> <4A70FFC6.6000207@sun.com> Message-ID: <07F4BB87-64AF-4C52-B5F6-744D615BAB19@sun.com> On Jul 29, 2009, at 7:04 PM, Changpeng Fang wrote: > http://cr.openjdk.java.net/~cfang/6833129/webrev.06/ > > Hopefully this is the last version of update! > > It seems we clear the reexecute bit too earlier on the execution > path in the last update (webrev.05). > My original intention is not to let the reexecute state for the > current bytecode to leak into the > exception block. But I do this in the wrong place > (**GraphKit::make_exception_state**). Later > in the parser, when we "do_exception", we still need the current bci > and associated reexecute > bit before handling the catch block. I'm very leery of explicitly clearing the reexecute state. It's just seems likely to be buggy. It seems to me that once we set the value of the reexecute bit for a particular bci in a JVMState, every use of that state at that must respect the reexecute bit. Any use where we deopt must reexecute that bytecode. If an exception is actually thrown then the existence of the exception will override any reexecute logic, which is correct and fine. So given all that why do we ever need to explicitly clear the reexecute bit? I guess I'd like a more complete explanation of what will go wrong if we don't clear the reexecute bit in the cases where you are currently doing it. By the way, I noticed that set_bci requires that the reexecute state be undefined, which seems wrong to me. Shouldn't it change the state to undefined since we're no longer on the original bytecode? tom > > webrev.06 does the reexecute bit clean up in two places: > > (1) Block::set_start_map() -- reexecute bit should always be > initialized or reset the undefined at the block start > For the case of > exception, we will prevent the reexecute bit of the current map > leaking into the catch > block. How exactly does it leak into catch block? Wouldn't that fix this problem? > (2) The place after make_runtime_call of rethrow in > Parse::catch_inline_exceptions where we are sure that > the reexecute bit is no longer needed. I'm not sure I understand why this is needed. > > Thanks, > > Changpeng > > On 07/24/09 10:41, changpeng fang - Sun Microsystems - Santa Clara > United States wrote: >> http://cr.openjdk.java.net/~cfang/6833129/webrev.05/ >> >> I updated the change with the addition of the assert of undefined >> reexecute state >> in set_bci(). This assert caught the problem of reexecute state >> leaking to the exception >> path. Here I propose to clear the reexecute state when the control >> goes to the exception >> path because the parser will stop parsing the current bytecode (it >> will either parses >> the catch block or goes to process exit). >> >> Thanks, >> >> Changpeng >> >> >> >> >> On 07/22/09 13:41, Vladimir Kozlov wrote: >>> I would use REState name instead of REBit. >>> Also why you did not add the assert we talked about in set_bci()? >>> Otherwise looks good. >>> >>> Vladimir >>> >>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ >>>> >>>> Please take a final look at the implementation of reexecute bit. >>>> >>>> Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : >>>> >>>> (1) In C2 JVMState, use a three state field (instead of a >>>> boolean) to represent the reexecute bit: * class JVMState : >>>> public ResourceObj {* >>>> *+ public:* >>>> *+ typedef enum {* >>>> *+ RE_Undefined = -1, // not defined -- will be translated >>>> into false later* >>>> *+ RE_False = 0, // false -- do not reexecute* >>>> *+ RE_True = 1 // true -- reexecute the bytecode* >>>> *+ } REBit; //ReExecution Bit* >>>> *+ * >>>> >>>> In this way, we can keep the original defined reexecute bit (true >>>> or false) when we are going to determine >>>> the reexecute bit by bytecode. >>>> >>>> *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined >>>> && //don't touch defined values* >>>> *+ should_reexecute_implied_by_bytecode(out_jvms)) {* >>>> *+ out_jvms->set_reexecute(JVMState::RE_True);* >>>> *+ }* >>>> *+ * >>>> >>>> (2) Renamed Intepreter::continuation_for to be Interpreter:: >>>> deopt_continue_after_entry. >>>> Renamed Interpreter::bytecodes_to_reexecute to >>>> Interpreter::bytecode_should_reexecute >>>> >>>> >>>> Thanks, >>>> >>>> Changpeng >>>> >>>> >>>> On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa >>>> Clara United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >>>>> >>>>> Problem: >>>>> The problem is in intrinsics Object.clone and Arrays.copyOf. >>>>> When de-optimization occurs on the slow path for array/instance >>>>> allocation, the Interpreter will continue execution in next >>>>> bytecode after the slow allocation calls without actual copying. >>>>> The >>>>> fundamental problem is that the current vm does not have the >>>>> logic for the compilers to specify reexecution for the interpreter >>>>> if deoptimization happens for cases like intrinsics of >>>>> Object.clone and Arrays.copyOf. >>>>> >>>>> Solution: >>>>> We add such logic in the vm. >>>>> (1) For C2, we add an "reexecute" field in JVMState to specify >>>>> whether to reexecute this bytecode. This reexecute bit will be >>>>> recorded as debug information through **describe_scope. At >>>>> runtime, the deoptimizer will get the reexecution information >>>>> at the time of unpack_frame through reading the scope. >>>>> (2) There are some bytecodes that we have already known that the >>>>> interpreter should re-execute them when deoptimization >>>>> happens (e.g. _getfield and _putfield). For C2, we set the >>>>> reexecute bit for the out JVMS (youngest one) for them at the >>>>> time of adding safepoint edges. For C1, we simply set the >>>>> reexecute bit for them at the time of ** **describe_scope. >>>>> (3) For **Object.clone and Arrays.copyOf., we set the reexecute >>>>> bit and pop off the argument when we intrinsify them. >>>>> >>>>> Tests: >>>>> Passed specjvm98, JPRT and the test case of clone in the bug >>>>> report. >>>>> >>>>> >>>>> Since there are several previous email exchanges, I collect the >>>>> questions from them and give a brief answer here: >>>>> >>>>> ============================ >>>>> >From kvn: >>>>> ============================ >>>>> >Also in src/share/vm/opto/callnode.hpp add an assert >>>>> >to check that bci is no changed when _restart is set >>>>> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >>>>> >>>>> I could not do this assertion here because sync_jvms() will >>>>> set_bci and we have already set the restart (reexecute) before >>>>> some sync_jvms calls. Do you think it ok for an assertion like >>>>> assert(_bci== bci || !_restart, ""); whih means for a new bci >>>>> the restart >>>>> should be false? Thanks. >>>>> >>>>> =================== >>>>> From jrose: >>>>> =================== >>>>> >Here's a nit: is_restart() in scopeDesc.hpp should be a const >>>>> function. >>>>> >I'd like to see comment in each case demonstrating why that the >>>>> values captured in dummy_restart, and the throwaway restart in >>>>> javaClasses.cpp (which should be called dummy_restart also) >>>>> don't matter. >>>>> Done! I appreciate if you can double check to see whether the >>>>> comments are appropriate or not. Thanks. >>>>> >>>>> >I'd still like to see the restart decision made by >>>>> continuation_for turned into an assert. At least compare it >>>>> with is_restart(): >>>>>> pc = Interpreter::continuation_for(method(), bcp, >>>>>> callee_parameters, is_top_frame, use_next_mdp); >>>>>> + assert(is_restart() == !use_next_mdp, ""); >>>>> >If the assert fails, there may be a bug. >>>>> Thanks for pointing out this. Now, after the redesign, >>>>> continuation_for does not make decision whether to reexecute or >>>>> continue. It is just used to compute the address >>>>> for the continuation (next bytecode). I add a new function to >>>>> compute the reexecution address >>>>> Interpreter::deopt_reexecute_entry(...). What do you think of >>>>> the new >>>>> design? Thanks. >>>>> >>>>> ========================= >>>>> >From never: >>>>> ========================= >>>>> >I think the term reexecute should be used in place of restart >>>>> since that terminology is used elsewhere. Actually I think >>>>> should_reexecute is better than is_reexecute as well. >>>>> Yes, reexecute better than restart here! Thanks. >>>>> >>>>> >I don't really like that the restart bit is associated with the >>>>> bci. It implies that any scope can be reexecuted when it fact >>>>> it's only the topmost one that can be. Given how these >>>>> describing scopes is structured I'm not sure I see a better way >>>>> though. I >don't see any asserts to enforce this for the >>>>> scopeDescs either. >>>>> Done ! Thanks >>>>> The printing forms for ScopeDesc and JVMState should indicate if >>>>> this is a restarted bytecode or not. The SA also needs to be >>>>> updated to read these modified ScopeDescs. >>>>> Done! Thanks. >>>>> >>>>> >I think manually toggling the restart bit back and forth should >>>>> be avoided. Preserve the original and pass on the modified one >>>>> or have a helper object that toggles the bit in it's constructor/ >>>>> destructor. >>>>> I just design a new class "PreserveReexecuteAndSP" to save and >>>>> restore the reexecute bit and sp. Thanks. >>>>> >>>>> >>>>> Thank you so much for your help and inputs. >>>>> >>>>> Changpeng >>>>> >>>>> >>>> >> >> > > From Changpeng.Fang at Sun.COM Thu Jul 30 13:10:29 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Thu, 30 Jul 2009 13:10:29 -0700 Subject: Request for reviews (M)(resent with big modification): 6833129 : specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot In-Reply-To: <07F4BB87-64AF-4C52-B5F6-744D615BAB19@sun.com> References: <4A52363D.8030106@sun.com> <4A5253E6.6070805@sun.com> <4A52754B.8020400@sun.com> <4A527F6F.4050304@sun.com> <4A52951A.5070409@sun.com> <17962EFC-C952-404D-A7B5-BCD1ED87B468@sun.com> <4A5F955D.5030805@sun.com> <212D1EC0-9407-4C4B-9558-0F7414739533@Sun.COM> <4A5FC2E0.3010506@sun.com> <4A6655CB.8080203@sun.com> <4A67796B.5050604@sun.com> <4A69F239.3050601@sun.com> <4A70FFC6.6000207@sun.com> <07F4BB87-64AF-4C52-B5F6-744D615BAB19@sun.com> Message-ID: <4A71FE35.6010004@sun.com> On 07/30/09 11:53, Tom Rodriguez wrote: > > On Jul 29, 2009, at 7:04 PM, Changpeng Fang wrote: > >> http://cr.openjdk.java.net/~cfang/6833129/webrev.06/ >> >> Hopefully this is the last version of update! >> >> It seems we clear the reexecute bit too earlier on the execution path >> in the last update (webrev.05). >> My original intention is not to let the reexecute state for the >> current bytecode to leak into the >> exception block. But I do this in the wrong place >> (**GraphKit::make_exception_state**). Later >> in the parser, when we "do_exception", we still need the current bci >> and associated reexecute >> bit before handling the catch block. > > I'm very leery of explicitly clearing the reexecute state. It's just > seems likely to be buggy. It seems to me that once we set the value > of the reexecute bit for a particular bci in a JVMState, every use of > that state at that must respect the reexecute bit. Any use where we > deopt must reexecute that bytecode. If an exception is actually thrown > then the existence of the exception will override any reexecute logic, > which is correct and fine. So given all that why do we ever need to > explicitly clear the reexecute bit? I guess I'd like a more complete > explanation of what will go wrong if we don't clear the reexecute bit > in the cases where you are currently doing it. > > By the way, I noticed that set_bci requires that the reexecute state > be undefined, which seems wrong to me. Shouldn't it change the state > to undefined since we're no longer on the original bytecode? Yes, I think reexecute bit should be changed to undefined whenever we change the bci. In this way, we should be clear the reexecute bit explicitly. I was doing the reexecute bit clearing to avoid reexecute bit leaking to other bci (then assert in set_bci). But if we do this for every new bci, that is not needed. Thanks, Changpeng > tom > >> >> webrev.06 does the reexecute bit clean up in two places: >> >> (1) Block::set_start_map() -- reexecute bit should always be >> initialized or reset the undefined at the block start >> For the case of exception, >> we will prevent the reexecute bit of the current map >> leaking into the catch block. > > How exactly does it leak into catch block? Wouldn't that fix this > problem? > >> (2) The place after make_runtime_call of rethrow in >> Parse::catch_inline_exceptions where we are sure that >> the reexecute bit is no longer needed. > > I'm not sure I understand why this is needed. > >> >> Thanks, >> >> Changpeng >> >> On 07/24/09 10:41, changpeng fang - Sun Microsystems - Santa Clara >> United States wrote: >>> http://cr.openjdk.java.net/~cfang/6833129/webrev.05/ >>> >>> I updated the change with the addition of the assert of undefined >>> reexecute state >>> in set_bci(). This assert caught the problem of reexecute state >>> leaking to the exception >>> path. Here I propose to clear the reexecute state when the control >>> goes to the exception >>> path because the parser will stop parsing the current bytecode (it >>> will either parses >>> the catch block or goes to process exit). >>> >>> Thanks, >>> >>> Changpeng >>> >>> >>> >>> >>> On 07/22/09 13:41, Vladimir Kozlov wrote: >>>> I would use REState name instead of REBit. >>>> Also why you did not add the assert we talked about in set_bci()? >>>> Otherwise looks good. >>>> >>>> Vladimir >>>> >>>> changpeng fang - Sun Microsystems - Santa Clara United States wrote: >>>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.04/ >>>>> >>>>> Please take a final look at the implementation of reexecute bit. >>>>> >>>>> Changes from http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ : >>>>> >>>>> (1) In C2 JVMState, use a three state field (instead of a >>>>> boolean) to represent the reexecute bit: * class JVMState : >>>>> public ResourceObj {* >>>>> *+ public:* >>>>> *+ typedef enum {* >>>>> *+ RE_Undefined = -1, // not defined -- will be translated >>>>> into false later* >>>>> *+ RE_False = 0, // false -- do not reexecute* >>>>> *+ RE_True = 1 // true -- reexecute the bytecode* >>>>> *+ } REBit; //ReExecution Bit* >>>>> *+ * >>>>> >>>>> In this way, we can keep the original defined reexecute bit (true >>>>> or false) when we are going to determine >>>>> the reexecute bit by bytecode. >>>>> >>>>> *+ if (out_jvms->should_reexecute() == JVMState::RE_Undefined && >>>>> //don't touch defined values* >>>>> *+ should_reexecute_implied_by_bytecode(out_jvms)) {* >>>>> *+ out_jvms->set_reexecute(JVMState::RE_True);* >>>>> *+ }* >>>>> *+ * >>>>> >>>>> (2) Renamed Intepreter::continuation_for to be Interpreter:: >>>>> deopt_continue_after_entry. >>>>> Renamed Interpreter::bytecodes_to_reexecute to >>>>> Interpreter::bytecode_should_reexecute >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Changpeng >>>>> >>>>> >>>>> On 07/16/09 17:16, changpeng fang - Sun Microsystems - Santa Clara >>>>> United States wrote: >>>>>> http://cr.openjdk.java.net/~cfang/6833129/webrev.03/ >>>>>> >>>>>> Problem: >>>>>> The problem is in intrinsics Object.clone and Arrays.copyOf. When >>>>>> de-optimization occurs on the slow path for array/instance >>>>>> allocation, the Interpreter will continue execution in next >>>>>> bytecode after the slow allocation calls without actual copying. The >>>>>> fundamental problem is that the current vm does not have the >>>>>> logic for the compilers to specify reexecution for the interpreter >>>>>> if deoptimization happens for cases like intrinsics of >>>>>> Object.clone and Arrays.copyOf. >>>>>> >>>>>> Solution: >>>>>> We add such logic in the vm. >>>>>> (1) For C2, we add an "reexecute" field in JVMState to specify >>>>>> whether to reexecute this bytecode. This reexecute bit will be >>>>>> recorded as debug information through **describe_scope. At >>>>>> runtime, the deoptimizer will get the reexecution information >>>>>> at the time of unpack_frame through reading the scope. >>>>>> (2) There are some bytecodes that we have already known that the >>>>>> interpreter should re-execute them when deoptimization >>>>>> happens (e.g. _getfield and _putfield). For C2, we set the >>>>>> reexecute bit for the out JVMS (youngest one) for them at the >>>>>> time of adding safepoint edges. For C1, we simply set the >>>>>> reexecute bit for them at the time of ** **describe_scope. >>>>>> (3) For **Object.clone and Arrays.copyOf., we set the reexecute >>>>>> bit and pop off the argument when we intrinsify them. >>>>>> >>>>>> Tests: >>>>>> Passed specjvm98, JPRT and the test case of clone in the bug report. >>>>>> >>>>>> >>>>>> Since there are several previous email exchanges, I collect the >>>>>> questions from them and give a brief answer here: >>>>>> >>>>>> ============================ >>>>>> >From kvn: >>>>>> ============================ >>>>>> >Also in src/share/vm/opto/callnode.hpp add an assert >>>>>> >to check that bci is no changed when _restart is set >>>>>> >void set_bci(int bci) { assert(!_restart, ""); _bci = bci; } >>>>>> >>>>>> I could not do this assertion here because sync_jvms() will >>>>>> set_bci and we have already set the restart (reexecute) before >>>>>> some sync_jvms calls. Do you think it ok for an assertion like >>>>>> assert(_bci== bci || !_restart, ""); whih means for a new bci the >>>>>> restart >>>>>> should be false? Thanks. >>>>>> >>>>>> =================== >>>>>> From jrose: >>>>>> =================== >>>>>> >Here's a nit: is_restart() in scopeDesc.hpp should be a const >>>>>> function. >>>>>> >I'd like to see comment in each case demonstrating why that the >>>>>> values captured in dummy_restart, and the throwaway restart in >>>>>> javaClasses.cpp (which should be called dummy_restart also) don't >>>>>> matter. >>>>>> Done! I appreciate if you can double check to see whether the >>>>>> comments are appropriate or not. Thanks. >>>>>> >>>>>> >I'd still like to see the restart decision made by >>>>>> continuation_for turned into an assert. At least compare it with >>>>>> is_restart(): >>>>>>> pc = Interpreter::continuation_for(method(), bcp, >>>>>>> callee_parameters, is_top_frame, use_next_mdp); >>>>>>> + assert(is_restart() == !use_next_mdp, ""); >>>>>> >If the assert fails, there may be a bug. >>>>>> Thanks for pointing out this. Now, after the redesign, >>>>>> continuation_for does not make decision whether to reexecute or >>>>>> continue. It is just used to compute the address >>>>>> for the continuation (next bytecode). I add a new function to >>>>>> compute the reexecution address >>>>>> Interpreter::deopt_reexecute_entry(...). What do you think of the >>>>>> new >>>>>> design? Thanks. >>>>>> >>>>>> ========================= >>>>>> >From never: >>>>>> ========================= >>>>>> >I think the term reexecute should be used in place of restart >>>>>> since that terminology is used elsewhere. Actually I think >>>>>> should_reexecute is better than is_reexecute as well. >>>>>> Yes, reexecute better than restart here! Thanks. >>>>>> >>>>>> >I don't really like that the restart bit is associated with the >>>>>> bci. It implies that any scope can be reexecuted when it fact >>>>>> it's only the topmost one that can be. Given how these >>>>>> describing scopes is structured I'm not sure I see a better way >>>>>> though. I >don't see any asserts to enforce this for the >>>>>> scopeDescs either. >>>>>> Done ! Thanks >>>>>> The printing forms for ScopeDesc and JVMState should indicate if >>>>>> this is a restarted bytecode or not. The SA also needs to be >>>>>> updated to read these modified ScopeDescs. >>>>>> Done! Thanks. >>>>>> >>>>>> >I think manually toggling the restart bit back and forth should >>>>>> be avoided. Preserve the original and pass on the modified one >>>>>> or have a helper object that toggles the bit in it's >>>>>> constructor/destructor. >>>>>> I just design a new class "PreserveReexecuteAndSP" to save and >>>>>> restore the reexecute bit and sp. Thanks. >>>>>> >>>>>> >>>>>> Thank you so much for your help and inputs. >>>>>> >>>>>> Changpeng >>>>>> >>>>>> >>>>> >>> >>> >> >> > From Vladimir.Kozlov at Sun.COM Thu Jul 30 13:35:39 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 30 Jul 2009 13:35:39 -0700 Subject: Request for reviews (S): 6865031: Application gives bad result (throws bad exception) with compressed oops Message-ID: <4A72041B.1040404@sun.com> http://cr.openjdk.java.net/~kvn/6865031/webrev.00 Fixed 6865031: Application gives bad result (throws bad exception) with compressed oops Problem: The problem at the same place as in 6851282. The new Phi narrow type is incorrect since it is based on the type of one of inputs which could be subtype of the original Phi's type. The Phi is used in CmpP node which gives a wrong result since Phi's type is wrong. It leads to incorrect graph and generated code. Solution: Produce narrow type for new Phi from the original type instead of using a type of Phi's input. Reviewed by: Fix verified (y/n): y, bug's test and 6851282 test Other testing: JPRT, CTW with +UseCompressedOops From Vladimir.Kozlov at Sun.COM Thu Jul 30 15:00:09 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 30 Jul 2009 15:00:09 -0700 Subject: Request for reviews (XS): 6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops Message-ID: <4A7217E9.7030305@sun.com> http://cr.openjdk.java.net/~kvn/6864914/webrev.00 Fixed 6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops Problem: decodeHeapOop_not_null() defined as not modifying flags but "shift" instruction is used for it where narrow base is zero. Solution: Always use "lea" instruction instead of "shift". Reviewed by: Fix verified (y/n): y, jvm2008 Other testing: JPRT From Thomas.Rodriguez at Sun.COM Thu Jul 30 15:43:43 2009 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 30 Jul 2009 15:43:43 -0700 Subject: Request for reviews (XS): 6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops In-Reply-To: <4A7217E9.7030305@sun.com> References: <4A7217E9.7030305@sun.com> Message-ID: looks good. tom On Jul 30, 2009, at 3:00 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6864914/webrev.00 > > Fixed 6864914: SPECjvm2008 produces invalid result with zero based > Compressed Oops > > Problem: > decodeHeapOop_not_null() defined as not modifying flags > but "shift" instruction is used for it where narrow base is zero. > > Solution: > Always use "lea" instruction instead of "shift". > > Reviewed by: > > Fix verified (y/n): y, jvm2008 > > Other testing: > JPRT > From John.Coomes at sun.com Thu Jul 30 16:02:21 2009 From: John.Coomes at sun.com (John Coomes) Date: Thu, 30 Jul 2009 16:02:21 -0700 Subject: review request (S) 6866585 debug code in ciObjectFactory too slow Message-ID: <19058.9853.988064.242430@sun.com> I'd appreciate some reviews of 6866585: debug code in ciObjectFactory too slow for large objects. http://cr.openjdk.java.net/~jcoomes/6866585-ci-debug/ (The bug is not yet visible on bugs.sun.com; it should be sometime soon.) Before the change, a fastdebug build took 6+ minutes to run the test; now it takes a few seconds. Since I almost never touch compiler code, I'd also appreciate recommendations for tests to run. -John From vladimir.kozlov at sun.com Thu Jul 30 19:44:48 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 31 Jul 2009 02:44:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops Message-ID: <20090731024502.1C6BDED82@hg.openjdk.java.net> Changeset: 60fea60a6db5 Author: kvn Date: 2009-07-30 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/60fea60a6db5 6864914: SPECjvm2008 produces invalid result with zero based Compressed Oops Summary: Always use "lea" instruction for narrow oop decoding instead of "shift". Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp From john.coomes at sun.com Thu Jul 30 21:29:59 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 31 Jul 2009 04:29:59 +0000 Subject: hg: jdk7/hotspot-comp: 2 new changesets Message-ID: <20090731042959.EDB27EDAC@hg.openjdk.java.net> Changeset: c4523c6f8204 Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/c4523c6f8204 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! make/deploy-rules.gmk ! make/jprt.properties ! make/sanity-rules.gmk Changeset: cab520b37e9a Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/cab520b37e9a Added tag jdk7-b67 for changeset c4523c6f8204 ! .hgtags From john.coomes at sun.com Thu Jul 30 21:35:50 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 31 Jul 2009 04:35:50 +0000 Subject: hg: jdk7/hotspot-comp/corba: 2 new changesets Message-ID: <20090731043553.20F3AEDB1@hg.openjdk.java.net> Changeset: a12ea7c7b497 Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/a12ea7c7b497 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! make/Makefile ! make/common/Library.gmk ! make/common/Rules.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk ! make/jprt.properties ! make/org/omg/idl/Makefile ! make/tools/logutil/Makefile ! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerReadStream.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAFactory.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBSingleton.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/tools/corba/se/idl/Parser.java ! src/share/classes/com/sun/tools/corba/se/idl/first.set ! src/share/classes/com/sun/tools/corba/se/idl/follow.set ! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl ! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl ! src/share/classes/com/sun/tools/corba/se/idl/idl.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/logutil/Input.java ! src/share/classes/com/sun/tools/corba/se/logutil/InputCode.java ! src/share/classes/com/sun/tools/corba/se/logutil/InputException.java ! src/share/classes/com/sun/tools/corba/se/logutil/MC.java ! src/share/classes/org/omg/CORBA/ORB.java ! src/windows/resource/version.rc Changeset: ec55ebb18a61 Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/ec55ebb18a61 Added tag jdk7-b67 for changeset a12ea7c7b497 ! .hgtags From john.coomes at sun.com Thu Jul 30 21:45:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 31 Jul 2009 04:45:03 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: 2 new changesets Message-ID: <20090731044506.C7FC5EDB7@hg.openjdk.java.net> Changeset: a033af8d824a Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/a033af8d824a 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! make/build.properties ! make/build.xml ! make/jprt.properties ! src/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java ! src/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java Changeset: c77f6ec0bd9b Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/c77f6ec0bd9b Added tag jdk7-b67 for changeset a033af8d824a ! .hgtags From john.coomes at sun.com Thu Jul 30 21:50:39 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 31 Jul 2009 04:50:39 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: 2 new changesets Message-ID: <20090731045042.BBA5BEDBD@hg.openjdk.java.net> Changeset: faa13cd4d6cd Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/faa13cd4d6cd 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: b70ce5b02bbc Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/b70ce5b02bbc Added tag jdk7-b67 for changeset faa13cd4d6cd ! .hgtags From john.coomes at sun.com Thu Jul 30 21:56:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 31 Jul 2009 04:56:12 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 4 new changesets Message-ID: <20090731045715.3A1ABEDC2@hg.openjdk.java.net> Changeset: 8eddead6a701 Author: yhuang Date: 2009-07-02 20:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/8eddead6a701 6606396: Notepad and Stylepad demos don't run in Japanese locale. Reviewed-by: peytoia, ogino ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties Changeset: d8ff2f23a8fc Author: yhuang Date: 2009-07-26 19:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d8ff2f23a8fc Merge Changeset: a952aafd5181 Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/a952aafd5181 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! make/common/Defs-linux.gmk ! make/common/Release.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/sun/Makefile ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/TrayIcon.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/System.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/lang/java_props_md.c ! test/demo/jvmti/hprof/HelloWorld.java ! test/demo/jvmti/hprof/StackMapTableTest.java ! test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java ! test/tools/jar/index/MetaInf.java Changeset: 5c52dcbde260 Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5c52dcbde260 Added tag jdk7-b67 for changeset a952aafd5181 ! .hgtags From john.coomes at sun.com Thu Jul 30 22:08:29 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 31 Jul 2009 05:08:29 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 2 new changesets Message-ID: <20090731050834.5B225EDC7@hg.openjdk.java.net> Changeset: 14b1a8ede954 Author: xdono Date: 2009-07-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/14b1a8ede954 6862919: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 07/09 Reviewed-by: tbell, ohair ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/legacy.properties ! test/tools/javac/typeAnnotations/failures/OldArray.java Changeset: 689bec60a482 Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/689bec60a482 Added tag jdk7-b67 for changeset 14b1a8ede954 ! .hgtags From Vladimir.Kozlov at Sun.COM Fri Jul 31 09:58:07 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 31 Jul 2009 09:58:07 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <4A6D8B3D.6060704@Sun.COM> Message-ID: <4A73229F.9090903@sun.com> John, I did not find anything alarming. Could you rename non_perm_state_clean() to non_perm_not_marked() or something otherwise the next code looks strange since the non_perm_state is also used to flag "on list" state: + debug_only(cur->clear_non_perm_marked()); + assert(cur->non_perm_state_clean(), ""); + assert(cur->on_non_perm_list(), "else shouldn't be on this list"); In nmethod.hpp could you move enum above its usage and use it in on_non_perm_list()? Can you change the comment in parse3.cpp to next?: // cases: // should_be_constant = (oop == null || oop in perm space || NonPermCodeRefs >= 2) // has_encoding = (should_be_constant || NonPermCodeRefs == 1) // In globals.hpp it would be better to have "1: allow" on a separate line. Thanks, Vladimir John Rose wrote: > I have updated the webrev slightly, and fixed the URL: > http://cr.openjdk.java.net/~jrose/6863023/webrev.01/ > > Someone observed that the pruning logic might not be exercised, since > non-perms do not become perm. But it does get exercised when nmethods > are deallocated. (And that caused a bug I had to fix...) > > -- John > > On Jul 28, 2009, at 7:08 PM, John Rose wrote: > >> On Jul 27, 2009, at 4:10 AM, Christian Thalinger wrote: >> >>> It seems there is a problem with returns: >> >> Right; it was an incomplete code change. Thanks. -- John > From Changpeng.Fang at Sun.COM Fri Jul 31 11:56:35 2009 From: Changpeng.Fang at Sun.COM (changpeng fang - Sun Microsystems - Santa Clara United States) Date: Fri, 31 Jul 2009 11:56:35 -0700 Subject: Request for reviews (S): 6865031: Application gives bad result (throws bad exception) with compressed oops In-Reply-To: <4A72041B.1040404@sun.com> References: <4A72041B.1040404@sun.com> Message-ID: <4A733E63.2030503@sun.com> Looks good to me. Changpeng On 07/30/09 13:35, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6865031/webrev.00 > > Fixed 6865031: Application gives bad result (throws bad exception) > with compressed oops > > Problem: > The problem at the same place as in 6851282. > The new Phi narrow type is incorrect since it is based > on the type of one of inputs which could be subtype of > the original Phi's type. The Phi is used in CmpP node > which gives a wrong result since Phi's type is wrong. > It leads to incorrect graph and generated code. > > Solution: > Produce narrow type for new Phi from the original type > instead of using a type of Phi's input. > > Reviewed by: > > Fix verified (y/n): y, bug's test and 6851282 test > > Other testing: > JPRT, CTW with +UseCompressedOops > From Vladimir.Kozlov at Sun.COM Fri Jul 31 14:43:32 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 31 Jul 2009 14:43:32 -0700 Subject: for review (L): 6858164: invokedynamic code needs some cleanup (post-6655638) In-Reply-To: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> Message-ID: <4A736584.8000307@sun.com> Looks good. I am only concern about the changes "char*" to "const char*" which could affect builds on linux. Thanks, Vlaidmir John Rose wrote: > http://cr.openjdk.java.net/~jrose/6858164/vm-webrev.01/ > > Summary: These are fixes for method handles proper. > - correctly raises exceptions > - supports safe bitwise "raw" conversions (e.g., int -> void) > - fixes bugs (various, small) revealed by VerifyMethodHandles > - dead code is removed > - debugging support is improved > > Still to follow: > - more bug fixes to the invokedynamic instruction > - runtime simplification for invokedynamic > - compiler support for invokedynamic > - inlining of method handles > - API adjustments that affect the JVM (mainly, removing private supertypes) > From vladimir.kozlov at sun.com Fri Jul 31 16:05:30 2009 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 31 Jul 2009 23:05:30 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6865031: Application gives bad result (throws bad exception) with compressed oops Message-ID: <20090731230538.975A4EEC7@hg.openjdk.java.net> Changeset: 55cb84cd1247 Author: kvn Date: 2009-07-31 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/55cb84cd1247 6865031: Application gives bad result (throws bad exception) with compressed oops Summary: Produce narrow type for new Phi from the original Phi type. Reviewed-by: cfang ! src/share/vm/opto/cfgnode.cpp + test/compiler/6865031/Test.java From Vladimir.Kozlov at Sun.COM Fri Jul 31 16:06:57 2009 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 31 Jul 2009 16:06:57 -0700 Subject: for review (L): 6858164: invokedynamic cleanups (part B) In-Reply-To: References: <618841AB-C98E-4CB4-896A-5C1CDA5594C9@sun.com> <4A6D99A2.60104@Sun.COM> Message-ID: <4A737911.1000609@sun.com> Looks good. Vladimir John Rose wrote: > As I mentioned in the previous review request, JSR 292 code for the > JavaOne Preview needs two batches of fixes. > > Here is the second batch, for invokedynamic (on top of method handles). > The diffs of this review request are new, although I erroneously > mentioned its bug number in a previous review request. > > http://cr.openjdk.java.net/~jrose/6858164/webrev.02/ > > 6858164: invokedynamic code needs some cleanup (post-6655638) > > 467 lines changed: 100 ins; 287 del; 80 mod; 42741 unchg > > Summary: > - fix several crashers > - remove needless paths for boxed-style bootstrap method call > - refactor & simplify APIs for rewriter constantPoolOop > - remove sun.dyn.CallSiteImpl > > Testing: These changes have been in use by several users of the mlvm > patch repo., as a base for further development. They correctly run all > current invokedynamic test code. > > Still to follow: > - compiler support for invokedynamic > - inlining of method handles > - API adjustments that affect the JVM (mainly, removing private supertypes) > - ports to x64, SPARC > - compressed oop support > From changpeng.fang at sun.com Fri Jul 31 21:49:06 2009 From: changpeng.fang at sun.com (changpeng.fang at sun.com) Date: Sat, 01 Aug 2009 04:49:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6833129: specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot Message-ID: <20090801044915.5FC5BEEFE@hg.openjdk.java.net> Changeset: 9987d9d5eb0e Author: cfang Date: 2009-07-31 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9987d9d5eb0e 6833129: specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot Summary: developed a reexecute logic for the interpreter to reexecute the bytecode when deopt happens Reviewed-by: kvn, never, jrose, twisti ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp + test/compiler/6833129/Test.java