From david.holmes at oracle.com Sat Jul 2 07:13:38 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Sat, 02 Jul 2011 14:13:38 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Message-ID: <20110702141341.10B2F47134@hg.openjdk.java.net> Changeset: 109d1d265924 Author: dholmes Date: 2011-07-02 04:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/109d1d265924 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Reviewed-by: kamg, dsamersoff ! make/jprt.gmk From volker.simonis at gmail.com Mon Jul 4 02:51:46 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Jul 2011 11:51:46 +0200 Subject: Question about "6961186: Better VM handling of unexpected exceptions from application native code" In-Reply-To: <4E0C4C5A.8030903@oracle.com> References: <4E0C4C5A.8030903@oracle.com> Message-ID: Hi David, first I thought you're right, but actually you're not:) libjvm.so isn't linked dynamically against libstdc++, but statically. See make/linux/makefiles/gcc.make: # statically link libstdc++.so, work with gcc but ignored by g++ STATIC_STDCXX = -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic And actually 'set_terminate' is already included in the current libjvm.so: > nm -C jdk1.6.0_26/jre/lib/amd64/server/libjvm.so | grep set_terminate 00000000008791f0 t std::set_terminate(void (*)()) Nevertheless you're probably right that it is not worth while porting the change to Linux as well. Regards, Volker On Thu, Jun 30, 2011 at 12:13 PM, David Holmes wrote: > Hi Volker, > > Volker Simonis said the following on 06/29/11 18:26: >> >> recently the bug "6961186: Better VM handling of unexpected exceptions >> from application native code" has been fixed but the fix only applies >> for Windows and Solaris platforms. >> While the bug evaluation at >> http://bugs.sun.com/view_bug.do?bug_id=6961186 mentions that the fix >> for Solaris and Linux would be the same (i.e. using set_terminate to >> catch uncaught C++ exceptions), the fix was apparently not implemented >> for Linux. >> >> Has the Linux fix been omitted intentionally or accidentally? > > As I understand it, while the suggested fix should work for Linux we > actually don't link with the C++ library on Linux that provides this API, > and we did not want to start doing so for an obscure problem that hasn't > even been reported on Linux. For Linux the error is apparently much clearer > even without additional handling by the VM. > > The problems we've seen here have predominantly been on Windows. Solaris was > included as it was trivial to do so. > > David Holmes > >> Regards, >> Volker > From joel.franck at oracle.com Tue Jul 5 04:56:26 2011 From: joel.franck at oracle.com (=?UTF-8?B?Sm9lbCBCb3JnZ3LDqW4tRnJhbmNr?=) Date: Tue, 05 Jul 2011 13:56:26 +0200 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: <4E029B13.7030308@oracle.com> References: <4E009399.4060000@oracle.com> <4E010DEB.3030104@oracle.com> <4E029B13.7030308@oracle.com> Message-ID: <4E12FBEA.6000201@oracle.com> On 06/23/2011 03:46 AM, Coleen Phillimore wrote: > http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/src/share/vm/utilities/quicksort.cpp.html > > 46 bool aIsOdd = a % 2 == 1; > 47 bool bIsOdd = b % 2 == 1; > Sorry for being late, but this does not work for negative numbers. Also all the tests are on arrays of positive numbers. Perhaps this does not matter that much because it is testing code ... cheers /Joel Joel Borggr?n-Franck JVM Sustaining Engineering > Can you add () around the bit operations? Since the order precedence of > these operators is always surprising (at least to me). > > I like the way you set the pattern for the internal testing framework. > Thanks for getting this started. > > When we move these methodOops out of permgen, we might want to go back > to stdlib::quicksort. It would be less code for us to maintain. > Otherwise, this looks pretty straightforward and I like this fix. > > Thanks, > Coleen > > > On 6/21/2011 5:32 PM, Bengt Rutisson wrote: >> >> Hi again, >> >> For completeness. Here is the graph for sorting maximum length arrays >> on Linux x64 (run on my laptop). These runs show that my >> implementation takes twice as long as the stdlib version. I am not >> happy about that, but I don't know how much effort it is worth to >> optimize for this case. >> >> Bengt >> >> >> On 2011-06-21 14:50, Bengt Rutisson wrote: >>> >>> Hi Runtime and GC, >>> >>> Sending this review request to both groups. I fixed a GC bug, but the >>> changes are in runtime code. >>> >>> The bug that I fixed is this one: >>> 7016112 CMS: crash during promotion testing >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 >>> >>> And here is the webrev: >>> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ >>> >>> The investigation to find the root of the crashes reported in 7016112 >>> was quite lengthy. It is not that easy to read the CR and figure out >>> what is going on, so here is some background: >>> >>> When we load classes we store references to the methods of a class in >>> an object array. When we have loaded all methods we sort the object >>> array to allow binary search within the array. To do this sort we use >>> stdlib::qsort(), which is the standard library quicksort implementation. >>> >>> If we are using CMS we might be doing concurrent marking while we are >>> sorting the object array. The object array can be found by the >>> concurrent marking code and it may start iterating over the array >>> while we are sorting it. The problem is that on Windows the >>> stdlib::qsort() is not implemented to do atomic updates of elements >>> in the array that it sorts. Instead it does a byte-by-byte swap when >>> it needs to swap two values. That is an easy way to implement >>> different element widths, but it means that at some point in time one >>> element may contain a few bytes from the element above or below. If >>> this happens at the same time as the marking code is trying to read >>> that element, we will be marking some random address and not the >>> method that was supposed to be marked. >>> >>> On Solaris and Linux the stdlib::qsort() implementations try to swap >>> as wide data types as possible so this issue should not occur there. >>> On the other hand we have no guarantees that this will always be how >>> stdlib::qsort() is implemented. >>> >>> After some discussions about different ways of solving this we came >>> to the conclusion that the simplest way is to implement our own >>> quicksort that operates on the correct pointer width (oop or narrowOop). >>> >>> So, this is what I have done to fix this bug. >>> >>> Also, it is likely that this problem will go away when the perm gen >>> removal project is finished. Right now it looks like we will not be >>> tracing and marking methods at all after that change. >>> >>> * Questions * >>> >>> - Should we keep the bubble sort that is done before calling >>> quicksort in methodOopDesc::sort_methods() ? >>> >>> - Should we keep the idempotent option or should we try to always use >>> idempotent sorting (see performance test below)? >>> >>> - What is the best way to handle unit tests? I added a flag called >>> ExecuteInternalVMTests to run unit tests. This is in line with the >>> existing ErrorHandlerTest flag. My thought is that we can use this >>> same flag for other unit tests than just the quicksort tests. Would >>> be good if we could get these tests executed by JPRT as well. I >>> simply run these with "java -XX:+ExecuteInternalVMTests -version". >>> >>> >>> * Testing * >>> >>> Did the obvious testing: Ran JPRT with the changes in the webrev and >>> ran the failing nsk test from the bug >>> (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral >>> days without failing. >>> >>> I created some unit tests for the quicksort implementation and they >>> all pass. >>> >>> I also made a build that sorts both with my own quicksort and with >>> stdlib::qsort and then compares that the arrays have the same sort >>> order. Ran this through JPRT and it seems to work on all platforms. >>> That run also included the unit tests. If anybody wants to see how >>> this testing was done, there is a separate webrev for that build. The >>> interesting code is in methodOop.cpp: >>> >>> http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ >>> >>> * Performance * >>> >>> I am a bit unsure how to get any relevant performance data for this >>> change. What I have done so far is to create a class that has 65535 >>> methods (which is the maximum - the length of the method array is u2) >>> and I have measured how long it takes to sort this method array. The >>> methods have random names but every hundredth method has 4 overloaded >>> version. This makes sure that there are some duplicates in the array. >>> >>> For now I have run this on my Windows x64 work station with 4 cpus >>> and on a Solaris Sparc machine with 2 cpus (uname says: SunOS >>> sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). >>> >>> I am attaching graphs for the results. The Y-axis has time in nano >>> seconds. Judging by this my quicksort is a bit faster on Windows and >>> a bit slower on Solaris. But the interesting thing is that the >>> idempotent version is faster than the default behavior on Windows and >>> on par with the default on Solaris. I assume that this is due to the >>> fact that some stores can be avoided if we don't do swap of >>> duplicates. This means that (at least on Windows) swap is more >>> expensive than compare. If this is true we should probably remove the >>> special treatment of idempotent. >>> >>> I could run this on more machines, but I am not sure how relevant >>> this type of data is. Most method arrays will be much shorter and >>> compared to reading the class from a file the sort will be in the noise. >>> >>> Long email...I hope I covered most of the issues here. Let me know if >>> you have any questions. >>> >>> Thanks, >>> Bengt >> > From David.Holmes at oracle.com Wed Jul 6 22:25:39 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 07 Jul 2011 15:25:39 +1000 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol Message-ID: <4E154353.8070601@oracle.com> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ This is a simple fix in the VM to honour the Throwable immutability protocol that was defined for Java 7. Pre-allocated Throwable instances are normally immutable, but that is not the case for a group of pre-allocated OutOfMemoryError instances. To conform to the protocol, when we set the backtrace (VM representation of the stackTrace) we have to set the stackTrace field to the sentinel value stored in the static Throwable.UNASSIGNED_STACK field. With this fix in place the workaround in Throwable.java, under 7045138, can be backed out. Thanks, David From John.Coomes at oracle.com Wed Jul 6 23:53:45 2011 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 6 Jul 2011 23:53:45 -0700 Subject: review request (S/M): embedded -> open changes Message-ID: <19989.22521.173461.664975@oracle.com> A handful of moving from closed to open source; most relate to embedded builds. They've already been reviewed within Oracle (necessary before exposing them), but additional feedback is welcome. The first is trivial (just adds some includes); I'm going to push it shortly. http://cr.openjdk.java.net/~jcoomes/emb-overview.html -John From coleen.phillimore at oracle.com Fri Jul 8 01:49:34 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 08 Jul 2011 08:49:34 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 37 new changesets Message-ID: <20110708085043.9A35247289@hg.openjdk.java.net> Changeset: e2af886d540b Author: trims Date: 2011-07-01 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e2af886d540b 7061691: Fork HS21 to HS22 - renumber Minor and build numbers of JVM Summary: Update the Minor and Build numbers for HS22 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1e3493ac2d11 Author: ysr Date: 2011-05-27 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1e3493ac2d11 7048342: CMS: eob == _limit || fc->isFree() failed: Only a free chunk should allow us to cross over the limit Summary: The freeness bit was being cleared in debug code when it shouldn't have been. Also removed unused FreeChunk methods linkAfterNonNull and clearPrev. Reviewed-by: brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp Changeset: 5c0a3c1858b1 Author: ysr Date: 2011-06-02 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5c0a3c1858b1 7048782: CMS: assert(last_chunk_index_to_check<= last_chunk_index) failed: parCardTableModRefBS.cpp:359 Summary: The LNC array is sized before the start of a scavenge, while the heap may expand during a scavenge. With CMS, the last block of an arbitrary suffice of the LNC array may expand due to coalition with the expansion delta. We now take care not to attempt access past the end of the LNC array. LNC array code will be cleaned up and suitably encapsulated as part of the forthcoming performance RFE 7043675. Reviewed-by: brutisso ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp Changeset: e66f38dd58a9 Author: ysr Date: 2011-06-08 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e66f38dd58a9 Merge Changeset: 053d84a76d3d Author: tonyp Date: 2011-06-08 15:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/053d84a76d3d 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions Summary: This changeset extends the logging information generated by +PrintGCDetails to also print out separate size transitions for the eden, survivors, and old regions. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: ae5b2f1dcf12 Author: tonyp Date: 2011-06-08 21:48 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ae5b2f1dcf12 7045662: G1: OopsInHeapRegionClosure::set_region() should not be virtual Summary: make the method non-virtual, remove five unused closures, and fix a couple of copyright typos. Reviewed-by: stefank, johnc, poonam ! 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/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: c3f1170908be Author: tonyp Date: 2011-06-10 13:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c3f1170908be 7045330: G1: Simplify/fix the HeapRegionSeq class 7042285: G1: native memory leak during humongous object allocation 6804436: G1: heap region indices should be size_t Summary: A series of fixes and improvements to the HeapRegionSeq class: a) replace the _regions growable array with a standard C array, b) avoid de-allocating / re-allocating HeapRegion instances when the heap shrinks / grows (fix for 7042285), c) introduce fast method to map address to HeapRegion via a "biased" array pointer, d) embed the _hrs object in G1CollectedHeap, instead of pointing to it via an indirection, e) assume that all the regions added to the HeapRegionSeq instance are contiguous, f) replace int's with size_t's for indexes (and expand that to HeapRegion as part of 6804436), g) remove unnecessary / unused methods, h) rename a couple of fields (_alloc_search_start and _seq_bottom), i) fix iterate_from() not to always start from index 0 irrespective of the region passed to it, j) add a verification method to check the HeapRegionSeq assumptions, k) always call the wrappers for _hrs.iterate(), _hrs_length(), and _hrs.at() from G1CollectedHeap, not those methods di rectly, and l) unify the code that expands the sequence (by either re-using or creating a new HeapRegion) and make it robust wrt to a HeapRegion allocation failing. Reviewed-by: stefank, johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 2a241e764894 Author: minqi Date: 2011-06-10 15:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2a241e764894 6941923: RFE: Handling large log files produced by long running Java Applications Summary: supply optinal flags to realize gc log rotation Reviewed-by: ysr, jwilhelm ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/gc/6941923/test6941923.sh Changeset: 42df21744b50 Author: minqi Date: 2011-06-10 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/42df21744b50 Merge Changeset: ef2d1b8f2dd4 Author: ysr Date: 2011-06-13 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ef2d1b8f2dd4 7051430: CMS: ongoing CMS cycle should terminate abruptly to allow prompt JVM termination at exit Summary: It turns out that there is no need to explicitly stop CMS since the JVM is taken down at a terminal safepoint during which CMS threads are (terminally) inactive. This will need to be revised if and when we evolve in the future to a point where we allow JVM reincarnation in the same process, but those changes will be much more sweeping than just terminating CMS threads. The unused ::stop() methods will be removed in a separate CR. Also include in this CR is the fix for a small typo in the spelling of UseGCLogFileRotation in a message in arguments.cpp, brought to our attention by Rainer Jung and reviewed by minqi. Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 74cd10898bea Author: brutisso Date: 2011-06-13 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/74cd10898bea 6918185: Remove unused code for lost card-marking optimization in BacktraceBuilder Summary: Removed dead code Reviewed-by: ysr, coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp Changeset: 842b840e67db Author: tonyp Date: 2011-06-14 10:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/842b840e67db 7046558: G1: concurrent marking optimizations Summary: Some optimizations to improve the concurrent marking phase: specialize the main oop closure, make sure a few methods in the fast path are properly inlined, a few more bits and pieces, and some cosmetic fixes. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp + src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/utilities/bitMap.hpp Changeset: 6747fd0512e0 Author: johnc Date: 2011-06-14 11:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6747fd0512e0 7004681: G1: Extend marking verification to Full GCs Summary: Perform a heap verification after the first phase of G1's full GC using objects' mark words to determine liveness. The third parameter of the heap verification routines, which was used in G1 to determine which marking bitmap to use in liveness calculations, has been changed from a boolean to an enum with values defined for using the mark word, and the 'prev' and 'next' bitmaps. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: 5130fa1b24f1 Author: johnc Date: 2011-06-15 10:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5130fa1b24f1 7045751: G1: +ExplicitGCInvokesConcurrent causes excessive single region evacuation pauses Summary: When ExplicitGCInvokesConcurrent is enabled, do not perform an evacuation pause if a marking cycle is already in progress and block the requesting thread until the marking cycle completes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c9ca3f51cf41 Author: tonyp Date: 2011-06-16 15:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9ca3f51cf41 6994322: Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap Summary: Remove two unused parameters from the mem_allocate() method and update its uses accordingly. Reviewed-by: stefank, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: f75137faa7fe Author: ysr Date: 2011-06-20 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f75137faa7fe 6916968: CMS: freeList.cpp:304 assert(_allocation_stats.prevSweep() + ..., "Conservation Principle") Summary: Fix assert and adjust demand volume computation by adding missing factor. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 23d434c6290d Author: tonyp Date: 2011-06-20 22:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/23d434c6290d 7055073: G1: code cleanup in the concurrentMark.* files Summary: Only cosmetic changes to make the concurrentMark.* more consistent, code-style-wise, with the rest of the codebase. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: e8b0b0392037 Author: tonyp Date: 2011-06-21 15:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8b0b0392037 7046182: G1: remove unnecessary iterations over the collection set Summary: Remove two unnecessary iterations over the collection set which are supposed to prepare the RSet's of the CSet regions for parallel iterations (we'll make sure this is done incrementally). I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code. Reviewed-by: brutisso, johnc ! 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/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 5f6f2615433a Author: tonyp Date: 2011-06-24 12:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f6f2615433a 7049999: G1: Make the G1PrintHeapRegions output consistent and complete Summary: Extend and make more consistent the output from the G1PrintHeapRegions flag. Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.cpp + src/share/vm/gc_implementation/g1/g1HRPrinter.hpp Changeset: 04760e41b01e Author: brutisso Date: 2011-06-28 14:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/04760e41b01e 7016112: CMS: crash during promotion testing Summary: Also reviewed by mikael.gerdin at oracle.com; stdlib:qsort() does byte-by-byte swapping on Windows. This leads to pointer shearing. Fix is to implement a quicksort that does full pointer updates. Reviewed-by: never, coleenp, ysr ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/utilities/quickSort.cpp + src/share/vm/utilities/quickSort.hpp Changeset: 4bf3cbef0b3e Author: jcoomes Date: 2011-07-06 08:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4bf3cbef0b3e Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/globals.hpp Changeset: d83ac25d0304 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d83ac25d0304 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: aacaff365100 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aacaff365100 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java Changeset: de6a837d75cf Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de6a837d75cf 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad Changeset: aabf25fa3f05 Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aabf25fa3f05 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp Changeset: ddd894528dbc Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ddd894528dbc 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 498c6cf70f7e Author: kvn Date: 2011-06-28 14:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/498c6cf70f7e 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Summary: parseClassFile() incorrectly uses nonstatic_oop_map_size() method instead of nonstatic_oop_map_count(). Reviewed-by: never Contributed-by: Krystal Mok ! src/share/vm/classfile/classFileParser.cpp Changeset: 6ae7a1561b53 Author: kvn Date: 2011-06-28 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6ae7a1561b53 6990015: Incorrect Icache line size is used for 64 bit x86 Summary: correct Icache::line_size for x64 and add verification code into vm_version_x86. Reviewed-by: never, phh ! src/cpu/x86/vm/icache_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: e3cbc9ddd434 Author: kvn Date: 2011-06-28 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3cbc9ddd434 7044738: Loop unroll optimization causes incorrect result Summary: take into account memory dependencies when clonning nodes in clone_up_backedge_goo(). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp + test/compiler/7044738/Test7044738.java + test/compiler/7046096/Test7046096.java Changeset: 7889bbcc7f88 Author: kvn Date: 2011-06-28 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7889bbcc7f88 7047954: VM crashes with assert(is_Mem()) failed Summary: cast constant array ptrs to bottom Reviewed-by: never ! src/share/vm/opto/compile.cpp Changeset: 6f6e91603a45 Author: iveresov Date: 2011-07-01 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f6e91603a45 7058689: Tiered: Reprofiling doesn't happen in presence of level 4 OSR methods Summary: Take into account current state of profiling before believing that existing higher level versions are valid Reviewed-by: kvn, never ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: 2c359f27615c Author: iveresov Date: 2011-07-01 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2c359f27615c 7057120: Tiered: Allow C1 to inline methods with loops Summary: Recompile the enclosing methods without inlining of the method that has OSRed to level 4 or recompile the enclosing method at level 4. Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 15559220ce79 Author: never Date: 2011-07-05 16:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/15559220ce79 6478991: C1 NullCheckEliminator yields incorrect exceptions Reviewed-by: twisti, iveresov ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6478991/NullCheckTest.java Changeset: fe240d87c6ec Author: never Date: 2011-07-06 09:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fe240d87c6ec 7061101: adlc should complain about mixing block and expression forms of ins_encode Reviewed-by: kvn ! src/share/vm/adlc/adlparse.cpp Changeset: 3e23978ea0c3 Author: never Date: 2011-07-06 18:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3e23978ea0c3 7062856: Disassembler needs to be smarter about finding hsdis after 1.7 launcher changes Summary: do explicit lookup emulating old LD_LIBRARY_PATH search Reviewed-by: kvn, jrose ! src/share/tools/hsdis/README ! src/share/vm/compiler/disassembler.cpp Changeset: b16582d6c7db Author: kvn Date: 2011-07-07 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b16582d6c7db Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp Changeset: 5447b2c582ad Author: coleenp Date: 2011-07-07 22:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5447b2c582ad Merge From john.coomes at oracle.com Fri Jul 8 18:24:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Jul 2011 01:24:00 +0000 Subject: hg: hsx/hotspot-rt: 15 new changesets Message-ID: <20110709012401.0E0F4472CE@hg.openjdk.java.net> Changeset: bde8f3d56ffa Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/bde8f3d56ffa Added tag jdk7-b142 for changeset cfbbdb77eac0 ! .hgtags Changeset: 14b8e7eee105 Author: ohair Date: 2011-05-16 08:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/14b8e7eee105 7043700: Regression for IcedTea builds Reviewed-by: dholmes, omajid ! Makefile ! make/jprt.gmk Changeset: 7203965666a4 Author: schien Date: 2011-05-20 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/7203965666a4 Added tag jdk7-b143 for changeset 14b8e7eee105 ! .hgtags Changeset: 3408a19567a6 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/3408a19567a6 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 4373d87e6f37 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/4373d87e6f37 Added tag jdk7-b144 for changeset 7203965666a4 ! .hgtags Changeset: 93d2590fd849 Author: jeff Date: 2011-05-27 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/93d2590fd849 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 55e9ebf03218 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/55e9ebf03218 Merge Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags Changeset: 404bd0b9385f Author: schien Date: 2011-06-08 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/404bd0b9385f Merge Changeset: 3e0b96f8f6a0 Author: schien Date: 2011-06-20 16:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/3e0b96f8f6a0 Added tag jdk7-b146 for changeset 2d38c2a79c14 ! .hgtags Changeset: 29e7e1474b5e Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/29e7e1474b5e Merge Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d91364304d7c Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/d91364304d7c Merge Changeset: ee67ee3bd597 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/ee67ee3bd597 Added tag jdk7-b147 for changeset d91364304d7c ! .hgtags Changeset: 04734fe746f0 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/04734fe746f0 Merge From john.coomes at oracle.com Fri Jul 8 18:24:09 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Jul 2011 01:24:09 +0000 Subject: hg: hsx/hotspot-rt/corba: 19 new changesets Message-ID: <20110709012424.1044B472CF@hg.openjdk.java.net> Changeset: 62a6a0a1a350 Author: mfang Date: 2011-05-10 15:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/62a6a0a1a350 7043548: message drop 3 translation integration Reviewed-by: yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties Changeset: a2f340a048c8 Author: mfang Date: 2011-05-10 19:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/a2f340a048c8 Merge Changeset: 51ed32f6f4de Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/51ed32f6f4de Added tag jdk7-b142 for changeset a2f340a048c8 ! .hgtags Changeset: b06dd44a2740 Author: schien Date: 2011-05-20 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/b06dd44a2740 Added tag jdk7-b143 for changeset 51ed32f6f4de ! .hgtags Changeset: c908ae06bd6b Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/c908ae06bd6b 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 7033a5756ad5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/7033a5756ad5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/corba/se/impl/transport/CorbaTransportManagerImpl.java Changeset: 74eb715474f2 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/74eb715474f2 Added tag jdk7-b144 for changeset 7033a5756ad5 ! .hgtags Changeset: 93e77c49b3bb Author: miroslawzn Date: 2011-05-26 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/93e77c49b3bb 7046882: Regression : JDK 7b123 : Enum exchanged as parameters using CORBA call results in Exception Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 643f267ca234 Author: jeff Date: 2011-05-27 14:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/643f267ca234 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 7839048ec99e Author: jeff Date: 2011-05-27 15:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/7839048ec99e Merge Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/77ec0541aa2a Merge Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags Changeset: e85ff90212ad Author: schien Date: 2011-06-08 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/e85ff90212ad Merge Changeset: 36f0efbc66ef Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/36f0efbc66ef Added tag jdk7-b146 for changeset 770227a4087e ! .hgtags Changeset: abe4723b9b7f Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/abe4723b9b7f Merge Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 73323cb33962 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/73323cb33962 Merge Changeset: 960011ba4bf2 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/960011ba4bf2 Added tag jdk7-b147 for changeset 73323cb33962 ! .hgtags Changeset: 97014e43181f Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/97014e43181f Merge From john.coomes at oracle.com Fri Jul 8 18:24:31 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Jul 2011 01:24:31 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 22 new changesets Message-ID: <20110709012431.BEEA8472D0@hg.openjdk.java.net> Changeset: 30129a58aacc Author: ohair Date: 2011-04-29 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/30129a58aacc 7040147: jaxp 1.4.5 jdk7 integration Reviewed-by: joehw ! jaxp.properties Changeset: 5598bd5ede94 Author: lana Date: 2011-04-30 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/5598bd5ede94 Merge Changeset: 9da6d4f2c640 Author: jgodinez Date: 2011-05-03 22:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/9da6d4f2c640 Merge Changeset: 7d067af4b25e Author: jgodinez Date: 2011-05-09 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7d067af4b25e Merge Changeset: 3910007a86d8 Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/3910007a86d8 Added tag jdk7-b142 for changeset 7d067af4b25e ! .hgtags Changeset: 7691aa48eba4 Author: alanb Date: 2011-05-09 01:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7691aa48eba4 Merge Changeset: 16b847e9bbd7 Author: lana Date: 2011-05-14 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/16b847e9bbd7 Merge Changeset: 39bf6dcaab23 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/39bf6dcaab23 Added tag jdk7-b143 for changeset 16b847e9bbd7 ! .hgtags Changeset: f816d9ea0b34 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/f816d9ea0b34 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: bee49f47043f Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bee49f47043f Added tag jdk7-b144 for changeset 39bf6dcaab23 ! .hgtags Changeset: bdf77cbd9958 Author: ohair Date: 2011-05-19 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bdf77cbd9958 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop Reviewed-by: joehw ! jaxp.properties Changeset: 775dd77e4730 Author: lana Date: 2011-05-20 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/775dd77e4730 Merge Changeset: a70a042c8600 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/a70a042c8600 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 10ca7570f47f Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/10ca7570f47f Merge Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags Changeset: bae5f389d17b Author: schien Date: 2011-06-08 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bae5f389d17b Merge Changeset: 9a4d09f33f01 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/9a4d09f33f01 Added tag jdk7-b146 for changeset bcd31fa1e3c6 ! .hgtags Changeset: 03692de33ca8 Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/03692de33ca8 Merge Changeset: eed2486cb10b Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/eed2486cb10b 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: fc268cd1dd5d Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/fc268cd1dd5d Merge Changeset: 6c9ac74190a0 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/6c9ac74190a0 Added tag jdk7-b147 for changeset fc268cd1dd5d ! .hgtags Changeset: 58dfc6f729e8 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/58dfc6f729e8 Merge From john.coomes at oracle.com Fri Jul 8 18:24:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Jul 2011 01:24:39 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 27 new changesets Message-ID: <20110709012439.91C6E472D1@hg.openjdk.java.net> Changeset: 7439eee6371b Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/7439eee6371b Added tag jdk7-b142 for changeset 0ef3ef823c39 ! .hgtags Changeset: 6d59d563f187 Author: ohair Date: 2011-05-10 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/6d59d563f187 7042773: Integrate JAXWS 2.2.4 update to JDK7 Reviewed-by: ramap ! jaxws.properties Changeset: 569d1e7ea980 Author: lana Date: 2011-05-14 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/569d1e7ea980 Merge Changeset: 6bd683f2d527 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/6bd683f2d527 Added tag jdk7-b143 for changeset 569d1e7ea980 ! .hgtags Changeset: b52d1b2f4a52 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/b52d1b2f4a52 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 6158298d2b94 Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/6158298d2b94 Added tag jdk7-b144 for changeset 6bd683f2d527 ! .hgtags Changeset: c902e39c384e Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c902e39c384e 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: bcca8afc019f Author: ohair Date: 2011-06-01 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/bcca8afc019f 7049699: Problem with xml/jax-ws Reviewed-by: ramap ! jaxws.properties Changeset: 42bfba80beb7 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/42bfba80beb7 Merge Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags Changeset: 1b7851b9e113 Author: schien Date: 2011-06-08 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/1b7851b9e113 Merge Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/05469dd4c366 Merge Changeset: faa394edbfe3 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/faa394edbfe3 Added tag jdk7-b146 for changeset 05469dd4c366 ! .hgtags Changeset: 9244c440c0df Author: schien Date: 2011-06-20 17:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/9244c440c0df Merge Changeset: 632e38191caa Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/632e38191caa 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d13b1f877bb5 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d13b1f877bb5 Merge Changeset: 2605f832dfbf Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/2605f832dfbf Added tag jdk7-b147 for changeset d13b1f877bb5 ! .hgtags Changeset: 47022a1b59be Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/47022a1b59be Merge From john.coomes at oracle.com Fri Jul 8 18:42:14 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Jul 2011 01:42:14 +0000 Subject: hg: hsx/hotspot-rt/langtools: 73 new changesets Message-ID: <20110709014457.DA680472D5@hg.openjdk.java.net> Changeset: 2637cf09460b Author: schien Date: 2011-04-28 17:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2637cf09460b Added tag jdk7-b140 for changeset 258e6654aba2 ! .hgtags Changeset: 90adb5d6adc7 Author: schien Date: 2011-05-02 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/90adb5d6adc7 Merge Changeset: 4c41a371aaf4 Author: schien Date: 2011-05-05 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4c41a371aaf4 Added tag jdk7-b141 for changeset 90adb5d6adc7 ! .hgtags Changeset: bbd053476ec3 Author: bpatel Date: 2011-04-18 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bbd053476ec3 6758050: javadoc handles nested generic types incorrectly Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java + test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java + test/com/sun/javadoc/testNestedGenerics/pkg/NestedGenerics.java Changeset: 671bb63f3ed5 Author: mcimadamore Date: 2011-04-19 13:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/671bb63f3ed5 7036906: Scope: CompoundScope.getElements() doesn't pass scope filter to subscopes Summary: CompoundScope.getElements() is not filtering elements according to the ScopeFilter argument Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java Changeset: fb84cfca28a1 Author: jjg Date: 2011-04-25 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fb84cfca28a1 7039019: test cannot run standalone Reviewed-by: dlsmith ! test/tools/javac/processing/model/TestSymtabItems.java Changeset: 4c5f13798b8d Author: jjg Date: 2011-04-25 15:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4c5f13798b8d 7038363: cast from object to primitive should be for source >= 1.7 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/types/CastObjectToPrimitiveTest.java + test/tools/javac/types/CastObjectToPrimitiveTest.out Changeset: a8f5cad1e6bb Author: darcy Date: 2011-04-27 17:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a8f5cad1e6bb 7039822: Project Coin: add explicit tests for the lub of an exception parameter Reviewed-by: mcimadamore, jjg + test/tools/javac/multicatch/Neg07.java + test/tools/javac/multicatch/Neg07.out + test/tools/javac/multicatch/Pos10.java Changeset: 5c81ba0eddff Author: bpatel Date: 2011-04-27 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5c81ba0eddff 7028815: Missing styles for some bulleted items in the new stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c7841bbe1227 Author: mchung Date: 2011-04-28 08:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c7841bbe1227 7037081: Remove com.sun.tracing from NON_CORE_PKGS Reviewed-by: ohair, jjg, jmasa ! src/share/classes/com/sun/tools/javac/resources/legacy.properties Changeset: 7ae6c0fd479b Author: jjg Date: 2011-04-28 15:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7ae6c0fd479b 7029150: Project Coin: present union types from the tree API through to javax.lang.model Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/multicatch/model/Model01.java ! test/tools/javac/multicatch/model/ModelChecker.java + test/tools/javac/multicatch/model/UnionTypeInfo.java + test/tools/javac/processing/model/type/TestUnionType.java Changeset: 4c03383f6529 Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4c03383f6529 7040104: javac NPE on Object a[]; Object o = (a=null)[0]; Summary: When a null literal is found on top of stack, if expected type is 1-dimension array no checkcast is emitted Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java + test/tools/javac/T7040104.java Changeset: 9a847a77205d Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9a847a77205d 7039937: Improved catch analysis fails to handle a common idiom in the libraries Summary: Disable generation of 'unreachable catch' warnings for catch statements catching Exception/Throwable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! test/tools/javac/6558548/T6558548.java ! test/tools/javac/6558548/T6558548_6.out ! test/tools/javac/6558548/T6558548_latest.out ! test/tools/javac/diags/examples/UnreachableCatch1.java Changeset: 1092b67b3cad Author: mcimadamore Date: 2011-04-29 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1092b67b3cad 7034495: Javac asserts on usage of wildcards in bounds Summary: Problem with intersection types and wildcards causing javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/wildcards/7034495/T7034495.java + test/tools/javac/generics/wildcards/7034495/T7034495.out Changeset: dc3d9ef880a1 Author: mcimadamore Date: 2011-04-29 16:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/dc3d9ef880a1 6550655: com.sun.tools.javac.code.Symbol$CompletionFailure Summary: Accessing a non-existing enum constant from an annotation whose class is available results in an internal error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/annotations/6550655/T6550655.java ! test/tools/javac/diags/examples.not-yet.txt Changeset: 4caf17560ae0 Author: mcimadamore Date: 2011-04-30 11:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4caf17560ae0 7039931: Project Coin: diamond inference fail with generic constructor explicit type-arguments Summary: diamond should be disallowed in cases where explicit generic constructor parameters are specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/DiamondAndExplicitParams.java ! test/tools/javac/generics/diamond/7030150/GenericConstructorAndDiamondTest.java - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 459854f564ed Author: lana Date: 2011-04-30 16:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/459854f564ed Merge Changeset: 62bc3775d5bb Author: bpatel Date: 2011-05-02 02:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/62bc3775d5bb 6492694: @deprecated tag doesn't work in package-info files. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testPackageDeprecation/C2.java + test/com/sun/javadoc/testPackageDeprecation/FooDepr.java + test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java + test/com/sun/javadoc/testPackageDeprecation/pkg/A.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/ClassUseTest1.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/Foo.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/Foo2.java + test/com/sun/javadoc/testPackageDeprecation/pkg1/package-info.java ! test/com/sun/javadoc/testSubTitle/TestSubTitle.java Changeset: 384ea9a98912 Author: mcimadamore Date: 2011-05-02 12:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/384ea9a98912 7040883: Compilation error: "length in Array is defined in an inaccessible class or interface" Summary: Fix of 7034511 (now backed out) is causing spurious accessibility errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/generics/7034511/T7034511a.java ! test/tools/javac/generics/7034511/T7034511b.java + test/tools/javac/generics/typevars/T7040883.java Changeset: dbc4ced9d171 Author: bpatel Date: 2011-05-02 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/dbc4ced9d171 6553182: Need to modify javadoc doclet for GPL Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/testDocRootLink/TestDocRootLink.java + test/com/sun/javadoc/testDocRootLink/pkg1/C1.java + test/com/sun/javadoc/testDocRootLink/pkg1/package.html + test/com/sun/javadoc/testDocRootLink/pkg2/C2.java + test/com/sun/javadoc/testDocRootLink/pkg2/package.html ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java Changeset: 14ff19ca715f Author: jgodinez Date: 2011-05-03 22:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/14ff19ca715f Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: b72d70f33ee4 Author: jgodinez Date: 2011-05-09 12:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b72d70f33ee4 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 66956f601f5a Author: mfang Date: 2011-05-10 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/66956f601f5a 7022005: [ja,zh_CN] javadoc, part of navigation bar in generated html are not translated. Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties Changeset: c60f85f28aa9 Author: mfang Date: 2011-05-10 15:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c60f85f28aa9 7043548: message drop 3 translation integration Reviewed-by: yhuang ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties Changeset: 7476b164194c Author: mfang Date: 2011-05-10 19:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7476b164194c Merge Changeset: 4d05949f8d6b Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4d05949f8d6b Added tag jdk7-b142 for changeset 7476b164194c ! .hgtags Changeset: c3e3945cc24f Author: alanb Date: 2011-05-09 01:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c3e3945cc24f Merge Changeset: 68fde7f5863b Author: jjg Date: 2011-05-10 19:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/68fde7f5863b 7043694: printStackTrace call should be removed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java Changeset: a2d422d480cb Author: mcimadamore Date: 2011-05-11 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a2d422d480cb 7042566: Regression: new ambiguity between varargs method Summary: Erroneous ambiguity error when choosing most specific varargs method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/7042566/T7042566.java Changeset: 95fc7fd39be2 Author: mcimadamore Date: 2011-05-11 13:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/95fc7fd39be2 7041730: Regression: compiler accepts invalid cast from int to Byte Summary: Implementation of cast conversion rules between primitive and boxed types is too liberal Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/types/BoxingConversionTest.java ! test/tools/javac/types/CastTest.java Changeset: bdfa48f80c82 Author: jjg Date: 2011-05-11 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bdfa48f80c82 7043867: docs/jdk/api/javac have html files that have issues with HTML4 compliance Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/SynchronizedTree.java Changeset: 652f0daf74a7 Author: lana Date: 2011-05-14 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/652f0daf74a7 Merge Changeset: 5faa9eedc44e Author: mcimadamore Date: 2011-05-16 09:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5faa9eedc44e 7043922: Regression: internal compiler error for nested anonymous inner class featuring varargs constructor Summary: Attributing a constructor call does not clean up the compiler's attribution context Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/varargs/7043922/T7043922.java Changeset: 8987de9a4ab8 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8987de9a4ab8 Added tag jdk7-b143 for changeset 5faa9eedc44e ! .hgtags Changeset: fdc22d73b6f3 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fdc22d73b6f3 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 8eb952f43b11 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8eb952f43b11 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/TryWithResources/DuplicateResource.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java ! test/tools/javac/api/TestClientCodeWrapper.java ! test/tools/javac/api/TestJavacTask_Lock.java ! test/tools/javac/api/TestJavacTask_Multiple.java ! test/tools/javac/api/TestJavacTask_ParseAttrGen.java ! test/tools/javac/multicatch/model/ModelChecker.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface1.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingGenericInterface2.java ! test/tools/javac/processing/model/element/TestMissingElement2/TestMissingInterface.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/tools/javac/tree/T6963934.java Changeset: 9f25c6a3ac23 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9f25c6a3ac23 Added tag jdk7-b144 for changeset 8eb952f43b11 ! .hgtags Changeset: 6bb526ccf5ff Author: mcimadamore Date: 2011-05-23 11:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6bb526ccf5ff 7046348: Regression: javac complains of missing classfile for a seemingly unrelated interface Summary: Types.implementation forces unnecessary symbol completion on superinterfaces of a given type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 6211df69f7e0 Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6211df69f7e0 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 6762754eb7c0 Author: jjg Date: 2011-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6762754eb7c0 7042623: Regression: javac silently crash when attributing non-existent annotation Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T7042623.java + test/tools/javac/T7042623.out Changeset: c455e2ae5c93 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c455e2ae5c93 Merge Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags Changeset: f27b6f45a449 Author: schien Date: 2011-06-08 10:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f27b6f45a449 Merge Changeset: 347349c981f2 Author: jjh Date: 2011-06-09 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/347349c981f2 7052782: Two langtools regression tests fail due to fix for 7034977 which removed the invokeGeneric method Summary: Change the tests to call invoke instead of invokeGeneric Reviewed-by: jrose, mcimadamore ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/XlintWarn.java Changeset: b8a2c9c87018 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b8a2c9c87018 Merge Changeset: 588d366d96df Author: asaha Date: 2011-04-21 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/588d366d96df Merge Changeset: 219b522d09e4 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/219b522d09e4 Merge Changeset: 145d832616d3 Author: asaha Date: 2011-05-05 22:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/145d832616d3 Merge Changeset: 8b6e015ae7d0 Author: asaha Date: 2011-05-24 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8b6e015ae7d0 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 35cc19ae29b5 Author: asaha Date: 2011-05-26 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/35cc19ae29b5 Merge Changeset: 8b65930602c3 Author: asaha Date: 2011-05-26 21:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8b65930602c3 Merge Changeset: 0adb806caf9d Author: asaha Date: 2011-06-06 10:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0adb806caf9d Merge Changeset: bb1fdcebde01 Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bb1fdcebde01 Merge Changeset: 8ed03b0e3c9c Author: asaha Date: 2011-06-06 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8ed03b0e3c9c Merge Changeset: f494ca4bca0d Author: lana Date: 2011-06-15 16:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f494ca4bca0d Merge Changeset: 7eba9df190ae Author: bpatel Date: 2011-06-17 20:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7eba9df190ae 7052425: Change the look and feel of the javadoc generate HTML pages using stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c3a3440fe6e8 Author: bpatel Date: 2011-06-17 20:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c3a3440fe6e8 Merge Changeset: 9425dd4f53d5 Author: schien Date: 2011-06-18 09:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9425dd4f53d5 Merge Changeset: 436fb6aeda5a Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/436fb6aeda5a Added tag jdk7-b146 for changeset 9425dd4f53d5 ! .hgtags Changeset: 06b6bbbe2787 Author: schien Date: 2011-06-20 17:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/06b6bbbe2787 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: a72412b148d7 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a72412b148d7 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 58bc532d6341 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/58bc532d6341 Merge Changeset: ce654f4ecfd8 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ce654f4ecfd8 Added tag jdk7-b147 for changeset 58bc532d6341 ! .hgtags Changeset: e0dec1645823 Author: schien Date: 2011-06-27 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e0dec1645823 Merge Changeset: defdd98cb7ce Author: darcy Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/defdd98cb7ce 7025784: Add SourceVersion.RELEASE_8 7025786: Add -source 8 and -target 8 to javac 7025789: Change javac source and target default to 8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/javax/lang/model/SourceVersion.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/quid/T6999438.java ! test/tools/javac/versions/check.sh Changeset: 3b1fd4ac2e71 Author: darcy Date: 2011-06-13 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3b1fd4ac2e71 7052122: Update JDK_MINOR_VERSION for JDK 8 Reviewed-by: mr, katleman + test/tools/javac/processing/model/TestSourceVersion.java Changeset: 4844a9fd3a62 Author: darcy Date: 2011-06-22 17:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4844a9fd3a62 6449184: Provide JavacProcessingEnvironment.getWriter Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/util/T6597678.java Changeset: 18002d039806 Author: jjg Date: 2011-06-23 11:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/18002d039806 7058174: Reduce langtools build warnings Reviewed-by: jjg Contributed-by: alexandre.boulgakov at oracle.com ! make/build.xml ! make/tools/CompileProperties/CompileProperties.java Changeset: d59414955614 Author: lana Date: 2011-06-22 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d59414955614 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: 9eb36cac6b64 Author: lana Date: 2011-06-23 17:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9eb36cac6b64 Merge Changeset: f74e4269a50a Author: darcy Date: 2011-06-24 13:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f74e4269a50a 6575445: Update annotation processor to only use java.util.ServiceLoader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt Changeset: 858ae8fec72f Author: jjg Date: 2011-06-30 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/858ae8fec72f 7060926: Attr.PostAttrAnalyzer misses a case Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/failover/FailOver15.java + test/tools/javac/failover/FailOver15.out Changeset: 469e3bec9b27 Author: lana Date: 2011-06-30 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/469e3bec9b27 Merge From john.coomes at oracle.com Fri Jul 8 18:34:41 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 09 Jul 2011 01:34:41 +0000 Subject: hg: hsx/hotspot-rt/jdk: 317 new changesets Message-ID: <20110709023101.D119C472DA@hg.openjdk.java.net> Changeset: fbe3a3401786 Author: dholmes Date: 2011-05-04 22:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fbe3a3401786 7041284: arm/ppc Missing launcher mapfiles prevent build Summary: Disable use of launcher mapfiles when cross-compiling Reviewed-by: ohair, ksrini ! make/common/Program.gmk Changeset: 28c1be91a39f Author: cl Date: 2011-05-05 18:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/28c1be91a39f 7026163: gzip tar files Reviewed-by: katleman ! make/common/shared/Defs-utils.gmk Changeset: 8e9e28663c5d Author: andrew Date: 2011-05-06 01:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8e9e28663c5d 7042040: Remove disk space sanity check Summary: Remove outdated disk space checks using df Reviewed-by: ohair, omajid ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: 87488f98e22d Author: andrew Date: 2011-05-06 02:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/87488f98e22d Merge Changeset: ce34293145b1 Author: cl Date: 2011-05-06 10:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ce34293145b1 Merge Changeset: d9571c986c73 Author: jgodinez Date: 2011-04-20 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d9571c986c73 6989724: font warnings in the build, native code Reviewed-by: bae, igor ! src/share/native/sun/awt/giflib/dgif_lib.c ! src/share/native/sun/font/fontscalerdefs.h ! src/share/native/sun/font/layout/HangulLayoutEngine.cpp ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/solaris/native/sun/awt/fontpath.c ! src/windows/native/sun/font/fontpath.c Changeset: 0f98d7d98c9f Author: prr Date: 2011-04-22 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0f98d7d98c9f 7031011: fallbackfont testing failed on OEL 6. Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: a07c9e09b4ca Author: bae Date: 2011-04-27 12:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a07c9e09b4ca 7037091: sun/java2d/pipe/Test7027667.java test is not executed Reviewed-by: prr ! test/sun/java2d/pipe/Test7027667.java Changeset: 24f474ad1703 Author: dlila Date: 2011-04-28 08:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/24f474ad1703 7036754: NaNs in stroked quadratics. Summary: Check for them and remove them. Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Stroker.java + test/sun/java2d/pisces/Test7036754.java Changeset: 34056b127c96 Author: flar Date: 2011-04-29 01:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/34056b127c96 7020955: No focus point adjustment for RadialGradientPaint Reviewed-by: prr ! src/share/classes/java/awt/RadialGradientPaint.java Changeset: 899d87ec43eb Author: flar Date: 2011-04-29 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/899d87ec43eb 6522514: Extending Arc2D.Double and serializing the object causes InvalidClassException Reviewed-by: prr ! src/share/classes/java/awt/geom/Arc2D.java Changeset: 678ce376be35 Author: lana Date: 2011-04-28 17:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/678ce376be35 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 3b536b18a6f0 Author: lana Date: 2011-04-29 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3b536b18a6f0 Merge Changeset: c5209316e1ab Author: flar Date: 2011-04-29 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c5209316e1ab 6982632: closed/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java fails Reviewed-by: prr + test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java Changeset: 55ef0efa2b14 Author: flar Date: 2011-05-02 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/55ef0efa2b14 6563734: Path2D.Float and Path2D.Double should have final getPathIterator methods Reviewed-by: prr ! src/share/classes/java/awt/geom/Path2D.java Changeset: 499d216a751e Author: jgodinez Date: 2011-05-03 22:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/499d216a751e Merge Changeset: f805a139c57c Author: anthony Date: 2011-04-19 14:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f805a139c57c 7036669: Simplify revalidating component hierarchy with multiple validate roots Summary: Introduce Component.revalidate() method Reviewed-by: art, alexp ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java + test/java/awt/Component/Revalidate/Revalidate.java Changeset: c292ec06529f Author: dav Date: 2011-04-19 18:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c292ec06529f 7036733: Regression : NullPointerException when scrolling horizontally on AWT List Reviewed-by: dcherepanov ! src/solaris/classes/sun/awt/X11/XListPeer.java + test/java/awt/List/ScrollOutside/ScrollOut.java Changeset: c9ddd8e0af54 Author: dav Date: 2011-04-25 21:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c9ddd8e0af54 7030632: Pasting HTML that was copied from MS Word results in IOException Reviewed-by: uta, denis ! src/windows/classes/sun/awt/windows/WDataTransferer.java Changeset: 673aa770a062 Author: denis Date: 2011-04-25 20:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/673aa770a062 6888182: Readable and permitted to delete files could not be transferred through Clipboard and DnD Reviewed-by: uta ! src/windows/native/sun/windows/awt_Clipboard.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp Changeset: 16f52939fa41 Author: denis Date: 2011-04-27 14:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/16f52939fa41 7020922: java.awt.Toolkit.getPropertyChangeListeners() should mention that it returns proxies Reviewed-by: malenkov ! src/share/classes/java/awt/Toolkit.java Changeset: 4c9ea1bf528a Author: denis Date: 2011-04-27 17:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4c9ea1bf528a 6998716: client vm crashes making browser fails to respond under some scenarios Reviewed-by: art, denis, uta ! src/windows/native/sun/windows/ObjectList.cpp ! src/windows/native/sun/windows/ObjectList.h ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Object.h ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awtmsg.h Changeset: 03d764676479 Author: dcherepanov Date: 2011-04-28 13:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/03d764676479 7032830: GraphicsDevice.setFullScreenWindow() works strange for decorated windows on OEL. 7016382: GraphicsDevice.setFullScreenWindow() - spec clarification for exclusive mode for dec/undec Frames Reviewed-by: art ! src/share/classes/java/awt/GraphicsDevice.java Changeset: b1567059e4fe Author: dav Date: 2011-04-28 20:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b1567059e4fe 6956646: Test: MouseWheelEvent/InfiniteRecursion test receives more MouseWheelEvents than expected Reviewed-by: serb, dcherepanov ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_1.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_4.java Changeset: 5b001da8768e Author: dcherepanov Date: 2011-04-28 19:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5b001da8768e 6853146: Regression: on-the-spot input is broken in AWT Peered components Reviewed-by: art, ant, naoto ! src/windows/native/sun/windows/awt_TextComponent.cpp Changeset: 43be19b7c945 Author: dcherepanov Date: 2011-04-28 19:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/43be19b7c945 7034766: closed/java/awt/EmbeddedFrame/EmbeddedFrameGrabTest/EmbeddedFrameGrabTest.java failed on jdk7 b134 Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Frame.cpp Changeset: 6303d3a93040 Author: dcherepanov Date: 2011-04-29 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6303d3a93040 7034291: Regression : Preedit String on active client is committed into unexpected component Reviewed-by: art, naoto ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h Changeset: 5d8445b532a7 Author: dcherepanov Date: 2011-04-29 16:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5d8445b532a7 7026055: Regression : Cannot use IME on JComboBox Japanese Reviewed-by: art, ant, naoto ! src/windows/native/sun/windows/awt_Component.cpp Changeset: 32488e6d3917 Author: lana Date: 2011-04-29 20:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/32488e6d3917 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java - src/share/native/sun/font/layout/Features.h - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: d400711b8cd2 Author: serb Date: 2011-05-03 15:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d400711b8cd2 7016528: Deadlock during mutual initialization of DataTransferer and DataTransferer$DataFlavorComparator Reviewed-by: dav, art, denis ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: 4e6897c7779f Author: jgodinez Date: 2011-05-03 22:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4e6897c7779f Merge Changeset: 4719cf8f5ae5 Author: rupashka Date: 2011-04-19 10:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4719cf8f5ae5 7036025: java.security.AccessControlException when creating JFileChooser in signed applet Reviewed-by: malenkov ! src/share/classes/sun/swing/WindowsPlacesBar.java + test/javax/swing/JFileChooser/7036025/bug7036025.java + test/javax/swing/JFileChooser/7036025/security.policy Changeset: ea0aed4b75cd Author: amenkov Date: 2011-04-20 16:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ea0aed4b75cd 7030629: closed/sun/audio/AudioClipClose/AudioClipClose.java test fails just against jdk7 b134 7033899: SoundTestSuite: test050 fails on Ubuntu Linux Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c Changeset: 6c94f33c36d5 Author: rupashka Date: 2011-04-21 14:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c94f33c36d5 7021058: The Create folder button produces error in the Details mode (JFileChooser) Reviewed-by: malenkov ! src/share/classes/sun/swing/FilePane.java Changeset: 91a590306e02 Author: alexp Date: 2011-04-22 20:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/91a590306e02 7036871: Some JCK interactive JSplitPane tests that test continuous layout fail with Nimbus L&F Reviewed-by: rupashka ! src/share/classes/javax/swing/JSplitPane.java Changeset: 78890acd99e4 Author: peytoia Date: 2011-04-26 10:46 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/78890acd99e4 7039469: (tz) Support tzdata2011g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/southamerica Changeset: 1be42326f1c2 Author: rupashka Date: 2011-04-27 13:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1be42326f1c2 7039403: Could not compile test/javax/swing/JLabel/6596966/bug6596966.java Reviewed-by: malenkov ! test/javax/swing/JLabel/6596966/bug6596966.java Changeset: 0896c9712cf0 Author: bagiras Date: 2011-04-27 15:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0896c9712cf0 7035209: 6u26 ea b01 - running an applet with old plugin crashes in awt.dll Reviewed-by: art, amenkov ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp Changeset: 1eaff0300541 Author: dav Date: 2011-04-27 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1eaff0300541 6888633: test/closed/javax/swing/JPopupMenu/4786415/bug4786415.java fails Reviewed-by: rupashka, alexp ! src/share/classes/javax/swing/JPopupMenu.java Changeset: 015a66da6fcc Author: dav Date: 2011-04-27 18:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/015a66da6fcc 6979551: closed/javax/swing/plaf/basic/BasicLabelUI/4798542/bug4798542.java fails Reviewed-by: art, yan, alexp ! src/share/classes/sun/awt/ExtendedKeyCodes.java + test/java/awt/keyboard/EqualKeyCode/EqualKeyCode.java Changeset: bb6594674ffe Author: lana Date: 2011-04-29 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bb6594674ffe Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java - src/share/native/sun/font/layout/Features.h Changeset: fd428801c7ba Author: jgodinez Date: 2011-05-03 22:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fd428801c7ba Merge Changeset: e9760efb5110 Author: sherman Date: 2011-04-18 21:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e9760efb5110 7027900: (fs) glob syntax under-specified Summary: Clarify how leading dots are treated in nio2 glob Reviewed-by: alanb ! src/share/classes/java/nio/file/FileSystem.java Changeset: 495dcc360214 Author: mduigou Date: 2011-04-19 10:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/495dcc360214 7030579: Extra words in documentation of ListIterator may cause confusion Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ListIterator.java Changeset: f8956ba13b37 Author: weijun Date: 2011-04-20 18:41 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f8956ba13b37 6894072: always refresh keytab Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java + src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KerberosKey.java + src/share/classes/javax/security/auth/kerberos/KeyTab.java + src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/KeyTabCompat.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/auto/SSL.java + test/sun/security/krb5/auto/TwoPrinces.java ! test/sun/security/krb5/ktab/KeyTabIndex.java Changeset: ed01737a2e9a Author: michaelm Date: 2011-04-20 12:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ed01737a2e9a 7034570: java.lang.Runtime.exec(String[] cmd, String[] env) can not work properly if SystemRoot not inherited Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: 31aa8c35a4df Author: michaelm Date: 2011-04-20 12:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31aa8c35a4df Merge Changeset: 00f3997e6aeb Author: smarks Date: 2011-04-20 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/00f3997e6aeb 6896297: (rmi) fix ConcurrentModificationException causing TCK failure Reviewed-by: alanb, dholmes, peterjones ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/server/Activation.java Changeset: d5a7ed4e72a4 Author: mduigou Date: 2011-04-20 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d5a7ed4e72a4 6546713: link the word (optional) in exception specifications to the text which provides explanation and context. Reviewed-by: dholmes, dl ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/Vector.java Changeset: 7fd31e477313 Author: dl Date: 2011-04-21 13:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7fd31e477313 7038501: Clarify meaning of "(optional)" in javadoc Reviewed-by: chegar ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java Changeset: 7cd0403492b6 Author: vinnie Date: 2011-04-21 14:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7cd0403492b6 6888925: SunMSCAPI's Cipher can't use RSA public keys obtained from other sources. Reviewed-by: mullan ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/PublicKeyInterop.java + test/sun/security/mscapi/PublicKeyInterop.sh Changeset: 401ef8c488e0 Author: vinnie Date: 2011-04-21 14:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/401ef8c488e0 Merge Changeset: e9ec52c63a9f Author: dl Date: 2011-04-21 17:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e9ec52c63a9f 7038542: Small performace regression in ConcurrentHashMap on c1 since CR 703655 Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: 69fead598c1b Author: vinnie Date: 2011-04-21 19:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/69fead598c1b 6732372: Some MSCAPI native methods not returning correct exceptions. Reviewed-by: mullan ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/windows/classes/sun/security/mscapi/KeyStore.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java ! src/windows/classes/sun/security/mscapi/RSAPublicKey.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/native/sun/security/mscapi/security.cpp Changeset: ca4f216c0bae Author: lana Date: 2011-04-21 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ca4f216c0bae Merge Changeset: 3669d17e7799 Author: lana Date: 2011-04-21 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3669d17e7799 Merge Changeset: 2c46bf0a462c Author: mullan Date: 2011-04-21 17:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c46bf0a462c 7038175: Expired PKITS certificates causing CertPathBuilder and CertPathValidator regression test failures Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java Changeset: 34b2c8e0ac85 Author: mullan Date: 2011-04-21 17:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/34b2c8e0ac85 Merge Changeset: a5bb55c7cfde Author: darcy Date: 2011-04-21 15:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a5bb55c7cfde 6998871: Support making the Throwable.stackTrace field immutable Reviewed-by: dholmes, mchung, forax ! src/share/classes/java/lang/ArithmeticException.java ! src/share/classes/java/lang/Error.java ! src/share/classes/java/lang/Exception.java ! src/share/classes/java/lang/NullPointerException.java ! src/share/classes/java/lang/OutOfMemoryError.java ! src/share/classes/java/lang/RuntimeException.java ! src/share/classes/java/lang/Throwable.java ! src/share/native/java/lang/Throwable.c ! test/java/lang/Throwable/ChainedExceptions.java ! test/java/lang/Throwable/StackTraceSerialization.java ! test/java/lang/Throwable/SuppressedExceptions.java Changeset: 48f659a09ed4 Author: coffeys Date: 2011-04-22 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/48f659a09ed4 7025227: SSLSocketImpl does not close the TCP layer socket if a close notify cannot be sent to the peer 6932403: SSLSocketImpl state issue Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 7c1cdb9c81a6 Author: dl Date: 2011-04-22 16:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c1cdb9c81a6 7038885: Improved bulk operation disclaimers for concurrent collections Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java Changeset: 7cd61feb3ec6 Author: kamg Date: 2011-04-15 10:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7cd61feb3ec6 6519228: JDWP Spec: need references at capability canRequestMonitorEvents for JDWP 1.6 Monitor* events Summary: Add descriptions in event type table Reviewed-by: ohair, jjh, acorn, dcubed ! make/jpda/jdwp/jdwp.spec Changeset: e56922f50d1c Author: kamg Date: 2011-04-22 04:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e56922f50d1c Merge Changeset: 9cc0045191ed Author: kamg Date: 2011-04-22 08:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9cc0045191ed Merge Changeset: d64f9348c7ca Author: vinnie Date: 2011-04-22 17:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d64f9348c7ca 6931562: Support SunMSCAPI Security Provider in Windows 64-bit releases of JVM Reviewed-by: mullan ! make/java/security/Makefile ! make/sun/security/Makefile ! test/sun/security/mscapi/AccessKeyStore.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/mscapi/KeyStoreCompatibilityMode.sh ! test/sun/security/mscapi/KeytoolChangeAlias.sh ! test/sun/security/mscapi/RSAEncryptDecrypt.sh Changeset: 8b36b1c4bb7f Author: nloodin Date: 2011-04-26 12:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8b36b1c4bb7f 7029383: Refresh of non-client demos Reviewed-by: mchung, ohair ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java Changeset: 147da2c8b749 Author: darcy Date: 2011-04-26 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/147da2c8b749 7039369: Limit range of strictfp in FloatingDecimal Summary: Additional reviews by sergey.kuksenko at oracle.com Reviewed-by: alanb ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! test/java/lang/Double/ParseDouble.java Changeset: 0e0db3421e8f Author: weijun Date: 2011-04-27 17:11 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0e0db3421e8f 6950929: Failures on Solaris sparc 64bit sun/security/krb5/auto/BadKdc4.java (and linux?) Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java Changeset: a0dde3ff1dfd Author: alanb Date: 2011-04-27 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a0dde3ff1dfd 7039186: (ch) EPoll based asynchronous I/O implementation should be portable to linux-arm and linux-ppc Reviewed-by: dholmes ! make/java/nio/mapfile-linux ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c Changeset: 5a4e2a734f1d Author: vinnie Date: 2011-04-27 20:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5a4e2a734f1d 6753664: Support SHA256 (and higher) in SunMSCAPI Reviewed-by: mullan ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/windows/native/sun/security/mscapi/security.cpp + test/sun/security/mscapi/SignUsingSHA2withRSA.java + test/sun/security/mscapi/SignUsingSHA2withRSA.sh Changeset: 7c109d060365 Author: vinnie Date: 2011-04-27 20:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c109d060365 Merge Changeset: 5b05f8d1c0e5 Author: mduigou Date: 2011-04-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5b05f8d1c0e5 4884238: Adds java.nio.charset.StandardCharset to provide static final constants for the standard charsets. Reviewed-by: alanb, sherman, darcy ! src/share/classes/java/nio/charset/Charset.java + src/share/classes/java/nio/charset/StandardCharset.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/awt/FontDescriptor.java + test/java/nio/charset/StandardCharset/Standard.java Changeset: bf2a12c1ffe3 Author: mduigou Date: 2011-04-27 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bf2a12c1ffe3 Merge Changeset: 76703c84b3a2 Author: weijun Date: 2011-04-28 20:34 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76703c84b3a2 7037201: regression: invalid signed jar file not detected Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarInputStream.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs/SignerInfo.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java - src/share/classes/sun/security/util/SignatureFileManifest.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/java/util/jar/JarInputStream/ScanSignedJar.java ! test/java/util/jar/JarInputStream/TestIndexedJarWithBadSignature.java Changeset: 28caa191884a Author: lancea Date: 2011-04-28 09:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/28caa191884a 7038565: address Findbugs issue in BatchUpdateException Reviewed-by: alanb, forax ! src/share/classes/java/sql/BatchUpdateException.java Changeset: c3f5333e10e3 Author: mchung Date: 2011-04-28 08:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c3f5333e10e3 7037081: Remove com.sun.tracing from NON_CORE_PKGS Reviewed-by: ohair, jjg, jmasa ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk Changeset: 37722a0a1c65 Author: mduigou Date: 2011-04-28 10:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/37722a0a1c65 7040381: Add StandardCharset.java to FILES_java.gmk Reviewed-by: alanb ! make/java/nio/FILES_java.gmk Changeset: 7b7c1ffd0752 Author: mduigou Date: 2011-04-28 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7b7c1ffd0752 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 67f411052dd6 Author: vinnie Date: 2011-04-29 00:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/67f411052dd6 6578658: Request for raw RSA (NONEwithRSA) Signature support in SunMSCAPI Reviewed-by: wetmore ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! src/windows/native/sun/security/mscapi/security.cpp + test/sun/security/mscapi/SignUsingNONEwithRSA.java + test/sun/security/mscapi/SignUsingNONEwithRSA.sh Changeset: 6c8ae62463a3 Author: darcy Date: 2011-04-28 17:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c8ae62463a3 7038843: IIOP serialization fails with NullPointerException when serializing Throwable Reviewed-by: dholmes, mchung ! src/share/classes/java/lang/Throwable.java Changeset: 775b77e74bec Author: sherman Date: 2011-04-28 20:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/775b77e74bec 7037261: j.l.Character.isLowerCase/isUpperCase need to match the Unicode Standard Summary: updated j.l.c.lsLowerCase/isUpperCase Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/tools/GenerateCharacter/CharacterData00.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/GenerateCharacter/CharacterData02.java.template ! make/tools/GenerateCharacter/CharacterData0E.java.template ! make/tools/GenerateCharacter/CharacterDataLatin1.java.template + make/tools/UnicodeData/PropList.txt ! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java + make/tools/src/build/tools/generatecharacter/PropList.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterData.java + test/java/lang/Character/CheckProp.java + test/java/lang/Character/PropList.txt Changeset: 94d02b3c5ac4 Author: sherman Date: 2011-04-28 20:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/94d02b3c5ac4 7039066: j.u.rgex does not match TR18 RL1.4 Simple Word Boundaries and RL1.2 Properties Summary: updated the regex Unicode property support Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + src/share/classes/java/util/regex/UnicodeProp.java + test/java/util/regex/POSIX_ASCII.java + test/java/util/regex/POSIX_Unicode.java ! test/java/util/regex/RegExTest.java Changeset: 0b1354ecf5a3 Author: lancea Date: 2011-04-29 09:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0b1354ecf5a3 7040150: Indexing Error in CachedRowSetImpl.removeCurrentRow Reviewed-by: smarks ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java Changeset: 24ad188dc46c Author: mchung Date: 2011-04-29 08:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/24ad188dc46c 7039809: Remove @ConstructorProperties annotation from java.io.File class Reviewed-by: alanb, malenkov ! src/share/classes/java/io/File.java - test/java/beans/XMLEncoder/java_io_File.java Changeset: 40e2b3a25533 Author: valeriep Date: 2011-04-29 13:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/40e2b3a25533 7036252: sunpkcs11-solaris.cfg needs a review Summary: Updated the disabled mechanisms section since Solaris bug 6306708 has been fixed. Reviewed-by: mullan ! src/share/lib/security/sunpkcs11-solaris.cfg Changeset: 36dd30b5f85d Author: mduigou Date: 2011-04-29 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/36dd30b5f85d 7040572: Fix broken java/nio/charset/StandardCharset/Standard.java and add more tests. Reviewed-by: alanb ! test/java/nio/charset/StandardCharset/Standard.java Changeset: ca58907a51f7 Author: lana Date: 2011-04-30 16:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ca58907a51f7 Merge ! make/java/java/FILES_java.gmk - src/share/native/sun/font/layout/Features.h - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: aa7c361144bb Author: weijun Date: 2011-05-01 14:22 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/aa7c361144bb 7040916: DynamicKeyTab test fails on Windows Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/DynamicKeytab.java Changeset: 4ac05b50f09c Author: sherman Date: 2011-05-01 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ac05b50f09c 7036522: j.u.r.Pattern documentation errors Summary: updated the Perl related information Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java Changeset: 94551cf150a1 Author: michaelm Date: 2011-05-02 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/94551cf150a1 6569621: Problem with java/classes_net Reviewed-by: chegar ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: aee65a629245 Author: michaelm Date: 2011-05-02 11:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/aee65a629245 Merge Changeset: c678b0cf5f92 Author: bpatel Date: 2011-05-02 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c678b0cf5f92 6553182: Need to modify javadoc doclet for GPL Reviewed-by: jjg ! make/docs/Makefile Changeset: fa17f2b9a6d5 Author: sherman Date: 2011-05-02 11:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fa17f2b9a6d5 7040220: java/char_encodin Optimize UTF-8 charset for String.getBytes()/new String(byte[]) Summary: implement sun.nio.cs.ArrayEn/Decoer in utf8 Reviewed-by: alanb ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/sun/nio/cs/UTF_8.java + test/sun/nio/cs/StrCodingBenchmarkUTF8.java ! test/sun/nio/cs/TestStringCoding.java + test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java Changeset: bd1ffb167be0 Author: darcy Date: 2011-05-02 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bd1ffb167be0 7041136: Use Objects.equals in JDK platform classes Reviewed-by: alanb, mduigou ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/net/HttpCookie.java Changeset: d08d77ad2d7b Author: weijun Date: 2011-05-03 02:48 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d08d77ad2d7b 7040151: SPNEGO GSS code does not parse tokens in accordance to RFC 2478 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/spnego/NegTokenInit.java ! src/share/classes/sun/security/jgss/spnego/NegTokenTarg.java ! src/share/classes/sun/security/jgss/spnego/SpNegoToken.java + test/sun/security/jgss/spnego/NegTokenTargFields.java + test/sun/security/krb5/auto/SPNEGO.java Changeset: 60b4039f60f9 Author: michaelm Date: 2011-05-02 20:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60b4039f60f9 7041044: InetAddress.getByName(String,InetAddress) added in error Reviewed-by: alanb ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: 36724da65fef Author: michaelm Date: 2011-05-02 20:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/36724da65fef Merge Changeset: 827b4bb47da7 Author: jgodinez Date: 2011-05-03 22:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/827b4bb47da7 Merge - test/java/beans/XMLEncoder/java_io_File.java Changeset: 10f6986c84ad Author: jgodinez Date: 2011-05-09 12:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/10f6986c84ad Merge - test/java/beans/XMLEncoder/java_io_File.java Changeset: 32f53b3cbc65 Author: asaha Date: 2011-05-04 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/32f53b3cbc65 7035172: Reintroduce LICENSE file in JDK/JRE bundle Reviewed-by: billyh ! make/common/Release.gmk Changeset: 1eb466ffaccf Author: cgruszka Date: 2011-05-10 17:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1eb466ffaccf Merge ! make/common/Release.gmk Changeset: 89d3aea9daf2 Author: vinnie Date: 2011-05-04 20:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/89d3aea9daf2 6738532: Error in Elliptic Curve NamedCurve determination. (related to PKCS11) Reviewed-by: valeriep ! src/share/classes/java/security/spec/EllipticCurve.java + test/java/security/spec/EllipticCurveMatch.java Changeset: ec6e2b13330f Author: ngthomas Date: 2011-05-10 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ec6e2b13330f Merge - test/java/beans/XMLEncoder/java_io_File.java Changeset: 25b72781083c Author: ngthomas Date: 2011-05-10 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/25b72781083c Merge Changeset: 0f4a9ce78cf9 Author: trims Date: 2011-05-10 18:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0f4a9ce78cf9 Merge Changeset: 7d36a6a37251 Author: ohair Date: 2011-05-05 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7d36a6a37251 Merge Changeset: 7bb810bddddd Author: ohair Date: 2011-05-06 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7bb810bddddd Merge Changeset: 62e8094052eb Author: ohair Date: 2011-05-06 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/62e8094052eb Merge Changeset: 69a4dd09ba46 Author: ohair Date: 2011-05-10 17:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/69a4dd09ba46 Merge Changeset: a8e0571232c4 Author: mfang Date: 2011-05-06 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a8e0571232c4 7021691: Most log level words are not translated in java logging Reviewed-by: yhuang ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties Changeset: 481e358abc98 Author: mfang Date: 2011-05-10 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/481e358abc98 7043580: integrate man page translation drop 2 into jdk7 Reviewed-by: yhuang ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/jvisualvm.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/jvisualvm.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 Changeset: 357395bc17ab Author: mfang Date: 2011-05-10 13:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/357395bc17ab 7042323: [sv, de, es, it] Print dialog has duplicate mnemonic key Reviewed-by: yhuang ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties Changeset: 98292f06cd7e Author: mfang Date: 2011-05-10 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/98292f06cd7e 7028447: security-related resources Chinese translation errors Reviewed-by: weijun ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_CN.java Changeset: 2dd7fb82f40e Author: mfang Date: 2011-05-10 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2dd7fb82f40e 7042475: [ja,zh_CN] extra mnemonic key in jconsole Reviewed-by: yhuang ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: 3d39f994d6ff Author: mfang Date: 2011-05-10 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3d39f994d6ff 7038807: [CCJK] OK button on message dialog of JOptionpane is not translated Reviewed-by: yhuang ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties Changeset: be418afb1b2e Author: mfang Date: 2011-05-10 16:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/be418afb1b2e 7043548: message drop 3 translation integration Reviewed-by: yhuang ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/sun/awt/resources/awt_es.properties ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_TW.java Changeset: 78f2f50bca1f Author: mfang Date: 2011-05-10 19:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/78f2f50bca1f Merge Changeset: 42c22d5a2cd0 Author: bpatel Date: 2011-05-11 08:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/42c22d5a2cd0 7043684: Update man pages for JDK 7 tools Reviewed-by: skannan ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 + src/linux/doc/man/jvisualvm.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 + src/solaris/doc/sun/man/man1/jvisualvm.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: 245d9754f487 Author: mfang Date: 2011-05-11 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/245d9754f487 7004603: L10n needed for newly added codes in LocaleNames Reviewed-by: naoto ! src/share/classes/sun/util/resources/LocaleNames_de.properties ! src/share/classes/sun/util/resources/LocaleNames_es.properties ! src/share/classes/sun/util/resources/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/LocaleNames_it.properties ! src/share/classes/sun/util/resources/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties Changeset: 2bbb5d2b419f Author: mfang Date: 2011-05-11 12:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2bbb5d2b419f Merge Changeset: caed82420c5d Author: mfang Date: 2011-05-11 14:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/caed82420c5d 7044019: LocaleEnhanceTest.java needs to be updated for 7004603 Reviewed-by: naoto ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 312612e89ece Author: schien Date: 2011-05-11 18:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/312612e89ece Merge Changeset: 2e430b88b949 Author: schien Date: 2011-05-12 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2e430b88b949 Added tag jdk7-b142 for changeset 312612e89ece ! .hgtags Changeset: 21cd37d96098 Author: trims Date: 2011-05-17 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/21cd37d96098 Merge Changeset: 13fa9a0c628f Author: ohair Date: 2011-05-12 07:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/13fa9a0c628f 7043921: generate java-rmi.cgi on 64 bit platform Reviewed-by: omajid, katleman ! make/sun/rmi/rmi/Makefile Changeset: cb71f8f695f5 Author: ohair Date: 2011-05-12 07:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cb71f8f695f5 Merge Changeset: d2c99ad6ab55 Author: ohair Date: 2011-05-12 17:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d2c99ad6ab55 Merge Changeset: 1be8850c7005 Author: schien Date: 2011-05-18 16:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1be8850c7005 Merge Changeset: 85f53467c30c Author: flar Date: 2011-05-10 15:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/85f53467c30c 7040717: Test case for 6522514 was not included in bug fix Reviewed-by: prr + test/java/awt/geom/Arc2D/SerializationTest.java Changeset: f290441b0cb7 Author: flar Date: 2011-05-11 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f290441b0cb7 7043054: REGRESSION: JDK 7 b126 : Wrong userBounds in Paint.createContext() Reviewed-by: prr ! src/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java ! src/windows/classes/sun/java2d/d3d/D3DRenderer.java + test/java/awt/Paint/PgramUserBoundsTest.java Changeset: 43e54e60d261 Author: lana Date: 2011-05-14 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/43e54e60d261 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java - test/java/beans/XMLEncoder/java_io_File.java Changeset: 59aadf63f2a7 Author: prr Date: 2011-05-16 15:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/59aadf63f2a7 7044682: Image I/O JPEG Metadata spec. should document that PhotoYCC ColorSpace interpretation is optional. Reviewed-by: flar ! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html Changeset: 1b154e3ab359 Author: dav Date: 2011-05-04 14:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1b154e3ab359 7040577: Default implementation of Toolkit.loadSystemColors(int[]) and many others doesn't throw HE in hl env Reviewed-by: dcherepanov, denis ! src/share/classes/java/awt/Toolkit.java + test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java Changeset: 997f464f8446 Author: bagiras Date: 2011-05-10 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/997f464f8446 7035053: java/awt/event/MouseWheelEvent/DisabledComponent/DisabledComponent.java fails against jdk7 b134 Reviewed-by: art, denis, ant, dcherepanov ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Frame.cpp Changeset: dde5cc0d768c Author: anthony Date: 2011-05-10 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dde5cc0d768c 7041387: Introduce new boolean system property java.awt.smartInvalidate Summary: The behavior introduced with 6852592 is now enabled by the new system property only Reviewed-by: dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! test/java/awt/Component/Revalidate/Revalidate.java ! test/java/awt/Container/ValidateRoot/InvalidateMustRespectValidateRoots.java Changeset: bcc961336f77 Author: dav Date: 2011-05-11 15:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bcc961336f77 7042429: jdk 7 b140: crashes in awt.dll+0xb85fb] Java_sun_awt_Win32GraphicsEnvironment_isVistaOS+0xfdf Reviewed-by: bae, dcherepanov ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/Devices.h Changeset: 4a5bb1f16cb4 Author: anthony Date: 2011-05-11 17:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4a5bb1f16cb4 7043455: Taking a screenshot may fail on X11 after 6903034 Summary: Backout 6903034 Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 84ad07aece8c Author: dav Date: 2011-05-13 19:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/84ad07aece8c 7042537: When press the 'Print' button,the NullPointerException is thrown and printdialog is not pop up. Reviewed-by: dcherepanov, art ! src/share/classes/java/awt/Toolkit.java Changeset: 368e1da134aa Author: lana Date: 2011-05-14 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/368e1da134aa Merge - src/share/classes/sun/security/util/SignatureFileManifest.java ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp - test/java/beans/XMLEncoder/java_io_File.java Changeset: 0b7f41c14605 Author: dcherepanov Date: 2011-05-16 18:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0b7f41c14605 7010721: Frame#setMaximizedbounds not working properly on dual screen environment Reviewed-by: art, anthony ! src/windows/classes/sun/awt/windows/WFramePeer.java Changeset: 52a9555dbbb1 Author: lana Date: 2011-05-16 18:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/52a9555dbbb1 Merge Changeset: ea6bd2607399 Author: rupashka Date: 2011-05-04 10:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ea6bd2607399 7031551: Generics: JComboBox Reviewed-by: alexp, malenkov ! src/share/classes/javax/swing/ComboBoxModel.java ! src/share/classes/javax/swing/DefaultComboBoxModel.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/MutableComboBoxModel.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java + test/javax/swing/JComboBox/7031551/bug7031551.java Changeset: adbbfd2e661c Author: dav Date: 2011-05-06 16:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/adbbfd2e661c 6894541: javax/swing/JTable/6788484/bug6788484.java fails w/ compilation errors. Reviewed-by: alexp ! test/javax/swing/JTable/6788484/bug6788484.java Changeset: 523ad3855e03 Author: kizune Date: 2011-05-10 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/523ad3855e03 7034619: Scrollable Tabs don't appear with JDK7 Synth based LaF, different from Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: e122346f8e2d Author: peytoia Date: 2011-05-11 08:02 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e122346f8e2d 7041232: IllegalArgumentException in sun.text.bidi.BidiBase.setLine starting from JDK 7 b64 Reviewed-by: okutsu ! src/share/classes/sun/text/bidi/BidiBase.java + test/java/text/Bidi/Bug7041232.java Changeset: 5030057f8b4c Author: lana Date: 2011-05-14 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5030057f8b4c Merge - src/share/classes/sun/security/util/SignatureFileManifest.java - test/java/beans/XMLEncoder/java_io_File.java Changeset: 2a580e14e428 Author: lana Date: 2011-05-16 18:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2a580e14e428 Merge Changeset: 85cbf90d88b9 Author: darcy Date: 2011-05-06 17:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/85cbf90d88b9 7011326: Add informative example to @SafeVarargs type or language discussion Reviewed-by: mcimadamore, mduigou ! src/share/classes/java/lang/SafeVarargs.java Changeset: d93f6b6b986b Author: alanb Date: 2011-05-09 01:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d93f6b6b986b Merge Changeset: dfe56edc1a1d Author: alanb Date: 2011-05-09 01:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dfe56edc1a1d Merge Changeset: 31fbed875a6b Author: vinnie Date: 2011-05-09 15:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31fbed875a6b 6987652: VM crashed in sun.security.mscapi.RSAKeyPairGenerator.generateRSAKeyPair(...) Reviewed-by: alanb ! src/windows/native/sun/security/mscapi/security.cpp Changeset: c6742d21853b Author: dl Date: 2011-05-09 16:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c6742d21853b 7042673: LockSupport.getBlocker(null) crashes Reviewed-by: chegar ! src/share/classes/java/util/concurrent/locks/LockSupport.java Changeset: 7c9780ea0c5a Author: mduigou Date: 2011-05-03 16:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c9780ea0c5a 7041612: Rename StandardCharset to StandardCharsets Reviewed-by: alanb, mr, darcy ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/charset/Charset.java - src/share/classes/java/nio/charset/StandardCharset.java + src/share/classes/java/nio/charset/StandardCharsets.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/awt/FontDescriptor.java Changeset: 5dceeea3bb99 Author: mduigou Date: 2011-05-09 08:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5dceeea3bb99 Merge Changeset: bd8c10d1db87 Author: mduigou Date: 2011-05-09 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bd8c10d1db87 7043104: disable test java/lang/invoke/InvokeDynamicPrintArgs.java Reviewed-by: alanb ! test/ProblemList.txt Changeset: dc497a55daa1 Author: alanb Date: 2011-05-09 18:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dc497a55daa1 7042979: Rename StandardSocketOption and StandardWatchEventKind Reviewed-by: forax, chegar ! make/com/sun/nio/sctp/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java - src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java + src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/java/net/SocketOption.java - src/share/classes/java/net/StandardSocketOption.java + src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/file/Path.java - src/share/classes/java/nio/file/StandardWatchEventKind.java + src/share/classes/java/nio/file/StandardWatchEventKinds.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/fs/AbstractPoller.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/nio/fs/PollingWatchService.java ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c ! src/share/sample/nio/chatserver/ChatServer.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! 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/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/Shutdown.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/file/Files/CheckPermissions.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/WatchService/LotsOfEvents.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/WatchService/WithSecurityManager.java Changeset: dec7961ff53f Author: alanb Date: 2011-05-09 18:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dec7961ff53f Merge Changeset: 05939afe3fc2 Author: naoto Date: 2011-05-09 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/05939afe3fc2 7041950: Fix copyright Reviewed-by: okutsu ! src/share/classes/sun/text/resources/BreakIteratorRules_th.java Changeset: 9f56fbc8b6be Author: weijun Date: 2011-05-10 07:00 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9f56fbc8b6be 7041635: GSSContextSpi.java copyright notice error Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java Changeset: f4d804b21217 Author: darcy Date: 2011-05-09 17:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f4d804b21217 7021645: Project Coin: Minor improvements to java.lang.Throwable Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java Changeset: 6a3a41e0af88 Author: lancea Date: 2011-05-10 14:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6a3a41e0af88 7043443: address missed reason initialization in BatchUpdateException Reviewed-by: alanb ! src/share/classes/java/sql/BatchUpdateException.java Changeset: e941ff30d005 Author: mduigou Date: 2011-05-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e941ff30d005 7043513: Update test for StandardCharsets Reviewed-by: alanb - test/java/nio/charset/StandardCharset/Standard.java + test/java/nio/charset/StandardCharsets/Standard.java Changeset: 2147ec13c98e Author: mduigou Date: 2011-05-10 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2147ec13c98e Merge - test/java/nio/charset/StandardCharset/Standard.java Changeset: 11ef1f1bd7ca Author: alanb Date: 2011-05-11 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11ef1f1bd7ca 7043425: (fc) ClosedByInterruptException thrown but interrupt status not set Reviewed-by: dholmes, chegar ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! test/java/nio/channels/FileChannel/ClosedByInterrupt.java Changeset: f91c799f7bfb Author: alanb Date: 2011-05-11 15:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f91c799f7bfb 7043788: (fs) PosixFileAttributes.owner() or group() throws NPE if owner/group not in passwd/group database Reviewed-by: chegar ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 501ca93ea3ef Author: sherman Date: 2011-05-11 08:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/501ca93ea3ef 7043234: (fmt) java.util.Formatter links in javadoc to BigDecimal need to be fixed Summary: fixed the doc miss Reviewed-by: alanb, emcmanus ! src/share/classes/java/util/Formatter.java Changeset: 831017d8fbcf Author: kamg Date: 2011-05-11 20:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/831017d8fbcf 6659215: javax.management.timer.Timer frequently fails to start Summary: Copy array to avoid ConcurrentModificationException Reviewed-by: dcubed, alanb ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/timer/StartTest.java Changeset: 99156e4f26ea Author: xuelei Date: 2011-05-11 20:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/99156e4f26ea 7043514: NPE in sun.security.ssl.JsseJce.isEcAvailable Reviewed-by: weijun, vinnie, wetmore ! src/share/classes/sun/security/ssl/JsseJce.java Changeset: d498e50ae62d Author: kamg Date: 2011-05-12 08:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d498e50ae62d 7044203: Missing @test tag in test/javax/management/timer/StartTest.java Summary: Add tag Reviewed-by: alanb ! test/javax/management/timer/StartTest.java Changeset: 8daf9e0c9a2e Author: fparain Date: 2011-05-13 13:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8daf9e0c9a2e 7031754: javax.management docs need to be updated to replace Java SE 6 occurrences Summary: Remove references to a specific version of the Java Platform Reviewed-by: mchung, kamg ! src/share/classes/javax/management/loading/package.html ! src/share/classes/javax/management/modelmbean/package.html ! src/share/classes/javax/management/monitor/package.html ! src/share/classes/javax/management/openmbean/package.html ! src/share/classes/javax/management/package.html ! src/share/classes/javax/management/relation/package.html ! src/share/classes/javax/management/remote/package.html Changeset: d830ec851cee Author: sherman Date: 2011-05-14 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d830ec851cee 7044849: Constructs for Unicode binary properties should be \p{IsXXX} not p{isXXX} Summary: fixed the doc typo Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java Changeset: 07b5cc7d4c84 Author: lana Date: 2011-05-14 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/07b5cc7d4c84 Merge Changeset: 55339371da15 Author: lana Date: 2011-05-14 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/55339371da15 Merge Changeset: cecfcb4dbcaa Author: chegar Date: 2011-05-16 13:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cecfcb4dbcaa 7042679: Phaser javadoc example does not compile Reviewed-by: dl ! src/share/classes/java/util/concurrent/Phaser.java Changeset: e0c3fd538f1f Author: fparain Date: 2011-05-16 17:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e0c3fd538f1f 7036199: Adding a notification to the implementation of GarbageCollectorMXBeans Summary: Add a JMX notification to GarbageCollectorMXBeans Reviewed-by: acorn, mchung ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java + src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/MemoryManagerImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/GarbageCollectorImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java + test/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java Changeset: 2ecb989b6fcc Author: dcubed Date: 2011-05-16 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2ecb989b6fcc 6977677: 3/2 Deadlock on logging subsystem initialization Summary: Over synchronized Logger.getLogger() deadlocks with LogManager.via PlatformLogger Reviewed-by: dsamersoff, never, acorn, mchung ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggingDeadlock4.java Changeset: b2db38eb3b13 Author: dcubed Date: 2011-05-16 12:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b2db38eb3b13 7016208: 4/3 null sometimes returned by java.util.logging.Logger.getLogger(String name) in -server -Xcomp Summary: Logger can be GC'ed between LogManager.addLogger() and LogManager.getLogger() Reviewed-by: dsamersoff, never, acorn, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: 9861df231e9e Author: dcubed Date: 2011-05-16 12:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9861df231e9e 7041595: 4/4 add lost test for 6487638 Summary: Add missing LoggingDeadlock3.java and LoggingDeadlock3.props Reviewed-by: dsamersoff, never, acorn, mchung + test/java/util/logging/LoggingDeadlock3.java + test/java/util/logging/LoggingDeadlock3.props Changeset: 5b38ed5f5eb4 Author: lana Date: 2011-05-16 18:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5b38ed5f5eb4 Merge - src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java - src/share/classes/java/net/StandardSocketOption.java - src/share/classes/java/nio/charset/StandardCharset.java - src/share/classes/java/nio/file/StandardWatchEventKind.java - test/java/nio/charset/StandardCharset/Standard.java Changeset: 65dd04c9ee64 Author: darcy Date: 2011-05-18 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/65dd04c9ee64 7045138: OutOfMemoryError thrown without stack trace in jdk7-b142 Reviewed-by: dholmes, mchung ! src/share/classes/java/lang/Throwable.java Changeset: 366fcac7ee01 Author: lana Date: 2011-05-18 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/366fcac7ee01 Merge Changeset: efbf75c24b0f Author: lana Date: 2011-05-18 18:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/efbf75c24b0f Merge - src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java - src/share/classes/java/net/StandardSocketOption.java - src/share/classes/java/nio/charset/StandardCharset.java - src/share/classes/java/nio/file/StandardWatchEventKind.java - test/java/nio/charset/StandardCharset/Standard.java Changeset: 5f69702cf570 Author: schien Date: 2011-05-20 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5f69702cf570 Added tag jdk7-b143 for changeset efbf75c24b0f ! .hgtags Changeset: be4b9e596352 Author: trims Date: 2011-05-20 05:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/be4b9e596352 Merge Changeset: 127560d6f6e6 Author: trims Date: 2011-05-24 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/127560d6f6e6 Merge Changeset: 3f760b347d3b Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3f760b347d3b 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 23bdcede4e39 Author: katleman Date: 2011-05-25 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/23bdcede4e39 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/keytool.1 ! src/share/classes/java/io/SerialCallbackContext.java ! src/share/classes/sun/io/ByteToCharCp833.java ! src/share/classes/sun/io/CharToByteCp833.java ! src/share/classes/sun/misc/FpUtils.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! test/com/sun/net/httpserver/Test10.java ! test/java/awt/List/ScrollOutside/ScrollOut.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_1.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_4.java ! test/java/awt/image/IncorrectSampleMaskTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java ! test/java/util/EnumMap/DistinctEntrySetElements.java ! test/java/util/EnumMap/EntrySetIteratorRemoveInvalidatesEntry.java ! test/java/util/EnumMap/SimpleSerialization.java ! test/java/util/EnumSet/LargeEnumIteratorRemoveResilience.java ! test/java/util/EnumSet/SmallEnumIteratorRemoveResilience.java ! test/java/util/Hashtable/SerializationDeadlock.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/IdentityHashMap/DistinctEntrySetElements.java ! test/java/util/IdentityHashMap/EntrySetIteratorRemoveInvalidatesEntry.java ! test/java/util/Vector/SerializationDeadlock.java ! test/java/util/Vector/SimpleSerialization.java ! test/java/util/concurrent/ConcurrentHashMap/DistinctEntrySetElements.java ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java ! test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor ! test/tools/launcher/TestHelper.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/Utils.java Changeset: c344779fab58 Author: schien Date: 2011-05-26 20:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c344779fab58 Added tag jdk7-b144 for changeset 23bdcede4e39 ! .hgtags Changeset: f09930d526ba Author: jrose Date: 2011-05-26 17:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f09930d526ba 7032323: code changes for JSR 292 EG adjustments to API, through Public Review Summary: API code changes and javadoc changes following JSR 292 Public Review comments, through PFD Reviewed-by: never ! src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/6998541/Test6998541.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/indify/Indify.java Changeset: 81f957f86ba5 Author: jcoomes Date: 2011-05-27 19:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/81f957f86ba5 Merge Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bc97b962330e 7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has. Reviewed-by: yhuang, ogino ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties Changeset: 6943c4d9caa3 Author: mfang Date: 2011-05-31 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c5bc5a807ee 7024120: Verify reduced JRE contents for java 7 Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode Reviewed-by: bobv, ohair ! make/common/Defs-embedded.gmk ! make/common/Release-embedded.gmk Changeset: f4895b3fe1be Author: dholmes Date: 2011-05-31 17:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8d91855a1f4e 7046587: Outlines in OTF/CFF fonts are misclassified as quadratic curves Reviewed-by: igor ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0b0b92707cf5 Author: bae Date: 2011-05-30 12:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0b0b92707cf5 7032904: XRender: Java2Demo : Infinite loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64 Reviewed-by: prr ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 290daca0a693 Author: prr Date: 2011-05-30 22:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/290daca0a693 7049874: OpenJDK Build breakage fix: freetypescaler.c needs to match updated signature Reviewed-by: lana, igor ! src/share/native/sun/font/freetypeScaler.c Changeset: b351af09bfa3 Author: lana Date: 2011-06-02 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d2081a1f417f 7045174: Most of the tests in awt area fails with jdk 7b142 on windows with -Xcheck:jni Reviewed-by: art, denis ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 000a845b1e38 Author: denis Date: 2011-05-28 12:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/000a845b1e38 7046325: Broken links in java.awt.Toolkit's javadoc Reviewed-by: dav, yan ! src/share/classes/java/awt/Toolkit.java Changeset: eab94f59b6dc Author: dcherepanov Date: 2011-05-30 13:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eab94f59b6dc 7045354: Korean IME's Hanja candidate window is not displayed on IMFDemo Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp Changeset: f05164caa490 Author: serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: b955226868af Author: lana Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1fbaf2b688a6 7045593: Possible Regression : JTextfield cursor placement behavior algorithm has changed. Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java + test/javax/swing/text/Utilities/bug7045593.java Changeset: 442237d3ec2c Author: rupashka Date: 2011-05-28 11:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/442237d3ec2c 7048204: NPE from NimbusLookAndFeel.addDefault Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test7048204.java Changeset: 386516fdf40b Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/386516fdf40b Merge Changeset: 0a80650409e1 Author: mullan Date: 2011-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0a80650409e1 7044443: Permissions resolved incorrectly for jar protocol (Patch from bugs.openjdk.java.net) Reviewed-by: alanb, chegar Contributed-by: dbhole at redhat.com ! src/share/classes/sun/security/provider/PolicyFile.java + test/java/security/Policy/GetPermissions/JarURL.java Changeset: ace2dfdecda1 Author: mullan Date: 2011-05-24 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ace2dfdecda1 Merge Changeset: 70942be348af Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/70942be348af 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: b49a0af85821 Author: vinnie Date: 2011-05-30 16:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b49a0af85821 7049173: Replace the software license for ECC native code Reviewed-by: alanb ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: 4ed7c877a463 Author: michaelm Date: 2011-05-30 23:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ed7c877a463 7042550: Reintegrate 6569621 Reviewed-by: chegar, alanb ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java + src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: c79a089ae13b Author: wetmore Date: 2011-05-31 12:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c79a089ae13b 7042097: JDK 7's Unlimited Cryptographic Policy bundle text files must be updated. Reviewed-by: valeriep ! make/javax/crypto/Makefile Changeset: a00f48c96345 Author: lancea Date: 2011-06-02 12:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a00f48c96345 7049107: Cannot call initCause() on BatchUpdateException Reviewed-by: darcy ! src/share/classes/java/sql/BatchUpdateException.java Changeset: 39de8937c1d8 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39de8937c1d8 Merge Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8318d03e1766 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. Reviewed-by: never ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 0b8b6eace473 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0b8b6eace473 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. Reviewed-by: kvn, never ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: 34481a4012c3 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/34481a4012c3 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) Reviewed-by: never ! test/java/lang/invoke/RicochetTest.java Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8f19b165347b 7042594: 3 testis api/java_awt/Color/ICC_ProfileRGB/index.html fail against RI b138 OEL6x64. Reviewed-by: prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java + test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: bbb4cef2208b Author: lana Date: 2011-06-04 17:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/03a828e368ca 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: 6c9c55ae313b Author: lana Date: 2011-06-03 22:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e81d259442ed Merge Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/53d759eb580c 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java Changeset: 49aef5a5416e Author: mullan Date: 2011-06-04 06:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/49aef5a5416e 7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows Reviewed-by: alanb ! test/java/security/Policy/GetPermissions/JarURL.java + test/java/security/Policy/GetPermissions/JarURL.policy Changeset: 1f39ca0b9598 Author: mullan Date: 2011-06-04 06:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1f39ca0b9598 Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags Changeset: e7493c32e598 Author: schien Date: 2011-06-08 10:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e7493c32e598 Merge Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ae731399e525 7048568: Crash in Java_sun_awt_Win32GraphicsEnvironment_isVistaOS Reviewed-by: dcherepanov, art, amenkov ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: f08fcae94813 Author: lana Date: 2011-06-10 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f08fcae94813 Merge Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6e961c328276 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Reviewed-by: chegar, alanb ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B7050028.java Changeset: b6ced5ad7a62 Author: dwanvik Date: 2011-06-10 17:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b6ced5ad7a62 7046557: Changes to the Java DB README files in JDK7 Summary: Update /README.html with correct mention of Java DB, add JDK specific README files to /db and /demo/db. Reviewed-by: ohair ! make/common/Release.gmk Changeset: 646ab254ff80 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/aca0dc2b921c 6618658: Deserialization allows creation of mutable SignedObject Reviewed-by: hawtin, mullan ! src/share/classes/java/security/SignedObject.java + test/java/security/SignedObject/Correctness.java Changeset: df445f522425 Author: bae Date: 2011-02-17 12:21 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/df445f522425 7013519: [parfait] Integer overflows in 2D code Reviewed-by: prr, valeriep ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ccb2fcfb6d6b Author: chegar Date: 2011-02-18 13:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ccb2fcfb6d6b 7013969: NetworkInterface.toString can reveal bindings Reviewed-by: alanb, michaelm, hawtin ! src/share/classes/java/net/NetworkInterface.java Changeset: 026adaac71f1 Author: dcherepanov Date: 2011-02-25 15:54 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/026adaac71f1 7012520: Heap overflow vulnerability in FileDialog.show() Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: d489f00d6c65 Author: flar Date: 2011-03-02 05:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d489f00d6c65 7016495: Crash in Java 2D transforming an image with scale close to zero Reviewed-by: prr, bae ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/java2d/loops/TransformHelper.c + test/java/awt/image/BufferedImage/TinyScale.java Changeset: fe27fe44ac51 Author: ksrini Date: 2011-03-03 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fe27fe44ac51 7016985: (launcher) implement safe secure dll loading Reviewed-by: mchung ! src/windows/bin/java_md.c Changeset: 0efa64f13302 Author: chegar Date: 2011-04-05 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0efa64f13302 7033865: JDK: Add private API for secure/restrictive loading of system dlls Reviewed-by: alanb ! src/share/native/common/jdk_util.h + src/solaris/native/common/jdk_util_md.h ! src/windows/native/common/jdk_util_md.c + src/windows/native/common/jdk_util_md.h Changeset: 67992a58bfba Author: ksrini Date: 2011-04-05 16:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/67992a58bfba 7032593: DLL_LOADING: Upgrade solution to 7016985 to reflect JDK7 solution Reviewed-by: mchung, asaha ! src/windows/bin/java_md.c Changeset: 7181441faf72 Author: dcherepanov Date: 2011-04-08 16:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7181441faf72 7003962: AWT: securely load DLLs and launch executables using fully qualified path Reviewed-by: art, bae, alanb ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/stdhdrs.h Changeset: 05a3923f516f Author: dcherepanov Date: 2011-04-08 17:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/05a3923f516f 7035077: Minor addition to the changes for 7003962 Reviewed-by: chegar ! src/windows/native/sun/windows/DllUtil.cpp Changeset: afcc1530e68b Author: asaha Date: 2011-04-08 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/afcc1530e68b Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 557bd9b5d92f Author: asaha Date: 2011-04-08 10:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e142148d8b54 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 76e0e562b617 Author: dcherepanov Date: 2011-04-15 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76e0e562b617 7036952: build warning after the changes for 7003962 Reviewed-by: art, bae ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: f8eddc85cc02 Author: zgu Date: 2011-04-15 09:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f8eddc85cc02 7003964: SERV: securely load DLLs and launch executables using fully qualified path Summary: Linked in Windows libraries that are available on jdk7 supported platforms, and used GetModuleHandle instead of LoadLibrary for already loaded Dlls. Reviewed-by: dcubed, alanb ! make/com/sun/tools/attach/Makefile ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h Changeset: 0865aa0ad9b2 Author: zgu Date: 2011-04-19 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6f8a4d334fb2 Merge ! make/com/sun/tools/attach/Makefile ! src/share/classes/java/net/NetworkInterface.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/windows/bin/java_md.c ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: f3645b5d6e62 Author: asaha Date: 2011-04-20 21:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b2295905901a Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 3fedf261fb4f Author: valeriep Date: 2011-04-26 15:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3fedf261fb4f 7003952: SEC: securely load DLLs and launch executables using fully qualified path Summary: Enforce full path when specifying library locations. Reviewed-by: wetmore, ohair ! make/sun/security/pkcs11/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c + test/sun/security/pkcs11/Provider/Absolute.cfg + test/sun/security/pkcs11/Provider/Absolute.java Changeset: 94ea3b8288f1 Author: alexp Date: 2011-05-04 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/94ea3b8288f1 7020198: ImageIcon creates Component with null acc Reviewed-by: rupashka, hawtin ! src/share/classes/javax/swing/ImageIcon.java Changeset: e6fdfb249e31 Author: asaha Date: 2011-05-04 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e6fdfb249e31 Merge - src/share/native/sun/font/layout/Features.h ! src/windows/native/sun/windows/awt_FileDialog.cpp - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 49244980d692 Author: asaha Date: 2011-05-05 22:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/49244980d692 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 647b031200f0 Author: asaha Date: 2011-05-06 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/92b5197e9ff5 Merge ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: cca9ea306c6e Author: asaha Date: 2011-05-26 21:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9f17be5136d1 7052537: java/security/Security/NotInstalledProviders.java is causing -samevm tests to fail. Reviewed-by: valeriep, asaha, alanb ! test/java/security/Security/NoInstalledProviders.java Changeset: 4961be00d3b5 Author: lana Date: 2011-06-15 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4961be00d3b5 Merge Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cf0632d2db2c 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a65fa0f6717e Merge Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c46f97579fe6 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Reviewed-by: chegar ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c Changeset: c102e1221afa Author: lana Date: 2011-06-17 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/539e576793a8 Merge Changeset: 7b4f4230fecf Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7b4f4230fecf Added tag jdk7-b146 for changeset 539e576793a8 ! .hgtags Changeset: f2928d86aab0 Author: schien Date: 2011-06-20 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f2928d86aab0 Merge Changeset: cfd7602f5c52 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cfd7602f5c52 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: f097ca2434b1 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f097ca2434b1 Merge Changeset: 9b8c96f96a0f Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9b8c96f96a0f Added tag jdk7-b147 for changeset f097ca2434b1 ! .hgtags Changeset: fc350fd41f31 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fc350fd41f31 Merge Changeset: 685a01aa8cd2 Author: prr Date: 2011-05-25 19:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/685a01aa8cd2 7044394: TrueTypeFont inner class DirectoryEntry should be static Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: 73d420a7199b Author: dlila Date: 2011-06-24 16:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/73d420a7199b 7049339: AnyBlit is broken with non-rectangular clips. Reviewed-by: flar ! src/share/classes/sun/java2d/loops/Blit.java + test/sun/java2d/loops/Bug7049339.java Changeset: bb481604e929 Author: lana Date: 2011-06-30 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bb481604e929 Merge Changeset: b8bcb12acea6 Author: weijun Date: 2011-05-27 09:01 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b8bcb12acea6 7048466: Move sun.misc.JavaxSecurityAuthKerberosAccess to sun.security.krb5 package Reviewed-by: weijun, alanb Contributed-by: Mandy Chung ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java + src/share/classes/sun/security/krb5/KerberosSecrets.java Changeset: 0da0a4d22fba Author: dcubed Date: 2011-06-01 17:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0da0a4d22fba 7048308: 4/4 LoggingDeadlock3 test timeout is too small Summary: Change timeout for test from 15 seconds to 80 seconds. Reviewed-by: dholmes ! test/java/util/logging/LoggingDeadlock3.java Changeset: 4a221501079a Author: dcubed Date: 2011-06-01 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4a221501079a 7045594: 4/4 fix for 6977677 introduced a ResourceBundle race Summary: Fix Logger.getLogger() ResourceBundle name race. Reviewed-by: dholmes, mchung ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerResourceBundleRace.java + test/java/util/logging/RacingThreadsTest.java Changeset: 9b678733fa51 Author: weijun Date: 2011-06-08 14:01 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9b678733fa51 7043737: klist does not detect non-existing keytab Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java + test/sun/security/krb5/tools/ktmissing.sh Changeset: 958eea7dd46e Author: darcy Date: 2011-06-13 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/958eea7dd46e 7052122: Update JDK_MINOR_VERSION for JDK 8 Reviewed-by: mr, katleman ! make/common/shared/Defs.gmk ! make/docs/Makefile Changeset: 08fdfdb19ad6 Author: coffeys Date: 2011-06-14 18:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/08fdfdb19ad6 7049774: UID construction appears to hang if time changed backwards Reviewed-by: alanb, dholmes, chegar, mduigou ! src/share/classes/java/rmi/server/UID.java Changeset: 4e7a9fa84dea Author: darcy Date: 2011-06-14 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4e7a9fa84dea 7054669: javadoc warnings from java.awt.Toolkit Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: 33e6291f3251 Author: darcy Date: 2011-06-15 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/33e6291f3251 7041252: Use j.u.Objects.equals in security classes Reviewed-by: weijun ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/x509/DistributionPoint.java ! src/share/classes/sun/security/x509/DistributionPointName.java Changeset: 85480980cd5e Author: darcy Date: 2011-06-17 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/85480980cd5e 7021922: java.lang.annoation.IncompleteExceptions throws NPE when type is null Reviewed-by: alanb, forax ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java + test/java/lang/annotation/TestIncompleteAnnotationExceptionNPE.java Changeset: e373b4c95b4b Author: ksrini Date: 2011-06-17 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e373b4c95b4b 7043125: TEST: tools/launcher/VersionCheck.java fails just against openjdk7 (b141 & b138-nightly) promoted Reviewed-by: darcy ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/VersionCheck.java Changeset: b29888e74be3 Author: alanb Date: 2011-06-19 11:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b29888e74be3 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java hangs or times out Reviewed-by: forax, vinnie ! test/ProblemList.txt ! test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 82706552f7a3 Author: weijun Date: 2011-06-20 17:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/82706552f7a3 7054428: test/java/security/SecureClassLoader/DefineClassByteBuffer.java error Reviewed-by: alanb ! test/ProblemList.txt ! test/java/security/SecureClassLoader/DefineClassByteBuffer.java Changeset: 411d02c13385 Author: dl Date: 2011-06-20 12:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/411d02c13385 7051516: ThreadLocalRandom seed is never initialized so all instances generate the same sequence Reviewed-by: chegar, dholmes, mduigou ! src/share/classes/java/util/Random.java Changeset: a015dda3bdc6 Author: weijun Date: 2011-06-20 19:17 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a015dda3bdc6 7054918: jdk_security1 test target cleanup Reviewed-by: alanb, smarks, vinnie ! test/ProblemList.txt ! test/java/security/BasicPermission/PermClass.java ! test/java/security/BasicPermission/SerialVersion.java ! test/java/security/KeyFactory/Failover.java ! test/java/security/KeyPairGenerator/Failover.java ! test/java/security/Provider/ChangeProviders.java ! test/java/security/Provider/GetInstance.java ! test/java/security/Provider/RemoveProvider.java ! test/java/security/Provider/Turkish.java ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/NoInstalledProviders.java ! test/java/security/Security/SynchronizedAccess.java ! test/java/security/Security/removing/RemoveProviders.java ! test/java/security/UnresolvedPermission/Equals.java ! test/java/security/spec/EllipticCurveMatch.java + test/java/security/testlibrary/ProvidersSnapshot.java Changeset: 3c8f939ced1c Author: darcy Date: 2011-06-20 17:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3c8f939ced1c 7055295: (reflect) add conventional constructor to GenericSignatureFormatError Reviewed-by: lancea, mduigou ! src/share/classes/java/lang/reflect/GenericSignatureFormatError.java Changeset: 70f14c2db078 Author: alanb Date: 2011-06-21 16:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/70f14c2db078 7056815: test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh times out intermittently on busy machine Reviewed-by: mchung ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh Changeset: 0bde4bed86e5 Author: alanb Date: 2011-06-22 15:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0bde4bed86e5 7056447: test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java fails in agentvm Reviewed-by: emcmanus ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java Changeset: febb7f557135 Author: weijun Date: 2011-06-23 09:27 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/febb7f557135 7055362: jdk_security2 test target cleanup Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt ! test/com/sun/crypto/provider/Cipher/DES/Sealtest.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP_KAT.java ! test/javax/crypto/EncryptedPrivateKeyInfo/GetKeySpecException.java ! test/javax/crypto/JceSecurity/SunJCE_BC_LoadOrdering.java Changeset: 3b7193ab0d87 Author: xuelei Date: 2011-06-22 19:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3b7193ab0d87 6952814: sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java failing in PIT Reviewed-by: alanb - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: 57265bf4b36b Author: xuelei Date: 2011-06-22 21:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/57265bf4b36b 7058271: Remove InterruptedIO.java record from ProblemList.txt Reviewed-by: weijun ! test/ProblemList.txt Changeset: 6b2c14dfe9b9 Author: chegar Date: 2011-06-23 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6b2c14dfe9b9 7057935: com/sun/nio/sctp tests should be moved out of jdk_nio and into their own target, jdk_sctp Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt Changeset: ae7211979179 Author: chegar Date: 2011-06-23 13:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ae7211979179 7021010: java/lang/Thread/ThreadStateTest.java fails intermittently Reviewed-by: dholmes, alanb, mchung ! test/ProblemList.txt ! test/java/lang/Thread/ThreadStateTest.java Changeset: cd7adb545f71 Author: xuelei Date: 2011-06-23 04:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cd7adb545f71 7057022: test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java has invalid jtreg tags Reviewed-by: weijun ! test/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java Changeset: 151756a4037b Author: darcy Date: 2011-06-23 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/151756a4037b 6253144: Long narrowing conversion should describe the algorithm used and implied "risks" Reviewed-by: mduigou, alanb ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Number.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java Changeset: 5838c5bd185d Author: lana Date: 2011-06-22 23:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5838c5bd185d Merge ! src/share/classes/java/awt/Toolkit.java ! test/java/security/Security/NoInstalledProviders.java Changeset: 5dedb265ba3e Author: lana Date: 2011-06-23 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5dedb265ba3e Merge Changeset: b037a8bc1be8 Author: lana Date: 2011-06-23 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b037a8bc1be8 Merge Changeset: 0ad50d4ed1cf Author: alanb Date: 2011-06-24 19:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0ad50d4ed1cf 6965150: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Basic.java takes too long Reviewed-by: chegar ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: 113c75db6c8b Author: michaelm Date: 2011-06-27 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/113c75db6c8b 7059777: Remove lang tests from Problemlist.txt Reviewed-by: alanb ! test/ProblemList.txt Changeset: a053c28304e8 Author: ksrini Date: 2011-06-27 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a053c28304e8 7046007: (launcher) Improve usage information for -verbose option Reviewed-by: darcy, alanb ! src/share/classes/sun/launcher/resources/launcher.properties Changeset: 3abc52f0a4dc Author: dholmes Date: 2011-06-27 20:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3abc52f0a4dc 7039182: PPC: NIO: java.io.IOException: Invalid argument in sun.nio.ch.FileDispatcherImpl.read0 Summary: Allow platform specific files to be located at build time instead of generating them Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk ! make/java/nio/Makefile Changeset: 7b5a0a141b8b Author: michaelm Date: 2011-06-28 10:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7b5a0a141b8b 7058832: com/sun/net/httpserver/bugs/B6373555.java failing intermittently Reviewed-by: alanb ! test/com/sun/net/httpserver/bugs/B6373555.java Changeset: 585cc4a4528d Author: michaelm Date: 2011-06-28 10:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/585cc4a4528d Merge Changeset: 9bcf6217a374 Author: lana Date: 2011-06-30 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9bcf6217a374 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java From ptisnovs at redhat.com Mon Jul 11 02:54:40 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 11 Jul 2011 11:54:40 +0200 Subject: Binary-only data contained in regression test hotspot/test/runtime/7020373 Message-ID: <4E1AC860.7030201@redhat.com> Hi all, I realized, that one part of the regression test hotspot/test/runtime/7020373 contains binary-only data which IMHO prevent us to backport this test to OpenJDK6 (in fact, only one file of this test was backported at this moment, so this test always fails due to a missed file). The mentioned part of 7020373 test is a Java archive "testcase.jar" which contains just one file "OOMCrashClass4000_1.class" without corresponding source code. I presume that the file "OOMCrashClass4000_1.class" were not obtained by compiling regular Java source file, but using BCEL or similar tool instead. The problem is that the script/source code used for creating .class is not included in the test. Is it possible to include such script/source code to the OpenJDK7 repository so the test could be fully backported to OpenJDK6, please? Thank you in advance, Pavel Tisnovsky From forax at univ-mlv.fr Mon Jul 11 03:09:08 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 11 Jul 2011 12:09:08 +0200 Subject: Binary-only data contained in regression test hotspot/test/runtime/7020373 In-Reply-To: <4E1AC860.7030201@redhat.com> References: <4E1AC860.7030201@redhat.com> Message-ID: <4E1ACBC4.9090506@univ-mlv.fr> On 07/11/2011 11:54 AM, Pavel Tisnovsky wrote: > Hi all, > > I realized, that one part of the regression test > hotspot/test/runtime/7020373 contains binary-only data which IMHO > prevent us to backport this test to OpenJDK6 (in fact, only one file of > this test was backported at this moment, so this test always fails due > to a missed file). > > The mentioned part of 7020373 test is a Java archive "testcase.jar" > which contains just one file "OOMCrashClass4000_1.class" without > corresponding source code. > > I presume that the file "OOMCrashClass4000_1.class" were not obtained by > compiling regular Java source file, but using BCEL or similar tool > instead. The problem is that the script/source code used for creating > .class is not included in the test. > > Is it possible to include such script/source code to the OpenJDK7 > repository so the test could be fully backported to OpenJDK6, please? > > Thank you in advance, > Pavel Tisnovsky You can re-create it :) ASM [1] (a BCEL like tool) has a nice tool called the ASMifier that allows you to create a Java code from a class file: |java -classpath "asm.jar;asm-util.jar" org.objectweb.asm.util.ASMifierClassVisitor org/domain/package/YourClass.class| R?mi [1] http://asm.ow2.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110711/fa8b89ab/attachment.html From ptisnovs at redhat.com Mon Jul 11 04:19:16 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 11 Jul 2011 13:19:16 +0200 Subject: Binary-only data contained in regression test hotspot/test/runtime/7020373 In-Reply-To: <4E1ACBC4.9090506@univ-mlv.fr> References: <4E1AC860.7030201@redhat.com> <4E1ACBC4.9090506@univ-mlv.fr> Message-ID: <4E1ADC34.2070502@redhat.com> R?mi Forax wrote: > On 07/11/2011 11:54 AM, Pavel Tisnovsky wrote: >> Hi all, >> >> I realized, that one part of the regression test >> hotspot/test/runtime/7020373 contains binary-only data which IMHO >> prevent us to backport this test to OpenJDK6 (in fact, only one file of >> this test was backported at this moment, so this test always fails due >> to a missed file). >> >> The mentioned part of 7020373 test is a Java archive "testcase.jar" >> which contains just one file "OOMCrashClass4000_1.class" without >> corresponding source code. >> >> I presume that the file "OOMCrashClass4000_1.class" were not obtained by >> compiling regular Java source file, but using BCEL or similar tool >> instead. The problem is that the script/source code used for creating >> .class is not included in the test. >> >> Is it possible to include such script/source code to the OpenJDK7 >> repository so the test could be fully backported to OpenJDK6, please? >> >> Thank you in advance, >> Pavel Tisnovsky > > You can re-create it :) > ASM [1] (a BCEL like tool) has a nice tool called the ASMifier that > allows you to create a Java code from a class file: > |java -classpath "asm.jar;asm-util.jar" > org.objectweb.asm.util.ASMifierClassVisitor > org/domain/package/YourClass.class| Hi R?mi, yes, I know it is possible to re-create source from .class file, but there's (AFAIK) problem with licence text because .class file (suprisingly :-) does not contains such licence which allows us to re-engineer it :-) Pavel > > R?mi > [1] http://asm.ow2.org/ > From forax at univ-mlv.fr Mon Jul 11 05:36:22 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 11 Jul 2011 14:36:22 +0200 Subject: Binary-only data contained in regression test hotspot/test/runtime/7020373 In-Reply-To: <4E1ADC34.2070502@redhat.com> References: <4E1AC860.7030201@redhat.com> <4E1ACBC4.9090506@univ-mlv.fr> <4E1ADC34.2070502@redhat.com> Message-ID: <4E1AEE46.7020400@univ-mlv.fr> On 07/11/2011 01:19 PM, Pavel Tisnovsky wrote: > R?mi Forax wrote: >> On 07/11/2011 11:54 AM, Pavel Tisnovsky wrote: >>> Hi all, >>> >>> I realized, that one part of the regression test >>> hotspot/test/runtime/7020373 contains binary-only data which IMHO >>> prevent us to backport this test to OpenJDK6 (in fact, only one file of >>> this test was backported at this moment, so this test always fails due >>> to a missed file). >>> >>> The mentioned part of 7020373 test is a Java archive "testcase.jar" >>> which contains just one file "OOMCrashClass4000_1.class" without >>> corresponding source code. >>> >>> I presume that the file "OOMCrashClass4000_1.class" were not obtained by >>> compiling regular Java source file, but using BCEL or similar tool >>> instead. The problem is that the script/source code used for creating >>> .class is not included in the test. >>> >>> Is it possible to include such script/source code to the OpenJDK7 >>> repository so the test could be fully backported to OpenJDK6, please? >>> >>> Thank you in advance, >>> Pavel Tisnovsky >> You can re-create it :) >> ASM [1] (a BCEL like tool) has a nice tool called the ASMifier that >> allows you to create a Java code from a class file: >> |java -classpath "asm.jar;asm-util.jar" >> org.objectweb.asm.util.ASMifierClassVisitor >> org/domain/package/YourClass.class| > Hi R?mi, > > yes, I know it is possible to re-create source from .class file, but > there's (AFAIK) problem with licence text because .class file > (suprisingly :-) does not contains such licence which allows us to > re-engineer it :-) > > Pavel I see. I was thinking it was an engineering problem not a legal one. R?mi >> R?mi >> [1] http://asm.ow2.org/ >> From keith.mcguigan at oracle.com Mon Jul 11 06:57:12 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 11 Jul 2011 09:57:12 -0400 Subject: Binary-only data contained in regression test hotspot/test/runtime/7020373 In-Reply-To: <4E1ADC34.2070502@redhat.com> References: <4E1AC860.7030201@redhat.com> <4E1ACBC4.9090506@univ-mlv.fr> <4E1ADC34.2070502@redhat.com> Message-ID: That test case was created directly as output from a Java program -- there is no "source code" for it. The generating program was submitted as an attachment to 6878713, but with different input parameters, IIRC, and was created by Marc Schoenefeld (sorry I don't know his email). Not sure what the licensing terms are on his submission; you'll have to check with him. -- - Keith On Jul 11, 2011, at 7:19 AM, Pavel Tisnovsky wrote: > R?mi Forax wrote: >> On 07/11/2011 11:54 AM, Pavel Tisnovsky wrote: >>> Hi all, >>> >>> I realized, that one part of the regression test >>> hotspot/test/runtime/7020373 contains binary-only data which IMHO >>> prevent us to backport this test to OpenJDK6 (in fact, only one >>> file of >>> this test was backported at this moment, so this test always fails >>> due >>> to a missed file). >>> >>> The mentioned part of 7020373 test is a Java archive "testcase.jar" >>> which contains just one file "OOMCrashClass4000_1.class" without >>> corresponding source code. >>> >>> I presume that the file "OOMCrashClass4000_1.class" were not >>> obtained by >>> compiling regular Java source file, but using BCEL or similar tool >>> instead. The problem is that the script/source code used for >>> creating >>> .class is not included in the test. >>> >>> Is it possible to include such script/source code to the OpenJDK7 >>> repository so the test could be fully backported to OpenJDK6, >>> please? >>> >>> Thank you in advance, >>> Pavel Tisnovsky >> >> You can re-create it :) >> ASM [1] (a BCEL like tool) has a nice tool called the ASMifier that >> allows you to create a Java code from a class file: >> |java -classpath "asm.jar;asm-util.jar" >> org.objectweb.asm.util.ASMifierClassVisitor >> org/domain/package/YourClass.class| > > Hi R?mi, > > yes, I know it is possible to re-create source from .class file, but > there's (AFAIK) problem with licence text because .class file > (suprisingly :-) does not contains such licence which allows us to > re-engineer it :-) > > Pavel > >> >> R?mi >> [1] http://asm.ow2.org/ >> > From forax at univ-mlv.fr Mon Jul 11 07:53:00 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 11 Jul 2011 16:53:00 +0200 Subject: Binary-only data contained in regression test hotspot/test/runtime/7020373 In-Reply-To: References: <4E1AC860.7030201@redhat.com> <4E1ACBC4.9090506@univ-mlv.fr> <4E1ADC34.2070502@redhat.com> Message-ID: <4E1B0E4C.90802@univ-mlv.fr> On 07/11/2011 03:57 PM, Keith McGuigan wrote: > > That test case was created directly as output from a Java program -- > there is no "source code" for it. The generating program was > submitted as an attachment to 6878713, but with different input > parameters, IIRC, and was created by Marc Schoenefeld (sorry I don't > know his email). Not sure what the licensing terms are on his > submission; you'll have to check with him. > > -- > - Keith He is a RedHat guy (mschoene @t redhat dot com) R?mi > > On Jul 11, 2011, at 7:19 AM, Pavel Tisnovsky wrote: > >> R?mi Forax wrote: >>> On 07/11/2011 11:54 AM, Pavel Tisnovsky wrote: >>>> Hi all, >>>> >>>> I realized, that one part of the regression test >>>> hotspot/test/runtime/7020373 contains binary-only data which IMHO >>>> prevent us to backport this test to OpenJDK6 (in fact, only one >>>> file of >>>> this test was backported at this moment, so this test always fails due >>>> to a missed file). >>>> >>>> The mentioned part of 7020373 test is a Java archive "testcase.jar" >>>> which contains just one file "OOMCrashClass4000_1.class" without >>>> corresponding source code. >>>> >>>> I presume that the file "OOMCrashClass4000_1.class" were not >>>> obtained by >>>> compiling regular Java source file, but using BCEL or similar tool >>>> instead. The problem is that the script/source code used for creating >>>> .class is not included in the test. >>>> >>>> Is it possible to include such script/source code to the OpenJDK7 >>>> repository so the test could be fully backported to OpenJDK6, please? >>>> >>>> Thank you in advance, >>>> Pavel Tisnovsky >>> >>> You can re-create it :) >>> ASM [1] (a BCEL like tool) has a nice tool called the ASMifier that >>> allows you to create a Java code from a class file: >>> |java -classpath "asm.jar;asm-util.jar" >>> org.objectweb.asm.util.ASMifierClassVisitor >>> org/domain/package/YourClass.class| >> >> Hi R?mi, >> >> yes, I know it is possible to re-create source from .class file, but >> there's (AFAIK) problem with licence text because .class file >> (suprisingly :-) does not contains such licence which allows us to >> re-engineer it :-) >> >> Pavel >> >>> >>> R?mi >>> [1] http://asm.ow2.org/ >>> >> > From mandy.chung at oracle.com Mon Jul 11 18:12:37 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Jul 2011 09:12:37 +0800 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E154353.8070601@oracle.com> References: <4E154353.8070601@oracle.com> Message-ID: <4E1B9F85.1080409@oracle.com> Hi David, On 7/7/11 1:25 PM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/7046490/webrev/ > > This is a simple fix in the VM to honour the Throwable immutability > protocol that was defined for Java 7. Pre-allocated Throwable > instances are normally immutable, but that is not the case for a group > of pre-allocated OutOfMemoryError instances. To conform to the > protocol, when we set the backtrace (VM representation of the > stackTrace) we have to set the stackTrace field to the sentinel value > stored in the static Throwable.UNASSIGNED_STACK field. This fix looks good. I assume you still need a reviewer for this fix :) Mandy From David.Holmes at oracle.com Mon Jul 11 18:47:20 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 12 Jul 2011 11:47:20 +1000 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E1B9F85.1080409@oracle.com> References: <4E154353.8070601@oracle.com> <4E1B9F85.1080409@oracle.com> Message-ID: <4E1BA7A8.6060606@oracle.com> Hi Mandy, Mandy Chung said the following on 07/12/11 11:12: > On 7/7/11 1:25 PM, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >> >> This is a simple fix in the VM to honour the Throwable immutability >> protocol that was defined for Java 7. Pre-allocated Throwable >> instances are normally immutable, but that is not the case for a group >> of pre-allocated OutOfMemoryError instances. To conform to the >> protocol, when we set the backtrace (VM representation of the >> stackTrace) we have to set the stackTrace field to the sentinel value >> stored in the static Throwable.UNASSIGNED_STACK field. > > This fix looks good. I assume you still need a reviewer for this fix :) Yes still needed reviewers. That's one down, now I need someone from runtime. Thanks, David From volker.simonis at gmail.com Thu Jul 14 07:33:29 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Jul 2011 16:33:29 +0200 Subject: Decoder not properly initialized on Windows Message-ID: Hi, it seems that after "7003748: Decode C stack frames when symbols are presented (PhoneHome project)" (http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2d4762ec74af) it can happen that the Decoder class is not properly initialized on Windows: In frame.cpp in 'print_C_frame()' there's the following code: 676 if (!in_vm || Decoder::can_decode_C_frame_in_vm()) { 677 found = os::dll_address_to_function_name(pc, buf, buflen, &offset); 678 679 if (found) { 680 st->print(" %s+0x%x", buf, offset); 681 } 682 } If 'in_vm' is false, 'Decoder::can_decode_C_frame_in_vm()' won't be called and the Decoder class will not be initialized. 'print_C_frame()' is only called from 'frame::print_on_error()' which in turn is called directly in the steps 60 and 120 of 'VMError::report()' and indirectly through 'VMError::print_stack_trace()' in the steps 130 and 135 of 'VMError::report()'. But only the call from step 120 properly initializes the Decoder class before calling 'frame::print_on_error()' by construction a local Decoder object: // initialize decoder to decode C frames Decoder decoder; The problem only manifests itself on Windows, because the Unix implementations of the Decoder class don't require an initialization. I would suggest the attached patch which moves the Decoder initialization from 'VMError::report()' right into the 'print_C_frame()' method (which is the place where it is actually required). If somebody would be so kind to create a bug for this issue I can also submit a formal webrev if required. With best regards, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: decoder.patch Type: text/x-patch Size: 1142 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110714/89266cbf/attachment.bin From daniel.daugherty at oracle.com Thu Jul 14 10:59:35 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Jul 2011 11:59:35 -0600 Subject: Decoder not properly initialized on Windows In-Reply-To: References: Message-ID: <4E1F2E87.7020100@oracle.com> New bug filed for you: 7067266 4/4 Decoder class not properly initialized on Windows Dan On 7/14/11 8:33 AM, Volker Simonis wrote: > Hi, > > it seems that after "7003748: Decode C stack frames when symbols are > presented (PhoneHome project)" > (http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2d4762ec74af) > it can happen that the Decoder class is not properly initialized on > Windows: > > In frame.cpp in 'print_C_frame()' there's the following code: > > > > 676 if (!in_vm || Decoder::can_decode_C_frame_in_vm()) { > 677 found = os::dll_address_to_function_name(pc, buf, buflen,&offset); > 678 > 679 if (found) { > 680 st->print(" %s+0x%x", buf, offset); > 681 } > 682 } > > If 'in_vm' is false, 'Decoder::can_decode_C_frame_in_vm()' won't be > called and the Decoder class will not be initialized. > > 'print_C_frame()' is only called from 'frame::print_on_error()' which > in turn is called directly in the steps 60 and 120 of > 'VMError::report()' and indirectly through > 'VMError::print_stack_trace()' in the steps 130 and 135 of > 'VMError::report()'. But only the call from step 120 properly > initializes the Decoder class before calling 'frame::print_on_error()' > by construction a local Decoder object: > > // initialize decoder to decode C frames > Decoder decoder; > > The problem only manifests itself on Windows, because the Unix > implementations of the Decoder class don't require an initialization. > > I would suggest the attached patch which moves the Decoder > initialization from 'VMError::report()' right into the > 'print_C_frame()' method (which is the place where it is actually > required). > > If somebody would be so kind to create a bug for this issue I can also > submit a formal webrev if required. > > With best regards, > Volker > decoder.patch > > > diff -r b16582d6c7db src/share/vm/runtime/frame.cpp > --- a/src/share/vm/runtime/frame.cpp Thu Jul 07 10:51:07 2011 -0700 > +++ b/src/share/vm/runtime/frame.cpp Thu Jul 14 16:30:26 2011 +0200 > @@ -673,6 +673,7 @@ > // names if pc is within jvm.dll or libjvm.so, because JVM only has > // JVM_xxxx and a few other symbols in the dynamic symbol table. Do this > // only for native libraries. > + Decoder decoder; // initialize decoder to decode C frames > if (!in_vm || Decoder::can_decode_C_frame_in_vm()) { > found = os::dll_address_to_function_name(pc, buf, buflen,&offset); > > diff -r b16582d6c7db src/share/vm/utilities/vmError.cpp > --- a/src/share/vm/utilities/vmError.cpp Thu Jul 07 10:51:07 2011 -0700 > +++ b/src/share/vm/utilities/vmError.cpp Thu Jul 14 16:30:26 2011 +0200 > @@ -566,9 +566,6 @@ > if (fr.pc()) { > st->print_cr("Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)"); > > - // initialize decoder to decode C frames > - Decoder decoder; > - > int count = 0; > while (count++< StackPrintLimit) { > fr.print_on_error(st, buf, sizeof(buf)); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110714/913853e6/attachment.html From volker.simonis at gmail.com Fri Jul 15 02:22:28 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jul 2011 11:22:28 +0200 Subject: Decoder not properly initialized on Windows In-Reply-To: <4E1F2E87.7020100@oracle.com> References: <4E1F2E87.7020100@oracle.com> Message-ID: Thank you! I'll file a webrev later today. Just out of personal interest: can you explain to me what the numbers (in this case '4/4') in front of the bug description mean. I see them from time to time but couldn't figure out there meaning. Regards, Volker On Thu, Jul 14, 2011 at 7:59 PM, Daniel D. Daugherty wrote: > New bug filed for you: > > 7067266 4/4 Decoder class not properly initialized on Windows > > Dan > > > > > On 7/14/11 8:33 AM, Volker Simonis wrote: > > Hi, > > it seems that after "7003748: Decode C stack frames when symbols are > presented (PhoneHome project)" > (http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2d4762ec74af) > it can happen that the Decoder class is not properly initialized on > Windows: > > In frame.cpp in 'print_C_frame()' there's the following code: > > > > 676 if (!in_vm || Decoder::can_decode_C_frame_in_vm()) { > 677 found = os::dll_address_to_function_name(pc, buf, buflen, &offset); > 678 > 679 if (found) { > 680 st->print(" %s+0x%x", buf, offset); > 681 } > 682 } > > If 'in_vm' is false, 'Decoder::can_decode_C_frame_in_vm()' won't be > called and the Decoder class will not be initialized. > > 'print_C_frame()' is only called from 'frame::print_on_error()' which > in turn is called directly in the steps 60 and 120 of > 'VMError::report()' and indirectly through > 'VMError::print_stack_trace()' in the steps 130 and 135 of > 'VMError::report()'. But only the call from step 120 properly > initializes the Decoder class before calling 'frame::print_on_error()' > by construction a local Decoder object: > > // initialize decoder to decode C frames > Decoder decoder; > > The problem only manifests itself on Windows, because the Unix > implementations of the Decoder class don't require an initialization. > > I would suggest the attached patch which moves the Decoder > initialization from 'VMError::report()' right into the > 'print_C_frame()' method (which is the place where it is actually > required). > > If somebody would be so kind to create a bug for this issue I can also > submit a formal webrev if required. > > With best regards, > Volker > > decoder.patch > diff -r b16582d6c7db src/share/vm/runtime/frame.cpp > --- a/src/share/vm/runtime/frame.cpp Thu Jul 07 10:51:07 2011 -0700 > +++ b/src/share/vm/runtime/frame.cpp Thu Jul 14 16:30:26 2011 +0200 > @@ -673,6 +673,7 @@ > // names if pc is within jvm.dll or libjvm.so, because JVM only has > // JVM_xxxx and a few other symbols in the dynamic symbol table. Do this > // only for native libraries. > + Decoder decoder; // initialize decoder to decode C frames > if (!in_vm || Decoder::can_decode_C_frame_in_vm()) { > found = os::dll_address_to_function_name(pc, buf, buflen, &offset); > > diff -r b16582d6c7db src/share/vm/utilities/vmError.cpp > --- a/src/share/vm/utilities/vmError.cpp Thu Jul 07 10:51:07 2011 -0700 > +++ b/src/share/vm/utilities/vmError.cpp Thu Jul 14 16:30:26 2011 +0200 > @@ -566,9 +566,6 @@ > if (fr.pc()) { > st->print_cr("Native frames: (J=compiled Java code, > j=interpreted, Vv=VM code, C=native code)"); > > - // initialize decoder to decode C frames > - Decoder decoder; > - > int count = 0; > while (count++ < StackPrintLimit) { > fr.print_on_error(st, buf, sizeof(buf)); > From Alan.Bateman at oracle.com Fri Jul 15 02:41:41 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jul 2011 10:41:41 +0100 Subject: Decoder not properly initialized on Windows In-Reply-To: References: <4E1F2E87.7020100@oracle.com> Message-ID: <4E200B55.5080201@oracle.com> Volker Simonis wrote: > Thank you! > > I'll file a webrev later today. > > Just out of personal interest: can you explain to me what the numbers > (in this case '4/4') in front of the bug description mean. I see them > from time to time but couldn't figure out there meaning. > The proprietary bug database has priority and severity fields so I assume this is priority=4 and severity=4 (where 1 is highest, 5 is lowest). -Alan. From volker.simonis at gmail.com Fri Jul 15 02:53:02 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jul 2011 11:53:02 +0200 Subject: Decoder not properly initialized on Windows In-Reply-To: <4E200B55.5080201@oracle.com> References: <4E1F2E87.7020100@oracle.com> <4E200B55.5080201@oracle.com> Message-ID: Interesting! But why do some bugs have these fields encoded in the Subject field while others do not have them? On Fri, Jul 15, 2011 at 11:41 AM, Alan Bateman wrote: > Volker Simonis wrote: >> >> Thank you! >> >> I'll file a webrev later today. >> >> Just out of personal interest: can you explain to me what the numbers >> (in this case '4/4') in front of the bug description mean. I see them >> from time to time but couldn't figure out there meaning. >> > > The proprietary bug database has priority and severity fields so I assume > this is priority=4 and severity=4 (where 1 is highest, 5 is lowest). > > -Alan. > From David.Holmes at oracle.com Fri Jul 15 03:24:58 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2011 20:24:58 +1000 Subject: Decoder not properly initialized on Windows In-Reply-To: References: <4E1F2E87.7020100@oracle.com> <4E200B55.5080201@oracle.com> Message-ID: <4E20157A.7050909@oracle.com> Volker Simonis said the following on 07/15/11 19:53: > Interesting! > > But why do some bugs have these fields encoded in the Subject field > while others do not have them? I think it is simply the format used by the tool Dan used to show the bug info: / David > > On Fri, Jul 15, 2011 at 11:41 AM, Alan Bateman wrote: >> Volker Simonis wrote: >>> Thank you! >>> >>> I'll file a webrev later today. >>> >>> Just out of personal interest: can you explain to me what the numbers >>> (in this case '4/4') in front of the bug description mean. I see them >>> from time to time but couldn't figure out there meaning. >>> >> The proprietary bug database has priority and severity fields so I assume >> this is priority=4 and severity=4 (where 1 is highest, 5 is lowest). >> >> -Alan. >> From volker.simonis at gmail.com Fri Jul 15 03:42:49 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 15 Jul 2011 12:42:49 +0200 Subject: Decoder not properly initialized on Windows In-Reply-To: <4E20157A.7050909@oracle.com> References: <4E1F2E87.7020100@oracle.com> <4E200B55.5080201@oracle.com> <4E20157A.7050909@oracle.com> Message-ID: Ok, I don't want to appear to nit-picky, but a short > hg log | grep "[0-9]/[0-9]" 7043298: 4/4 fix for 7028172 causes "Label too long: ..." error message 7041410: 5/4 finish removing SOLARIS_7_OR_LATER from HotSpot 7028172: 3/4 SA needs to adapt to Solaris libproc change made in 6748307 7039447: 2/1 java profiling is broken in build 139 (garbage in function name) 7010849: 5/5 Extraneous javac source/target options when building sa-jdi ... reveals 36 changes which have a summary in this format. So the severity/priority seems to be an integral part of the summary field in this case. That's of course no problem at all - it's just interesting to see that some people/tools seem to insert the severity/priority right into the summary field. But after you explained the meaning of the numbers the semantics is now easily understandable. Thanks again, Volker On Fri, Jul 15, 2011 at 12:24 PM, David Holmes wrote: > Volker Simonis said the following on 07/15/11 19:53: >> >> Interesting! >> >> But why do some bugs have these fields encoded in the Subject field >> while others do not have them? > > I think it is simply the format used by the tool Dan used to show the bug > info: > > / > > David > >> >> On Fri, Jul 15, 2011 at 11:41 AM, Alan Bateman >> wrote: >>> >>> Volker Simonis wrote: >>>> >>>> Thank you! >>>> >>>> I'll file a webrev later today. >>>> >>>> Just out of personal interest: can you explain to me what the numbers >>>> (in this case '4/4') in front of the bug description mean. I see them >>>> from time to time but couldn't figure out there meaning. >>>> >>> The proprietary bug database has priority and severity fields so I assume >>> this is priority=4 and severity=4 (where 1 is highest, 5 is lowest). >>> >>> -Alan. >>> > From David.Holmes at oracle.com Fri Jul 15 04:08:53 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Jul 2011 21:08:53 +1000 Subject: Decoder not properly initialized on Windows In-Reply-To: References: <4E1F2E87.7020100@oracle.com> <4E200B55.5080201@oracle.com> <4E20157A.7050909@oracle.com> Message-ID: <4E201FC5.9050000@oracle.com> Volker Simonis said the following on 07/15/11 20:42: > Ok, I don't want to appear to nit-picky, but a short > >> hg log | grep "[0-9]/[0-9]" > > 7043298: 4/4 fix for 7028172 causes "Label too long: ..." error message > 7041410: 5/4 finish removing SOLARIS_7_OR_LATER from HotSpot > 7028172: 3/4 SA needs to adapt to Solaris libproc change made in 6748307 > 7039447: 2/1 java profiling is broken in build 139 (garbage in function name) > 7010849: 5/5 Extraneous javac source/target options when building sa-jdi > ... > > reveals 36 changes which have a summary in this format. Interesting. The numbers are not part of the synopsis, so strictly speaking these commit comments are ill-formed (but jcheck doesn't validate the synopsis only that the line has the form ": "). I suspect Dan is using a script/tool to automatically extract the synopsis given the bugid to use in his commit comments, and the tool includes the additional info. BTW, not knowing the tool being used I don't know which order the numbers are actually in :) Cheers, David ----- > So the severity/priority seems to be an integral part of the summary > field in this case. > > That's of course no problem at all - it's just interesting to see that > some people/tools seem to insert the severity/priority right into the > summary field. > > But after you explained the meaning of the numbers the semantics is > now easily understandable. > > Thanks again, > Volker > > On Fri, Jul 15, 2011 at 12:24 PM, David Holmes wrote: >> Volker Simonis said the following on 07/15/11 19:53: >>> Interesting! >>> >>> But why do some bugs have these fields encoded in the Subject field >>> while others do not have them? >> I think it is simply the format used by the tool Dan used to show the bug >> info: >> >> / >> >> David >> >>> On Fri, Jul 15, 2011 at 11:41 AM, Alan Bateman >>> wrote: >>>> Volker Simonis wrote: >>>>> Thank you! >>>>> >>>>> I'll file a webrev later today. >>>>> >>>>> Just out of personal interest: can you explain to me what the numbers >>>>> (in this case '4/4') in front of the bug description mean. I see them >>>>> from time to time but couldn't figure out there meaning. >>>>> >>>> The proprietary bug database has priority and severity fields so I assume >>>> this is priority=4 and severity=4 (where 1 is highest, 5 is lowest). >>>> >>>> -Alan. >>>> From daniel.daugherty at oracle.com Fri Jul 15 06:34:11 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jul 2011 07:34:11 -0600 Subject: Decoder not properly initialized on Windows In-Reply-To: <4E201FC5.9050000@oracle.com> References: <4E1F2E87.7020100@oracle.com> <4E200B55.5080201@oracle.com> <4E20157A.7050909@oracle.com> <4E201FC5.9050000@oracle.com> Message-ID: <4E2041D3.8090604@oracle.com> Yes, old habits die hard... My bug management tools for the last decade or so have used:

/ Note the lack of a colon. OpenJDK's jcheck requires: : so I just have to remember to add the ':' in the right place and I'm good to go... I think I'm the last person left that does include the

/ info... Dan On 7/15/11 5:08 AM, David Holmes wrote: > Volker Simonis said the following on 07/15/11 20:42: >> Ok, I don't want to appear to nit-picky, but a short >> >>> hg log | grep "[0-9]/[0-9]" >> >> 7043298: 4/4 fix for 7028172 causes "Label too long: ..." error message >> 7041410: 5/4 finish removing SOLARIS_7_OR_LATER from HotSpot >> 7028172: 3/4 SA needs to adapt to Solaris libproc change made in 6748307 >> 7039447: 2/1 java profiling is broken in build 139 (garbage in >> function name) >> 7010849: 5/5 Extraneous javac source/target options when building sa-jdi >> ... >> >> reveals 36 changes which have a summary in this format. > > Interesting. The numbers are not part of the synopsis, so strictly > speaking these commit comments are ill-formed (but jcheck doesn't > validate the synopsis only that the line has the form ": "). > > I suspect Dan is using a script/tool to automatically extract the > synopsis given the bugid to use in his commit comments, and the tool > includes the additional info. > > BTW, not knowing the tool being used I don't know which order the > numbers are actually in :) > > Cheers, > David > ----- > >> So the severity/priority seems to be an integral part of the summary >> field in this case. >> >> That's of course no problem at all - it's just interesting to see that >> some people/tools seem to insert the severity/priority right into the >> summary field. >> >> But after you explained the meaning of the numbers the semantics is >> now easily understandable. >> >> Thanks again, >> Volker >> >> On Fri, Jul 15, 2011 at 12:24 PM, David Holmes >> wrote: >>> Volker Simonis said the following on 07/15/11 19:53: >>>> Interesting! >>>> >>>> But why do some bugs have these fields encoded in the Subject field >>>> while others do not have them? >>> I think it is simply the format used by the tool Dan used to show >>> the bug >>> info: >>> >>> / >>> >>> David >>> >>>> On Fri, Jul 15, 2011 at 11:41 AM, Alan Bateman >>>> >>>> wrote: >>>>> Volker Simonis wrote: >>>>>> Thank you! >>>>>> >>>>>> I'll file a webrev later today. >>>>>> >>>>>> Just out of personal interest: can you explain to me what the >>>>>> numbers >>>>>> (in this case '4/4') in front of the bug description mean. I see >>>>>> them >>>>>> from time to time but couldn't figure out there meaning. >>>>>> >>>>> The proprietary bug database has priority and severity fields so I >>>>> assume >>>>> this is priority=4 and severity=4 (where 1 is highest, 5 is lowest). >>>>> >>>>> -Alan. >>>>> From zhengyu.gu at oracle.com Fri Jul 15 11:27:06 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 15 Jul 2011 14:27:06 -0400 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows Message-ID: <4E20867A.7070400@oracle.com> Forward to openjdk for review: Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ Thanks, -Zhengyu -------- Original Message -------- Subject: Re: Code review request: 7067266 Decoder class not properly initialized on Windows Date: Fri, 15 Jul 2011 11:52:44 -0600 From: Daniel D. Daugherty Reply-To: daniel.daugherty at oracle.com To: Zhengyu Gu CC: hotspot-runtime-dev-confidential , volker-simonis at gmail.com Thumbs up on the code. Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net so this review should go out on that alias also (and the webrev copied to cr.openjdk.java.net) Dan On 7/15/11 11:26 AM, Zhengyu Gu wrote: > This is a simple fix that moves Decoder initialization to step 60 in > vmError.cpp, so the decoder can decode "Problematic frame:" in hs file > header. > > The bug was reported by volker-simonis at gmail.com > from SAP with proposed patch. The > solution was to move decoder initialization code to > print_C_frame() function, but it is less optimal, since decoder will > have to be initialized and uninitialized every time in/out of the > print_C_frame() function. > > CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 > Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ > > Testcase: > A simple Java program with JNI call that crashes VM: > > JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) { > int* p = NULL; > *p = 1; > } > > Without fix, hs file header: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, > tid=4140 > # > # JRE version: 6.0_23-b05 > # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing > windows-x86 ) > # Problematic frame: > # C [mydll.dll+0x11308] > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > > With fix: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, > tid=5964 > # > # JRE version: 6.0_23-b05 > # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode > windows-x86 ) > # Problematic frame: > # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 > # > # Failed to write core dump. Minidumps are not enabled by default on > client versions of Windows > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > > Thanks, > > -Zhengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110715/0e9a9278/attachment.html From John.Coomes at oracle.com Fri Jul 15 14:01:31 2011 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 15 Jul 2011 14:01:31 -0700 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E20867A.7070400@oracle.com> References: <4E20867A.7070400@oracle.com> Message-ID: <20000.43691.685390.246755@oracle.com> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: > Forward to openjdk for review: > > Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ Hi Zhengyu, The change looks correct. It's not new in this change, but I find it strange that static initialization of Decoder is triggered by creating an unused instance. It'd be clearer to call Decoder::initialize() instead, and then there'd be no need for the comment: // initialize decoder to decode C frames Decoder should also be changed to inherit from AllStatic instead of StackObj, but that's getting beyond this bug fix. -John > -------- Original Message -------- > Subject: Re: Code review request: 7067266 Decoder class not properly > initialized on Windows > Date: Fri, 15 Jul 2011 11:52:44 -0600 > From: Daniel D. Daugherty > Reply-To: daniel.daugherty at oracle.com > To: Zhengyu Gu > CC: hotspot-runtime-dev-confidential > , volker-simonis at gmail.com > > > > Thumbs up on the code. > > Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net > so this review should go out on that alias also (and the webrev > copied to cr.openjdk.java.net) > > Dan > > > On 7/15/11 11:26 AM, Zhengyu Gu wrote: > > This is a simple fix that moves Decoder initialization to step 60 in > > vmError.cpp, so the decoder can decode "Problematic frame:" in hs file > > header. > > > > The bug was reported by volker-simonis at gmail.com > > from SAP with proposed patch. The > > solution was to move decoder initialization code to > > print_C_frame() function, but it is less optimal, since decoder will > > have to be initialized and uninitialized every time in/out of the > > print_C_frame() function. > > > > CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 > > Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ > > > > Testcase: > > A simple Java program with JNI call that crashes VM: > > > > JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) { > > int* p = NULL; > > *p = 1; > > } > > > > Without fix, hs file header: > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, > > tid=4140 > > # > > # JRE version: 6.0_23-b05 > > # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing > > windows-x86 ) > > # Problematic frame: > > # C [mydll.dll+0x11308] > > # > > # If you would like to submit a bug report, please visit: > > # http://java.sun.com/webapps/bugreport/crash.jsp > > # The crash happened outside the Java Virtual Machine in native code. > > # See problematic frame for where to report the bug. > > # > > > > > > With fix: > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, > > tid=5964 > > # > > # JRE version: 6.0_23-b05 > > # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode > > windows-x86 ) > > # Problematic frame: > > # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 > > # > > # Failed to write core dump. Minidumps are not enabled by default on > > client versions of Windows > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.sun.com/bugreport/crash.jsp > > # The crash happened outside the Java Virtual Machine in native code. > > # See problematic frame for where to report the bug. > > # > > > > > > Thanks, > > > > -Zhengyu From David.Holmes at oracle.com Fri Jul 15 15:59:17 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 16 Jul 2011 08:59:17 +1000 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <20000.43691.685390.246755@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> Message-ID: <4E20C645.2050405@oracle.com> John Coomes said the following on 07/16/11 07:01: > Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >> Forward to openjdk for review: >> >> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ > > The change looks correct. > > It's not new in this change, but I find it strange that static > initialization of Decoder is triggered by creating an unused instance. > It'd be clearer to call Decoder::initialize() instead, and then > there'd be no need for the comment: > > // initialize decoder to decode C frames > > Decoder should also be changed to inherit from AllStatic instead of > StackObj, but that's getting beyond this bug fix. This is extremely confusing code. We have static data being manipulated by stack-scoped local instances, where the constructor does an initialize function and the destructor does an uninitalize that cleans up various resources. In addition we have a static function on Windows: bool Decoder::can_decode_C_frame_in_vm() { initialize(); return _can_decode_in_vm; } which initializes but never cleans up! And the use of these two mechanism can be interspersed. To top it off we create the Decoder instances in places where there is absolutely no indication that somewhere down in the call chain the Decoder functionality will be used! This is truly awful code. Volker's patch to move the Decoder into print_C_frame would seem much cleaner, but even it doesn't go far enough as we have redundant initialize() in can_decode_C_frame_in_vm, and I don't see why we should be working with static functions instead of the Decoder object that was created. Zhengyu is concerned that the repeated init/un-init might be too much if moved into print_C_frame, but his fix goes to the other extreme by giving the Decoder "global" scope in the error reporting process so we won't do any cleanup until right at the end (where we will presumably terminate the process) - so this seems to defeat the purpose of having the cleanup code in the first place. Given that we are in the process of dying I don't see that we should be overly concerned about overhead so I'd be inclined to go with Volker's fix and at least do the init and cleanup in the location where the Decoder is actually used. David ----- > -John > >> -------- Original Message -------- >> Subject: Re: Code review request: 7067266 Decoder class not properly >> initialized on Windows >> Date: Fri, 15 Jul 2011 11:52:44 -0600 >> From: Daniel D. Daugherty >> Reply-To: daniel.daugherty at oracle.com >> To: Zhengyu Gu >> CC: hotspot-runtime-dev-confidential >> , volker-simonis at gmail.com >> >> >> >> Thumbs up on the code. >> >> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >> so this review should go out on that alias also (and the webrev >> copied to cr.openjdk.java.net) >> >> Dan >> >> >> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>> This is a simple fix that moves Decoder initialization to step 60 in >>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs file >>> header. >>> >>> The bug was reported by volker-simonis at gmail.com >>> from SAP with proposed patch. The >>> solution was to move decoder initialization code to >>> print_C_frame() function, but it is less optimal, since decoder will >>> have to be initialized and uninitialized every time in/out of the >>> print_C_frame() function. >>> >>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>> >>> Testcase: >>> A simple Java program with JNI call that crashes VM: >>> >>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) { >>> int* p = NULL; >>> *p = 1; >>> } >>> >>> Without fix, hs file header: >>> >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, >>> tid=4140 >>> # >>> # JRE version: 6.0_23-b05 >>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>> windows-x86 ) >>> # Problematic frame: >>> # C [mydll.dll+0x11308] >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://java.sun.com/webapps/bugreport/crash.jsp >>> # The crash happened outside the Java Virtual Machine in native code. >>> # See problematic frame for where to report the bug. >>> # >>> >>> >>> With fix: >>> >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, >>> tid=5964 >>> # >>> # JRE version: 6.0_23-b05 >>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>> windows-x86 ) >>> # Problematic frame: >>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>> # >>> # Failed to write core dump. Minidumps are not enabled by default on >>> client versions of Windows >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://bugreport.sun.com/bugreport/crash.jsp >>> # The crash happened outside the Java Virtual Machine in native code. >>> # See problematic frame for where to report the bug. >>> # >>> >>> >>> Thanks, >>> >>> -Zhengyu From coleen.phillimore at oracle.com Sat Jul 16 23:26:21 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sun, 17 Jul 2011 06:26:21 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 12 new changesets Message-ID: <20110717062644.8CC89474B9@hg.openjdk.java.net> Changeset: 7d9e451f5416 Author: jcoomes Date: 2011-07-06 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7d9e451f5416 7061187: need some includes for arm/ppc Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/atomic.cpp Changeset: eb94b7226b7a Author: jcoomes Date: 2011-07-06 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eb94b7226b7a 7061192: option handling adjustments for oracle and embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65dba8692db7 Author: jcoomes Date: 2011-07-06 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/65dba8692db7 7061197: ThreadLocalStorage sp map table should be optional Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp Changeset: 48048b59a551 Author: jcoomes Date: 2011-07-06 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/48048b59a551 7061204: clean the chunk table synchronously in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: bf6481e5f96d Author: jcoomes Date: 2011-07-06 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf6481e5f96d 7061225: os::print_cpu_info() should support os-specific data Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 8a4fc2990229 Author: jcoomes Date: 2011-07-07 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8a4fc2990229 7053189: remove some unnecessary platform-dependent includes Reviewed-by: dholmes, never, jwilhelm, kvn ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp Changeset: b0b8491925fe Author: jcoomes Date: 2011-07-11 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b0b8491925fe 7061212: use o/s low memory notification in embedded builds Reviewed-by: dholmes, never, jwilhelm, kvn ! src/os/linux/vm/os_linux.cpp Changeset: 0defeba52583 Author: jcoomes Date: 2011-07-12 16:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0defeba52583 Merge Changeset: faa472957b38 Author: kvn Date: 2011-07-08 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/faa472957b38 7059034: Use movxtod/movdtox on T4 Summary: Use new VIS3 mov instructions on T4 for move data between general and float registers. Reviewed-by: never, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: 263247c478c5 Author: iveresov Date: 2011-07-08 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/263247c478c5 7058510: multinewarray with 6 dimensions uncommon traps in server compiler Summary: Pass arguments to runtime via java array for arrays with > 5 dimensions Reviewed-by: never, kvn, jrose, pbk ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 1f4f4ae84625 Author: kvn Date: 2011-07-13 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1f4f4ae84625 Merge ! src/share/vm/runtime/globals.hpp Changeset: bcc6475bc68f Author: coleenp Date: 2011-07-16 22:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bcc6475bc68f Merge From volker.simonis at gmail.com Mon Jul 18 02:25:16 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jul 2011 11:25:16 +0200 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E20C645.2050405@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> Message-ID: What about making the Decoder::decode() and all the other methods in the Decoder class instance methods? Then it would be clear that users of the decode() method would have to create (and initialize) a Decode object and it would be their responsibility when they create it and and when they uninitialize and clean it up. Depending on the platform, the Decoder class may still decide to keep its resources globally (as static data members) or just for the lifetime of a Decoder object. With the current solution the problem is (as pointed out by David) that it is not clear for callers if they have to do initialization or not, and this even differs between Unix and Windows. @Zhengyu: will you prepare a new webrev or should I submit one? Regards, Vovlker On Sat, Jul 16, 2011 at 12:59 AM, David Holmes wrote: > John Coomes said the following on 07/16/11 07:01: >> >> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>> >>> Forward to openjdk for review: >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >> >> The change looks correct. >> >> It's not new in this change, but I find it strange that static >> initialization of Decoder is triggered by creating an unused instance. >> It'd be clearer to call Decoder::initialize() instead, and then >> there'd be no need for the comment: >> >> ? ? ? ?// initialize decoder to decode C frames >> >> Decoder should also be changed to inherit from AllStatic instead of >> StackObj, but that's getting beyond this bug fix. > > This is extremely confusing code. We have static data being manipulated by > stack-scoped local instances, where the constructor does an initialize > function and the destructor does an uninitalize that cleans up various > resources. In addition we have a static function on Windows: > > bool Decoder::can_decode_C_frame_in_vm() { > ?initialize(); > ?return ?_can_decode_in_vm; > } > > which initializes but never cleans up! And the use of these two mechanism > can be interspersed. > > To top it off we create the Decoder instances in places where there is > absolutely no indication that somewhere down in the call chain the Decoder > functionality will be used! This is truly awful code. > > Volker's patch to move the Decoder into print_C_frame would seem much > cleaner, but even it doesn't go far enough as we have redundant initialize() > in can_decode_C_frame_in_vm, and I don't see why we should be working with > static functions instead of the Decoder object that was created. > > Zhengyu is concerned that the repeated init/un-init might be too much if > moved into print_C_frame, but his fix goes to the other extreme by giving > the Decoder "global" scope in the error reporting process so we won't do any > cleanup until right at the end (where we will presumably terminate the > process) - so this seems to defeat the purpose of having the cleanup code in > the first place. > > Given that we are in the process of dying I don't see that we should be > overly concerned about overhead so I'd be inclined to go with Volker's fix > and at least do the init and cleanup in the location where the Decoder is > actually used. > > David > ----- > > >> -John >> >>> -------- Original Message -------- >>> Subject: ? ? ? ?Re: Code review request: 7067266 Decoder class not >>> properly initialized on Windows >>> Date: ? Fri, 15 Jul 2011 11:52:44 -0600 >>> From: ? Daniel D. Daugherty >>> Reply-To: ? ? ? daniel.daugherty at oracle.com >>> To: ? ? Zhengyu Gu >>> CC: ? ? hotspot-runtime-dev-confidential >>> , volker-simonis at gmail.com >>> >>> >>> >>> Thumbs up on the code. >>> >>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>> so this review should go out on that alias also (and the webrev >>> copied to cr.openjdk.java.net) >>> >>> Dan >>> >>> >>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>> >>>> This is a simple fix that moves Decoder initialization to step 60 in >>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs file >>>> header. >>>> >>>> The bug was reported by volker-simonis at gmail.com >>>> from SAP with proposed patch. The solution >>>> was to move decoder initialization code to >>>> print_C_frame() function, but it is less optimal, since decoder will >>>> have to be initialized and uninitialized every time in/out of the >>>> print_C_frame() function. >>>> >>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>> >>>> Testcase: >>>> ?A simple Java program with JNI call that crashes VM: >>>> >>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) { >>>> ?int* p = NULL; >>>> ?*p = 1; >>>> } >>>> >>>> Without fix, hs file header: >>>> >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, >>>> tid=4140 >>>> # >>>> # JRE version: 6.0_23-b05 >>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>> windows-x86 ) >>>> # Problematic frame: >>>> # C ?[mydll.dll+0x11308] >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>> # The crash happened outside the Java Virtual Machine in native code. >>>> # See problematic frame for where to report the bug. >>>> # >>>> >>>> >>>> With fix: >>>> >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, >>>> tid=5964 >>>> # >>>> # JRE version: 6.0_23-b05 >>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>> windows-x86 ) >>>> # Problematic frame: >>>> # C ?[mydll.dll+0x11308] ?Java_jni_1excpt_Main_crashVM+0x28 >>>> # >>>> # Failed to write core dump. Minidumps are not enabled by default on >>>> client versions of Windows >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>> # The crash happened outside the Java Virtual Machine in native code. >>>> # See problematic frame for where to report the bug. >>>> # >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu > From zhengyu.gu at oracle.com Mon Jul 18 06:47:57 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 18 Jul 2011 09:47:57 -0400 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> Message-ID: <4E24398D.5000506@oracle.com> I have to disagree, I would much prefer to revert back it AllStatic implementation. Followings are the reasons: 1. Uninitialize() was intended to shutdown decoder in low memory scenarios, as the decoder is a secondary function. It may not be very clear in this usecase, but it is a scenario in the project I am currently working on. 2. Performance: Initial/uninitial decoder for decoding every symbol, definitely not optimal. In Unix implementation, it was programmed to maintain a symbol cache, which will not completely defeated, as it has to reopen/reparse elf file to decoder every frame. Again, decoder performance will be one of key factors for my other project. I will post new webrev to reflect AllStatic implementation. Thanks, -Zhengyu On 7/18/2011 5:25 AM, Volker Simonis wrote: > What about making the Decoder::decode() and all the other methods in > the Decoder class instance methods? > Then it would be clear that users of the decode() method would have to > create (and initialize) a Decode object and it would be their > responsibility when they create it and and when they uninitialize and > clean it up. Depending on the platform, the Decoder class may still > decide to keep its resources globally (as static data members) or just > for the lifetime of a Decoder object. > > With the current solution the problem is (as pointed out by David) > that it is not clear for callers if they have to do initialization or > not, and this even differs between Unix and Windows. > > @Zhengyu: will you prepare a new webrev or should I submit one? > > Regards, > Vovlker > > On Sat, Jul 16, 2011 at 12:59 AM, David Holmes wrote: >> John Coomes said the following on 07/16/11 07:01: >>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>> Forward to openjdk for review: >>>> >>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>> The change looks correct. >>> >>> It's not new in this change, but I find it strange that static >>> initialization of Decoder is triggered by creating an unused instance. >>> It'd be clearer to call Decoder::initialize() instead, and then >>> there'd be no need for the comment: >>> >>> // initialize decoder to decode C frames >>> >>> Decoder should also be changed to inherit from AllStatic instead of >>> StackObj, but that's getting beyond this bug fix. >> This is extremely confusing code. We have static data being manipulated by >> stack-scoped local instances, where the constructor does an initialize >> function and the destructor does an uninitalize that cleans up various >> resources. In addition we have a static function on Windows: >> >> bool Decoder::can_decode_C_frame_in_vm() { >> initialize(); >> return _can_decode_in_vm; >> } >> >> which initializes but never cleans up! And the use of these two mechanism >> can be interspersed. >> >> To top it off we create the Decoder instances in places where there is >> absolutely no indication that somewhere down in the call chain the Decoder >> functionality will be used! This is truly awful code. >> >> Volker's patch to move the Decoder into print_C_frame would seem much >> cleaner, but even it doesn't go far enough as we have redundant initialize() >> in can_decode_C_frame_in_vm, and I don't see why we should be working with >> static functions instead of the Decoder object that was created. >> >> Zhengyu is concerned that the repeated init/un-init might be too much if >> moved into print_C_frame, but his fix goes to the other extreme by giving >> the Decoder "global" scope in the error reporting process so we won't do any >> cleanup until right at the end (where we will presumably terminate the >> process) - so this seems to defeat the purpose of having the cleanup code in >> the first place. >> >> Given that we are in the process of dying I don't see that we should be >> overly concerned about overhead so I'd be inclined to go with Volker's fix >> and at least do the init and cleanup in the location where the Decoder is >> actually used. >> >> David >> ----- >> >> >>> -John >>> >>>> -------- Original Message -------- >>>> Subject: Re: Code review request: 7067266 Decoder class not >>>> properly initialized on Windows >>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>> From: Daniel D. Daugherty >>>> Reply-To: daniel.daugherty at oracle.com >>>> To: Zhengyu Gu >>>> CC: hotspot-runtime-dev-confidential >>>> , volker-simonis at gmail.com >>>> >>>> >>>> >>>> Thumbs up on the code. >>>> >>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>> so this review should go out on that alias also (and the webrev >>>> copied to cr.openjdk.java.net) >>>> >>>> Dan >>>> >>>> >>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>> This is a simple fix that moves Decoder initialization to step 60 in >>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs file >>>>> header. >>>>> >>>>> The bug was reported by volker-simonis at gmail.com >>>>> from SAP with proposed patch. The solution >>>>> was to move decoder initialization code to >>>>> print_C_frame() function, but it is less optimal, since decoder will >>>>> have to be initialized and uninitialized every time in/out of the >>>>> print_C_frame() function. >>>>> >>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>> >>>>> Testcase: >>>>> A simple Java program with JNI call that crashes VM: >>>>> >>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) { >>>>> int* p = NULL; >>>>> *p = 1; >>>>> } >>>>> >>>>> Without fix, hs file header: >>>>> >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, >>>>> tid=4140 >>>>> # >>>>> # JRE version: 6.0_23-b05 >>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>>> windows-x86 ) >>>>> # Problematic frame: >>>>> # C [mydll.dll+0x11308] >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>> # See problematic frame for where to report the bug. >>>>> # >>>>> >>>>> >>>>> With fix: >>>>> >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, >>>>> tid=5964 >>>>> # >>>>> # JRE version: 6.0_23-b05 >>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>>> windows-x86 ) >>>>> # Problematic frame: >>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>> # >>>>> # Failed to write core dump. Minidumps are not enabled by default on >>>>> client versions of Windows >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>> # See problematic frame for where to report the bug. >>>>> # >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu From volker.simonis at gmail.com Mon Jul 18 07:24:34 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Jul 2011 16:24:34 +0200 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E24398D.5000506@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> Message-ID: On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu wrote: > I have to disagree, I would much prefer to revert back it AllStatic > implementation. Followings are the reasons: > > 1. Uninitialize() was intended to shutdown decoder in low memory scenarios, > as the decoder is a secondary function. It may not be very clear in this > usecase, but it is a scenario in the project I am currently working on. > I don't know what project you are working on, but in the Hotspot as we can see it, the Decoder::decode() functionality is only accessed from os::dll_address_to_function_name(). This in turn is only called from two places: - from the VM error handler (in vmError.cpp) trough frame::print_on_error() which calls it trough print_C_frame() - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() > 2. Performance: Initial/uninitial decoder for decoding every symbol, > definitely not optimal. In Unix implementation, it was programmed to > maintain a symbol cache, which will not completely defeated, as it has to > reopen/reparse elf file to decoder every frame. Again, decoder performance > will be one of key factors for my other project. I didn't propose to create a new Decoder object for the decoding of each symbol. Instead a decoder object could be passed into os::dll_address_to_function_name() and frame::print_on_error(). The user of the functionality could then decide how long he wants to keep the Decoder object and its resources alive. In the case of the FlatProfiler this would probably be the whole VM lifetime, for the vmError use case it would be probably for the time of a complete stack trace. > > I will post new webrev to reflect AllStatic implementation. > > Thanks, > > -Zhengyu > > On 7/18/2011 5:25 AM, Volker Simonis wrote: >> >> What about making the Decoder::decode() and all the other methods in >> the Decoder class instance methods? >> Then it would be clear that users of the decode() method would have to >> create (and initialize) a Decode object and it would be their >> responsibility when they create it and and when they uninitialize and >> clean it up. Depending on the platform, the Decoder class may still >> decide to keep its resources globally (as static data members) or just >> for the lifetime of a Decoder object. >> >> With the current solution the problem is (as pointed out by David) >> that it is not clear for callers if they have to do initialization or >> not, and this even differs between Unix and Windows. >> >> @Zhengyu: will you prepare a new webrev or should I submit one? >> >> Regards, >> Vovlker >> >> On Sat, Jul 16, 2011 at 12:59 AM, David Holmes >> ?wrote: >>> >>> John Coomes said the following on 07/16/11 07:01: >>>> >>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>> >>>>> Forward to openjdk for review: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>> >>>> The change looks correct. >>>> >>>> It's not new in this change, but I find it strange that static >>>> initialization of Decoder is triggered by creating an unused instance. >>>> It'd be clearer to call Decoder::initialize() instead, and then >>>> there'd be no need for the comment: >>>> >>>> ? ? ? ?// initialize decoder to decode C frames >>>> >>>> Decoder should also be changed to inherit from AllStatic instead of >>>> StackObj, but that's getting beyond this bug fix. >>> >>> This is extremely confusing code. We have static data being manipulated >>> by >>> stack-scoped local instances, where the constructor does an initialize >>> function and the destructor does an uninitalize that cleans up various >>> resources. In addition we have a static function on Windows: >>> >>> bool Decoder::can_decode_C_frame_in_vm() { >>> ?initialize(); >>> ?return ?_can_decode_in_vm; >>> } >>> >>> which initializes but never cleans up! And the use of these two mechanism >>> can be interspersed. >>> >>> To top it off we create the Decoder instances in places where there is >>> absolutely no indication that somewhere down in the call chain the >>> Decoder >>> functionality will be used! This is truly awful code. >>> >>> Volker's patch to move the Decoder into print_C_frame would seem much >>> cleaner, but even it doesn't go far enough as we have redundant >>> initialize() >>> in can_decode_C_frame_in_vm, and I don't see why we should be working >>> with >>> static functions instead of the Decoder object that was created. >>> >>> Zhengyu is concerned that the repeated init/un-init might be too much if >>> moved into print_C_frame, but his fix goes to the other extreme by giving >>> the Decoder "global" scope in the error reporting process so we won't do >>> any >>> cleanup until right at the end (where we will presumably terminate the >>> process) - so this seems to defeat the purpose of having the cleanup code >>> in >>> the first place. >>> >>> Given that we are in the process of dying I don't see that we should be >>> overly concerned about overhead so I'd be inclined to go with Volker's >>> fix >>> and at least do the init and cleanup in the location where the Decoder is >>> actually used. >>> >>> David >>> ----- >>> >>> >>>> -John >>>> >>>>> -------- Original Message -------- >>>>> Subject: ? ? ? ?Re: Code review request: 7067266 Decoder class not >>>>> properly initialized on Windows >>>>> Date: ? Fri, 15 Jul 2011 11:52:44 -0600 >>>>> From: ? Daniel D. Daugherty >>>>> Reply-To: ? ? ? daniel.daugherty at oracle.com >>>>> To: ? ? Zhengyu Gu >>>>> CC: ? ? hotspot-runtime-dev-confidential >>>>> , volker-simonis at gmail.com >>>>> >>>>> >>>>> >>>>> Thumbs up on the code. >>>>> >>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>> so this review should go out on that alias also (and the webrev >>>>> copied to cr.openjdk.java.net) >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>> >>>>>> This is a simple fix that moves Decoder initialization to step 60 in >>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs file >>>>>> header. >>>>>> >>>>>> The bug was reported by volker-simonis at gmail.com >>>>>> ?from SAP with proposed patch. The >>>>>> solution >>>>>> was to move decoder initialization code to >>>>>> print_C_frame() function, but it is less optimal, since decoder will >>>>>> have to be initialized and uninitialized every time in/out of the >>>>>> print_C_frame() function. >>>>>> >>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>> >>>>>> Testcase: >>>>>> ?A simple Java program with JNI call that crashes VM: >>>>>> >>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) >>>>>> { >>>>>> ?int* p = NULL; >>>>>> ?*p = 1; >>>>>> } >>>>>> >>>>>> Without fix, hs file header: >>>>>> >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, >>>>>> tid=4140 >>>>>> # >>>>>> # JRE version: 6.0_23-b05 >>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>>>> windows-x86 ) >>>>>> # Problematic frame: >>>>>> # C ?[mydll.dll+0x11308] >>>>>> # >>>>>> # If you would like to submit a bug report, please visit: >>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>>> # See problematic frame for where to report the bug. >>>>>> # >>>>>> >>>>>> >>>>>> With fix: >>>>>> >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, >>>>>> tid=5964 >>>>>> # >>>>>> # JRE version: 6.0_23-b05 >>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>>>> windows-x86 ) >>>>>> # Problematic frame: >>>>>> # C ?[mydll.dll+0x11308] ?Java_jni_1excpt_Main_crashVM+0x28 >>>>>> # >>>>>> # Failed to write core dump. Minidumps are not enabled by default on >>>>>> client versions of Windows >>>>>> # >>>>>> # If you would like to submit a bug report, please visit: >>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>>> # See problematic frame for where to report the bug. >>>>>> # >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu > > From zhengyu.gu at oracle.com Mon Jul 18 07:37:21 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 18 Jul 2011 10:37:21 -0400 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> Message-ID: <4E244521.8070706@oracle.com> My other work pretty much requires Decoder to be on all the time when the feature is turned on. I do see the possibility to restrict access to uninitialize() function, which only intended to be called under low memory scenario. Otherwise, we have to reference counting on Decoder. You are absolutely right with current usecases, but there will be more callsites to the decoder soon, and I don't see any reason except low memory scenario, we want to shutdown decoder. Thanks, -Zhengyu On 7/18/2011 10:24 AM, Volker Simonis wrote: > On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu wrote: >> I have to disagree, I would much prefer to revert back it AllStatic >> implementation. Followings are the reasons: >> >> 1. Uninitialize() was intended to shutdown decoder in low memory scenarios, >> as the decoder is a secondary function. It may not be very clear in this >> usecase, but it is a scenario in the project I am currently working on. >> > I don't know what project you are working on, but in the Hotspot as we > can see it, the Decoder::decode() functionality is only accessed from > os::dll_address_to_function_name(). This in turn is only called from > two places: > - from the VM error handler (in vmError.cpp) trough > frame::print_on_error() which calls it trough print_C_frame() > - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() > >> 2. Performance: Initial/uninitial decoder for decoding every symbol, >> definitely not optimal. In Unix implementation, it was programmed to >> maintain a symbol cache, which will not completely defeated, as it has to >> reopen/reparse elf file to decoder every frame. Again, decoder performance >> will be one of key factors for my other project. > I didn't propose to create a new Decoder object for the decoding of > each symbol. Instead a decoder object could be passed into > os::dll_address_to_function_name() and frame::print_on_error(). The > user of the functionality could then decide how long he wants to keep > the Decoder object and its resources alive. In the case of the > FlatProfiler this would probably be the whole VM lifetime, for the > vmError use case it would be probably for the time of a complete stack > trace. > >> I will post new webrev to reflect AllStatic implementation. >> >> Thanks, >> >> -Zhengyu >> >> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>> What about making the Decoder::decode() and all the other methods in >>> the Decoder class instance methods? >>> Then it would be clear that users of the decode() method would have to >>> create (and initialize) a Decode object and it would be their >>> responsibility when they create it and and when they uninitialize and >>> clean it up. Depending on the platform, the Decoder class may still >>> decide to keep its resources globally (as static data members) or just >>> for the lifetime of a Decoder object. >>> >>> With the current solution the problem is (as pointed out by David) >>> that it is not clear for callers if they have to do initialization or >>> not, and this even differs between Unix and Windows. >>> >>> @Zhengyu: will you prepare a new webrev or should I submit one? >>> >>> Regards, >>> Vovlker >>> >>> On Sat, Jul 16, 2011 at 12:59 AM, David Holmes >>> wrote: >>>> John Coomes said the following on 07/16/11 07:01: >>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>> Forward to openjdk for review: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>> The change looks correct. >>>>> >>>>> It's not new in this change, but I find it strange that static >>>>> initialization of Decoder is triggered by creating an unused instance. >>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>> there'd be no need for the comment: >>>>> >>>>> // initialize decoder to decode C frames >>>>> >>>>> Decoder should also be changed to inherit from AllStatic instead of >>>>> StackObj, but that's getting beyond this bug fix. >>>> This is extremely confusing code. We have static data being manipulated >>>> by >>>> stack-scoped local instances, where the constructor does an initialize >>>> function and the destructor does an uninitalize that cleans up various >>>> resources. In addition we have a static function on Windows: >>>> >>>> bool Decoder::can_decode_C_frame_in_vm() { >>>> initialize(); >>>> return _can_decode_in_vm; >>>> } >>>> >>>> which initializes but never cleans up! And the use of these two mechanism >>>> can be interspersed. >>>> >>>> To top it off we create the Decoder instances in places where there is >>>> absolutely no indication that somewhere down in the call chain the >>>> Decoder >>>> functionality will be used! This is truly awful code. >>>> >>>> Volker's patch to move the Decoder into print_C_frame would seem much >>>> cleaner, but even it doesn't go far enough as we have redundant >>>> initialize() >>>> in can_decode_C_frame_in_vm, and I don't see why we should be working >>>> with >>>> static functions instead of the Decoder object that was created. >>>> >>>> Zhengyu is concerned that the repeated init/un-init might be too much if >>>> moved into print_C_frame, but his fix goes to the other extreme by giving >>>> the Decoder "global" scope in the error reporting process so we won't do >>>> any >>>> cleanup until right at the end (where we will presumably terminate the >>>> process) - so this seems to defeat the purpose of having the cleanup code >>>> in >>>> the first place. >>>> >>>> Given that we are in the process of dying I don't see that we should be >>>> overly concerned about overhead so I'd be inclined to go with Volker's >>>> fix >>>> and at least do the init and cleanup in the location where the Decoder is >>>> actually used. >>>> >>>> David >>>> ----- >>>> >>>> >>>>> -John >>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: Code review request: 7067266 Decoder class not >>>>>> properly initialized on Windows >>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>> From: Daniel D. Daugherty >>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>> To: Zhengyu Gu >>>>>> CC: hotspot-runtime-dev-confidential >>>>>> , volker-simonis at gmail.com >>>>>> >>>>>> >>>>>> >>>>>> Thumbs up on the code. >>>>>> >>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>> so this review should go out on that alias also (and the webrev >>>>>> copied to cr.openjdk.java.net) >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>> This is a simple fix that moves Decoder initialization to step 60 in >>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs file >>>>>>> header. >>>>>>> >>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>> from SAP with proposed patch. The >>>>>>> solution >>>>>>> was to move decoder initialization code to >>>>>>> print_C_frame() function, but it is less optimal, since decoder will >>>>>>> have to be initialized and uninitialized every time in/out of the >>>>>>> print_C_frame() function. >>>>>>> >>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>> >>>>>>> Testcase: >>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>> >>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) >>>>>>> { >>>>>>> int* p = NULL; >>>>>>> *p = 1; >>>>>>> } >>>>>>> >>>>>>> Without fix, hs file header: >>>>>>> >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, >>>>>>> tid=4140 >>>>>>> # >>>>>>> # JRE version: 6.0_23-b05 >>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>>>>> windows-x86 ) >>>>>>> # Problematic frame: >>>>>>> # C [mydll.dll+0x11308] >>>>>>> # >>>>>>> # If you would like to submit a bug report, please visit: >>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>>>> # See problematic frame for where to report the bug. >>>>>>> # >>>>>>> >>>>>>> >>>>>>> With fix: >>>>>>> >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, >>>>>>> tid=5964 >>>>>>> # >>>>>>> # JRE version: 6.0_23-b05 >>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>>>>> windows-x86 ) >>>>>>> # Problematic frame: >>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>> # >>>>>>> # Failed to write core dump. Minidumps are not enabled by default on >>>>>>> client versions of Windows >>>>>>> # >>>>>>> # If you would like to submit a bug report, please visit: >>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>>>> # See problematic frame for where to report the bug. >>>>>>> # >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >> From paul.hohensee at oracle.com Mon Jul 18 20:32:06 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 18 Jul 2011 23:32:06 -0400 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E154353.8070601@oracle.com> References: <4E154353.8070601@oracle.com> Message-ID: <4E24FAB6.2030305@oracle.com> Looks good, except, could you use obj_field() in unassigned_stacktrace() instead of checking UseCompressedOops there? Paul On 7/7/11 1:25 AM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/7046490/webrev/ > > This is a simple fix in the VM to honour the Throwable immutability > protocol that was defined for Java 7. Pre-allocated Throwable > instances are normally immutable, but that is not the case for a group > of pre-allocated OutOfMemoryError instances. To conform to the > protocol, when we set the backtrace (VM representation of the > stackTrace) we have to set the stackTrace field to the sentinel value > stored in the static Throwable.UNASSIGNED_STACK field. > > With this fix in place the workaround in Throwable.java, under > 7045138, can be backed out. > > Thanks, > David > > > From David.Holmes at oracle.com Mon Jul 18 21:02:45 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 19 Jul 2011 14:02:45 +1000 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E24FAB6.2030305@oracle.com> References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> Message-ID: <4E2501E5.8020205@oracle.com> Paul Hohensee said the following on 07/19/11 13:32: > Looks good, except, could you use obj_field() in unassigned_stacktrace() > instead of checking UseCompressedOops there? Thanks Paul. I don't think I can use obj_field() as it is for accessing instances and this is a static field. I copied the code for reading the static field from the java.lang.ref functions: 2286 // Support for java_lang_ref_Reference 2287 oop java_lang_ref_Reference::pending_list_lock() { 2288 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); 2289 address addr = ik->static_field_addr(static_lock_offset); 2290 if (UseCompressedOops) { 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); 2292 } else { 2293 return oopDesc::load_decode_heap_oop((oop*)addr); 2294 } 2295 } 2296 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { 2298 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); 2299 address addr = ik->static_field_addr(static_pending_offset); 2300 // XXX This might not be HeapWord aligned, almost rather be char *. 2301 return (HeapWord*)addr; 2302 } 2303 2304 oop java_lang_ref_Reference::pending_list() { 2305 char *addr = (char *)pending_list_addr(); 2306 if (UseCompressedOops) { 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); 2308 } else { 2309 return oopDesc::load_decode_heap_oop((oop*)addr); 2310 } 2311 } David ----- > > Paul > > On 7/7/11 1:25 AM, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >> >> This is a simple fix in the VM to honour the Throwable immutability >> protocol that was defined for Java 7. Pre-allocated Throwable >> instances are normally immutable, but that is not the case for a group >> of pre-allocated OutOfMemoryError instances. To conform to the >> protocol, when we set the backtrace (VM representation of the >> stackTrace) we have to set the stackTrace field to the sentinel value >> stored in the static Throwable.UNASSIGNED_STACK field. >> >> With this fix in place the workaround in Throwable.java, under >> 7045138, can be backed out. >> >> Thanks, >> David >> >> >> From paul.hohensee at oracle.com Tue Jul 19 05:33:06 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 19 Jul 2011 08:33:06 -0400 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E2501E5.8020205@oracle.com> References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> <4E2501E5.8020205@oracle.com> Message-ID: <4E257982.6050300@oracle.com> Ok. Paul On 7/19/11 12:02 AM, David Holmes wrote: > Paul Hohensee said the following on 07/19/11 13:32: >> Looks good, except, could you use obj_field() in >> unassigned_stacktrace() instead of checking UseCompressedOops there? > > Thanks Paul. > > I don't think I can use obj_field() as it is for accessing instances > and this is a static field. I copied the code for reading the static > field from the java.lang.ref functions: > > 2286 // Support for java_lang_ref_Reference > 2287 oop java_lang_ref_Reference::pending_list_lock() { > 2288 instanceKlass* ik = > instanceKlass::cast(SystemDictionary::Reference_klass()); > 2289 address addr = ik->static_field_addr(static_lock_offset); > 2290 if (UseCompressedOops) { > 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); > 2292 } else { > 2293 return oopDesc::load_decode_heap_oop((oop*)addr); > 2294 } > 2295 } > 2296 > 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { > 2298 instanceKlass* ik = > instanceKlass::cast(SystemDictionary::Reference_klass()); > 2299 address addr = ik->static_field_addr(static_pending_offset); > 2300 // XXX This might not be HeapWord aligned, almost rather be > char *. > 2301 return (HeapWord*)addr; > 2302 } > 2303 > 2304 oop java_lang_ref_Reference::pending_list() { > 2305 char *addr = (char *)pending_list_addr(); > 2306 if (UseCompressedOops) { > 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); > 2308 } else { > 2309 return oopDesc::load_decode_heap_oop((oop*)addr); > 2310 } > 2311 } > > David > ----- > >> >> Paul >> >> On 7/7/11 1:25 AM, David Holmes wrote: >>> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >>> >>> This is a simple fix in the VM to honour the Throwable immutability >>> protocol that was defined for Java 7. Pre-allocated Throwable >>> instances are normally immutable, but that is not the case for a >>> group of pre-allocated OutOfMemoryError instances. To conform to the >>> protocol, when we set the backtrace (VM representation of the >>> stackTrace) we have to set the stackTrace field to the sentinel >>> value stored in the static Throwable.UNASSIGNED_STACK field. >>> >>> With this fix in place the workaround in Throwable.java, under >>> 7045138, can be backed out. >>> >>> Thanks, >>> David >>> >>> >>> From tom.rodriguez at oracle.com Tue Jul 19 07:09:42 2011 From: tom.rodriguez at oracle.com (Thomas Rodriguez) Date: Tue, 19 Jul 2011 07:09:42 -0700 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E2501E5.8020205@oracle.com> References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> <4E2501E5.8020205@oracle.com> Message-ID: You can use ik->java_mirror()->obj_field(offset) to read static fields. I don't know why the others are done as they are. maybe just history. tom On Jul 18, 2011, at 9:02 PM, David Holmes wrote: > Paul Hohensee said the following on 07/19/11 13:32: >> Looks good, except, could you use obj_field() in unassigned_stacktrace() instead of checking UseCompressedOops there? > > Thanks Paul. > > I don't think I can use obj_field() as it is for accessing instances and this is a static field. I copied the code for reading the static field from the java.lang.ref functions: > > 2286 // Support for java_lang_ref_Reference > 2287 oop java_lang_ref_Reference::pending_list_lock() { > 2288 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); > 2289 address addr = ik->static_field_addr(static_lock_offset); > 2290 if (UseCompressedOops) { > 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); > 2292 } else { > 2293 return oopDesc::load_decode_heap_oop((oop*)addr); > 2294 } > 2295 } > 2296 > 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { > 2298 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); > 2299 address addr = ik->static_field_addr(static_pending_offset); > 2300 // XXX This might not be HeapWord aligned, almost rather be char *. > 2301 return (HeapWord*)addr; > 2302 } > 2303 > 2304 oop java_lang_ref_Reference::pending_list() { > 2305 char *addr = (char *)pending_list_addr(); > 2306 if (UseCompressedOops) { > 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); > 2308 } else { > 2309 return oopDesc::load_decode_heap_oop((oop*)addr); > 2310 } > 2311 } > > David > ----- > >> Paul >> On 7/7/11 1:25 AM, David Holmes wrote: >>> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >>> >>> This is a simple fix in the VM to honour the Throwable immutability protocol that was defined for Java 7. Pre-allocated Throwable instances are normally immutable, but that is not the case for a group of pre-allocated OutOfMemoryError instances. To conform to the protocol, when we set the backtrace (VM representation of the stackTrace) we have to set the stackTrace field to the sentinel value stored in the static Throwable.UNASSIGNED_STACK field. >>> >>> With this fix in place the workaround in Throwable.java, under 7045138, can be backed out. >>> >>> Thanks, >>> David >>> >>> >>> From volker.simonis at gmail.com Tue Jul 19 10:02:39 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Jul 2011 19:02:39 +0200 Subject: Problems with 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Message-ID: The change "7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls" (http://hg.openjdk.java.net/hsx/hsx21/master/rev/5def270bc147) has several problems: 1. The first problem is that the initialization of the PSApi library has been removed from os::init_2(): - // initialize PSAPI or ToolHelp for fatal error handler - if (win32::is_nt()) _init_psapi(); - else _init_toolhelp(); but not all clients which use its functionality have been updated. The function '_addr_in_ntdll()' calls 'os::PSApiDll::GetModuleInformation()' without a check if the PSApiDll module is initialized. This probably hasn't been detected until now because '_addr_in_ntdll()' is only called if 'UseVectoredExceptions' is true which is no the case by default. I'd suggest to change '_addr_in_ntdll()' such that it checks for the availability of the PSApi dll: static bool _addr_in_ntdll( address addr ) { HMODULE hmod; MODULEINFO minfo; if (!os::PSApiDll::PSApiAvailable()) { // I'm not sure what I should return here. I think PSApi should always be // available and thus PSApiAvailable() should always return 'true'. // Notice that before HS20 the initialization of the PSApi happened in // os::init_2() by calling _init_psapi(); guarantee(false, "PSApi must be available!"); return false; } hmod = GetModuleHandle("NTDLL.DLL"); if ( hmod == NULL ) return false; if ( !os::PSApiDll::GetModuleInformation( GetCurrentProcess(), hmod, &minfo, sizeof(MODULEINFO)) ) return false; if ( (addr >= minfo.lpBaseOfDll) && (addr < (address)((uintptr_t)minfo.lpBaseOfDll + (uintptr_t)minfo.SizeOfImage))) return true; else return false; } 2. The second problem is that the detection of whether the HotSpot runs in a JDK6 or JDK7 context is done at compile time and based on the compiler version in os_windows.hpp: // JDK7 requires VS2010 #if _MSC_VER < 1600 #define JDK6_OR_EARLIER 1 #endif This is a setup which will most probably only work in the current Oracle build context! There is already a detection of "JDK6_OR_EARLIER" in make/windows/build.make and a better solution would be to just propagate its value to the compiler predefines as this is done with other variables like for example JRE_RELEASE_VER Regards, Volker From David.Holmes at oracle.com Wed Jul 20 02:26:04 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 20 Jul 2011 19:26:04 +1000 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> <4E2501E5.8020205@oracle.com> Message-ID: <4E269F2C.60108@oracle.com> Hi Tom, Thomas Rodriguez said the following on 07/20/11 00:09: > You can use ik->java_mirror()->obj_field(offset) to read static fields. I don't know why the others are done as they are. maybe just history. Is there a different way to calculate the offset in this case? I tried this using the existing static_unassigned_stacktrace_offset and while I had no problems reading that value and setting it into the Throwable, as soon as I tried to access the stacktrace field containing that value I got a SEGV in LinkResolver::resolve_invokevirtual I must admit I was a bit puzzled by your suggestion. The java_mirror() is the oop for the Class object, but I didn't think that we stored static fields as instance fields of the Class object ??? Thanks, David > tom > > On Jul 18, 2011, at 9:02 PM, David Holmes wrote: > >> Paul Hohensee said the following on 07/19/11 13:32: >>> Looks good, except, could you use obj_field() in unassigned_stacktrace() instead of checking UseCompressedOops there? >> Thanks Paul. >> >> I don't think I can use obj_field() as it is for accessing instances and this is a static field. I copied the code for reading the static field from the java.lang.ref functions: >> >> 2286 // Support for java_lang_ref_Reference >> 2287 oop java_lang_ref_Reference::pending_list_lock() { >> 2288 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >> 2289 address addr = ik->static_field_addr(static_lock_offset); >> 2290 if (UseCompressedOops) { >> 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >> 2292 } else { >> 2293 return oopDesc::load_decode_heap_oop((oop*)addr); >> 2294 } >> 2295 } >> 2296 >> 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { >> 2298 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >> 2299 address addr = ik->static_field_addr(static_pending_offset); >> 2300 // XXX This might not be HeapWord aligned, almost rather be char *. >> 2301 return (HeapWord*)addr; >> 2302 } >> 2303 >> 2304 oop java_lang_ref_Reference::pending_list() { >> 2305 char *addr = (char *)pending_list_addr(); >> 2306 if (UseCompressedOops) { >> 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >> 2308 } else { >> 2309 return oopDesc::load_decode_heap_oop((oop*)addr); >> 2310 } >> 2311 } >> >> David >> ----- >> >>> Paul >>> On 7/7/11 1:25 AM, David Holmes wrote: >>>> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >>>> >>>> This is a simple fix in the VM to honour the Throwable immutability protocol that was defined for Java 7. Pre-allocated Throwable instances are normally immutable, but that is not the case for a group of pre-allocated OutOfMemoryError instances. To conform to the protocol, when we set the backtrace (VM representation of the stackTrace) we have to set the stackTrace field to the sentinel value stored in the static Throwable.UNASSIGNED_STACK field. >>>> >>>> With this fix in place the workaround in Throwable.java, under 7045138, can be backed out. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> From rednaxelafx at gmail.com Wed Jul 20 07:44:35 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 20 Jul 2011 07:44:35 -0700 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E269F2C.60108@oracle.com> References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> <4E2501E5.8020205@oracle.com> <4E269F2C.60108@oracle.com> Message-ID: <5BF2577E-D58B-4454-89F5-CC24F8973CC0@gmail.com> Hi David, Following the mailing list, moving the static fields from instanceKlass into java.lang.Class was a part of the recent steps to remove PermGen, as far as I understand. Regards, Kris Mok On 2011-7-20, at 2:26, David Holmes wrote: > Hi Tom, > > Thomas Rodriguez said the following on 07/20/11 00:09: >> You can use ik->java_mirror()->obj_field(offset) to read static fields. I don't know why the others are done as they are. maybe just history. > > Is there a different way to calculate the offset in this case? I tried this using the existing static_unassigned_stacktrace_offset and while I had no problems reading that value and setting it into the Throwable, as soon as I tried to access the stacktrace field containing that value I got a SEGV in LinkResolver::resolve_invokevirtual > > I must admit I was a bit puzzled by your suggestion. The java_mirror() is the oop for the Class object, but I didn't think that we stored static fields as instance fields of the Class object ??? > > Thanks, > David > >> tom >> On Jul 18, 2011, at 9:02 PM, David Holmes wrote: >>> Paul Hohensee said the following on 07/19/11 13:32: >>>> Looks good, except, could you use obj_field() in unassigned_stacktrace() instead of checking UseCompressedOops there? >>> Thanks Paul. >>> >>> I don't think I can use obj_field() as it is for accessing instances and this is a static field. I copied the code for reading the static field from the java.lang.ref functions: >>> >>> 2286 // Support for java_lang_ref_Reference >>> 2287 oop java_lang_ref_Reference::pending_list_lock() { >>> 2288 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >>> 2289 address addr = ik->static_field_addr(static_lock_offset); >>> 2290 if (UseCompressedOops) { >>> 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >>> 2292 } else { >>> 2293 return oopDesc::load_decode_heap_oop((oop*)addr); >>> 2294 } >>> 2295 } >>> 2296 >>> 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { >>> 2298 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >>> 2299 address addr = ik->static_field_addr(static_pending_offset); >>> 2300 // XXX This might not be HeapWord aligned, almost rather be char *. >>> 2301 return (HeapWord*)addr; >>> 2302 } >>> 2303 >>> 2304 oop java_lang_ref_Reference::pending_list() { >>> 2305 char *addr = (char *)pending_list_addr(); >>> 2306 if (UseCompressedOops) { >>> 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >>> 2308 } else { >>> 2309 return oopDesc::load_decode_heap_oop((oop*)addr); >>> 2310 } >>> 2311 } >>> >>> David >>> ----- >>> >>>> Paul >>>> On 7/7/11 1:25 AM, David Holmes wrote: >>>>> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >>>>> >>>>> This is a simple fix in the VM to honour the Throwable immutability protocol that was defined for Java 7. Pre-allocated Throwable instances are normally immutable, but that is not the case for a group of pre-allocated OutOfMemoryError instances. To conform to the protocol, when we set the backtrace (VM representation of the stackTrace) we have to set the stackTrace field to the sentinel value stored in the static Throwable.UNASSIGNED_STACK field. >>>>> >>>>> With this fix in place the workaround in Throwable.java, under 7045138, can be backed out. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> From zhengyu.gu at oracle.com Wed Jul 20 07:46:36 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 20 Jul 2011 10:46:36 -0400 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> Message-ID: <4E26EA4C.6020105@oracle.com> Hi, Sorry for delay. I am having trouble to upload webrev to cr.openjdk.java.net, probably due to re-ip here. This revision, Decoder class is reverted back to AllStatic. Decoder::initialize() is added at Step 60, and Decoder won't be uninitialized. Here is the link to internal webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ Here is the diff: bash-3.00$ hg diff diff --git a/src/share/vm/utilities/decoder.hpp b/src/share/vm/utilities/decoder.hpp --- a/src/share/vm/utilities/decoder.hpp +++ b/src/share/vm/utilities/decoder.hpp @@ -45,7 +45,7 @@ class ElfFile; #endif // _WINDOWS -class Decoder: public StackObj { +class Decoder: AllStatic { public: // status code for decoding native C frame @@ -61,9 +61,6 @@ class Decoder: public StackObj { }; public: - Decoder() { initialize(); }; - ~Decoder() { uninitialize(); }; - static bool can_decode_C_frame_in_vm(); static void initialize(); diff --git a/src/share/vm/utilities/vmError.cpp b/src/share/vm/utilities/vmError.cpp --- a/src/share/vm/utilities/vmError.cpp +++ b/src/share/vm/utilities/vmError.cpp @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { ); STEP(60, "(printing problematic frame)") + // initialize decoder to decode C frames + Decoder::initialize(); // Print current frame if we have a context (i.e. it's a crash) if (_context) { @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { // see if it's a valid frame if (fr.pc()) { st->print_cr("Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)"); - - // initialize decoder to decode C frames - Decoder decoder; int count = 0; while (count++ < StackPrintLimit) { Thanks, -Zhengyu On 7/18/2011 10:24 AM, Volker Simonis wrote: > On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu wrote: >> I have to disagree, I would much prefer to revert back it AllStatic >> implementation. Followings are the reasons: >> >> 1. Uninitialize() was intended to shutdown decoder in low memory scenarios, >> as the decoder is a secondary function. It may not be very clear in this >> usecase, but it is a scenario in the project I am currently working on. >> > I don't know what project you are working on, but in the Hotspot as we > can see it, the Decoder::decode() functionality is only accessed from > os::dll_address_to_function_name(). This in turn is only called from > two places: > - from the VM error handler (in vmError.cpp) trough > frame::print_on_error() which calls it trough print_C_frame() > - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() > >> 2. Performance: Initial/uninitial decoder for decoding every symbol, >> definitely not optimal. In Unix implementation, it was programmed to >> maintain a symbol cache, which will not completely defeated, as it has to >> reopen/reparse elf file to decoder every frame. Again, decoder performance >> will be one of key factors for my other project. > I didn't propose to create a new Decoder object for the decoding of > each symbol. Instead a decoder object could be passed into > os::dll_address_to_function_name() and frame::print_on_error(). The > user of the functionality could then decide how long he wants to keep > the Decoder object and its resources alive. In the case of the > FlatProfiler this would probably be the whole VM lifetime, for the > vmError use case it would be probably for the time of a complete stack > trace. > >> I will post new webrev to reflect AllStatic implementation. >> >> Thanks, >> >> -Zhengyu >> >> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>> What about making the Decoder::decode() and all the other methods in >>> the Decoder class instance methods? >>> Then it would be clear that users of the decode() method would have to >>> create (and initialize) a Decode object and it would be their >>> responsibility when they create it and and when they uninitialize and >>> clean it up. Depending on the platform, the Decoder class may still >>> decide to keep its resources globally (as static data members) or just >>> for the lifetime of a Decoder object. >>> >>> With the current solution the problem is (as pointed out by David) >>> that it is not clear for callers if they have to do initialization or >>> not, and this even differs between Unix and Windows. >>> >>> @Zhengyu: will you prepare a new webrev or should I submit one? >>> >>> Regards, >>> Vovlker >>> >>> On Sat, Jul 16, 2011 at 12:59 AM, David Holmes >>> wrote: >>>> John Coomes said the following on 07/16/11 07:01: >>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>> Forward to openjdk for review: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>> The change looks correct. >>>>> >>>>> It's not new in this change, but I find it strange that static >>>>> initialization of Decoder is triggered by creating an unused instance. >>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>> there'd be no need for the comment: >>>>> >>>>> // initialize decoder to decode C frames >>>>> >>>>> Decoder should also be changed to inherit from AllStatic instead of >>>>> StackObj, but that's getting beyond this bug fix. >>>> This is extremely confusing code. We have static data being manipulated >>>> by >>>> stack-scoped local instances, where the constructor does an initialize >>>> function and the destructor does an uninitalize that cleans up various >>>> resources. In addition we have a static function on Windows: >>>> >>>> bool Decoder::can_decode_C_frame_in_vm() { >>>> initialize(); >>>> return _can_decode_in_vm; >>>> } >>>> >>>> which initializes but never cleans up! And the use of these two mechanism >>>> can be interspersed. >>>> >>>> To top it off we create the Decoder instances in places where there is >>>> absolutely no indication that somewhere down in the call chain the >>>> Decoder >>>> functionality will be used! This is truly awful code. >>>> >>>> Volker's patch to move the Decoder into print_C_frame would seem much >>>> cleaner, but even it doesn't go far enough as we have redundant >>>> initialize() >>>> in can_decode_C_frame_in_vm, and I don't see why we should be working >>>> with >>>> static functions instead of the Decoder object that was created. >>>> >>>> Zhengyu is concerned that the repeated init/un-init might be too much if >>>> moved into print_C_frame, but his fix goes to the other extreme by giving >>>> the Decoder "global" scope in the error reporting process so we won't do >>>> any >>>> cleanup until right at the end (where we will presumably terminate the >>>> process) - so this seems to defeat the purpose of having the cleanup code >>>> in >>>> the first place. >>>> >>>> Given that we are in the process of dying I don't see that we should be >>>> overly concerned about overhead so I'd be inclined to go with Volker's >>>> fix >>>> and at least do the init and cleanup in the location where the Decoder is >>>> actually used. >>>> >>>> David >>>> ----- >>>> >>>> >>>>> -John >>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: Code review request: 7067266 Decoder class not >>>>>> properly initialized on Windows >>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>> From: Daniel D. Daugherty >>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>> To: Zhengyu Gu >>>>>> CC: hotspot-runtime-dev-confidential >>>>>> , volker-simonis at gmail.com >>>>>> >>>>>> >>>>>> >>>>>> Thumbs up on the code. >>>>>> >>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>> so this review should go out on that alias also (and the webrev >>>>>> copied to cr.openjdk.java.net) >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>> This is a simple fix that moves Decoder initialization to step 60 in >>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs file >>>>>>> header. >>>>>>> >>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>> from SAP with proposed patch. The >>>>>>> solution >>>>>>> was to move decoder initialization code to >>>>>>> print_C_frame() function, but it is less optimal, since decoder will >>>>>>> have to be initialized and uninitialized every time in/out of the >>>>>>> print_C_frame() function. >>>>>>> >>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>> >>>>>>> Testcase: >>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>> >>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, jclass) >>>>>>> { >>>>>>> int* p = NULL; >>>>>>> *p = 1; >>>>>>> } >>>>>>> >>>>>>> Without fix, hs file header: >>>>>>> >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, pid=7860, >>>>>>> tid=4140 >>>>>>> # >>>>>>> # JRE version: 6.0_23-b05 >>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>>>>> windows-x86 ) >>>>>>> # Problematic frame: >>>>>>> # C [mydll.dll+0x11308] >>>>>>> # >>>>>>> # If you would like to submit a bug report, please visit: >>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>>>> # See problematic frame for where to report the bug. >>>>>>> # >>>>>>> >>>>>>> >>>>>>> With fix: >>>>>>> >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, pid=1652, >>>>>>> tid=5964 >>>>>>> # >>>>>>> # JRE version: 6.0_23-b05 >>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>>>>> windows-x86 ) >>>>>>> # Problematic frame: >>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>> # >>>>>>> # Failed to write core dump. Minidumps are not enabled by default on >>>>>>> client versions of Windows >>>>>>> # >>>>>>> # If you would like to submit a bug report, please visit: >>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>> # The crash happened outside the Java Virtual Machine in native code. >>>>>>> # See problematic frame for where to report the bug. >>>>>>> # >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >> From volker.simonis at gmail.com Wed Jul 20 08:29:01 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Jul 2011 17:29:01 +0200 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E26EA4C.6020105@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> Message-ID: I must say that I in general don't like the idea to have a static method which is dependent on another static method being called before. This is just an implicit dependency which is not documented nor enforced anywhere. Your patch may fix the current problem, but what if somebody will use VMError::print_stack_trace() or frame::print_on_error() in the future. How can he know that he will have to initialize Decoder first? Regards, Volker On Wed, Jul 20, 2011 at 4:46 PM, Zhengyu Gu wrote: > Hi, > > Sorry for delay. I am having trouble to upload webrev to > cr.openjdk.java.net, probably due to re-ip here. > > This revision, Decoder class is reverted back to AllStatic. > Decoder::initialize() is added at Step 60, and Decoder won't be > uninitialized. > > Here is the link to internal webrev: > http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ > > Here is the diff: > > bash-3.00$ hg diff > diff --git a/src/share/vm/utilities/decoder.hpp > b/src/share/vm/utilities/decoder.hpp > --- a/src/share/vm/utilities/decoder.hpp > +++ b/src/share/vm/utilities/decoder.hpp > @@ -45,7 +45,7 @@ class ElfFile; > ?#endif // _WINDOWS > > > -class Decoder: public StackObj { > +class Decoder: AllStatic { > > ?public: > ? // status code for decoding native C frame > @@ -61,9 +61,6 @@ class Decoder: public StackObj { > ? }; > > ?public: > - ?Decoder() { initialize(); }; > - ?~Decoder() { uninitialize(); }; > - > ? static bool can_decode_C_frame_in_vm(); > > ? static void initialize(); > diff --git a/src/share/vm/utilities/vmError.cpp > b/src/share/vm/utilities/vmError.cpp > --- a/src/share/vm/utilities/vmError.cpp > +++ b/src/share/vm/utilities/vmError.cpp > @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { > ? ? ? ? ? ? ? ? ?); > > ? STEP(60, "(printing problematic frame)") > + ? ? ?// initialize decoder to decode C frames > + ? ? ?Decoder::initialize(); > > ? ? ?// Print current frame if we have a context (i.e. it's a crash) > ? ? ?if (_context) { > @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { > ? ? ? ?// see if it's a valid frame > ? ? ? ?if (fr.pc()) { > ? ? ? ? ? st->print_cr("Native frames: (J=compiled Java code, j=interpreted, > Vv=VM code, C=native code)"); > - > - ? ? ? ? ?// initialize decoder to decode C frames > - ? ? ? ? ?Decoder decoder; > > ? ? ? ? ? int count = 0; > ? ? ? ? ? while (count++ < StackPrintLimit) { > > > Thanks, > > -Zhengyu > > > On 7/18/2011 10:24 AM, Volker Simonis wrote: >> >> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu ?wrote: >>> >>> I have to disagree, I would much prefer to revert back it AllStatic >>> implementation. Followings are the reasons: >>> >>> 1. Uninitialize() was intended to shutdown decoder in low memory >>> scenarios, >>> as the decoder is a secondary function. It may not be very clear in this >>> usecase, but it is a scenario in the project I am currently working on. >>> >> I don't know what project you are working on, but in the Hotspot as we >> can see it, the Decoder::decode() functionality is only accessed from >> os::dll_address_to_function_name(). This in turn is only called from >> two places: >> - from the VM error handler (in vmError.cpp) trough >> frame::print_on_error() which calls it trough print_C_frame() >> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >> >>> 2. Performance: Initial/uninitial decoder for decoding every symbol, >>> definitely not optimal. In Unix implementation, it was programmed to >>> maintain a symbol cache, which will not completely defeated, as it has to >>> reopen/reparse elf file to decoder every frame. Again, decoder >>> performance >>> will be one of key factors for my other project. >> >> I didn't propose to create a new Decoder object for the decoding of >> each symbol. Instead a decoder object could be passed into >> os::dll_address_to_function_name() and ?frame::print_on_error(). The >> user of the functionality could then decide how long he wants to keep >> the Decoder object and its resources alive. In the case of the >> FlatProfiler this would probably be the whole VM lifetime, for the >> vmError use case it would be probably for the time of a complete stack >> trace. >> >>> I will post new webrev to reflect AllStatic implementation. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>> >>>> What about making the Decoder::decode() and all the other methods in >>>> the Decoder class instance methods? >>>> Then it would be clear that users of the decode() method would have to >>>> create (and initialize) a Decode object and it would be their >>>> responsibility when they create it and and when they uninitialize and >>>> clean it up. Depending on the platform, the Decoder class may still >>>> decide to keep its resources globally (as static data members) or just >>>> for the lifetime of a Decoder object. >>>> >>>> With the current solution the problem is (as pointed out by David) >>>> that it is not clear for callers if they have to do initialization or >>>> not, and this even differs between Unix and Windows. >>>> >>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>> >>>> Regards, >>>> Vovlker >>>> >>>> On Sat, Jul 16, 2011 at 12:59 AM, David Holmes >>>> ?wrote: >>>>> >>>>> John Coomes said the following on 07/16/11 07:01: >>>>>> >>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>> >>>>>>> Forward to openjdk for review: >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>> >>>>>> The change looks correct. >>>>>> >>>>>> It's not new in this change, but I find it strange that static >>>>>> initialization of Decoder is triggered by creating an unused instance. >>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>> there'd be no need for the comment: >>>>>> >>>>>> ? ? ? ?// initialize decoder to decode C frames >>>>>> >>>>>> Decoder should also be changed to inherit from AllStatic instead of >>>>>> StackObj, but that's getting beyond this bug fix. >>>>> >>>>> This is extremely confusing code. We have static data being manipulated >>>>> by >>>>> stack-scoped local instances, where the constructor does an initialize >>>>> function and the destructor does an uninitalize that cleans up various >>>>> resources. In addition we have a static function on Windows: >>>>> >>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>> ?initialize(); >>>>> ?return ?_can_decode_in_vm; >>>>> } >>>>> >>>>> which initializes but never cleans up! And the use of these two >>>>> mechanism >>>>> can be interspersed. >>>>> >>>>> To top it off we create the Decoder instances in places where there is >>>>> absolutely no indication that somewhere down in the call chain the >>>>> Decoder >>>>> functionality will be used! This is truly awful code. >>>>> >>>>> Volker's patch to move the Decoder into print_C_frame would seem much >>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>> initialize() >>>>> in can_decode_C_frame_in_vm, and I don't see why we should be working >>>>> with >>>>> static functions instead of the Decoder object that was created. >>>>> >>>>> Zhengyu is concerned that the repeated init/un-init might be too much >>>>> if >>>>> moved into print_C_frame, but his fix goes to the other extreme by >>>>> giving >>>>> the Decoder "global" scope in the error reporting process so we won't >>>>> do >>>>> any >>>>> cleanup until right at the end (where we will presumably terminate the >>>>> process) - so this seems to defeat the purpose of having the cleanup >>>>> code >>>>> in >>>>> the first place. >>>>> >>>>> Given that we are in the process of dying I don't see that we should be >>>>> overly concerned about overhead so I'd be inclined to go with Volker's >>>>> fix >>>>> and at least do the init and cleanup in the location where the Decoder >>>>> is >>>>> actually used. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> -John >>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: ? ? ? ?Re: Code review request: 7067266 Decoder class not >>>>>>> properly initialized on Windows >>>>>>> Date: ? Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>> From: ? Daniel D. Daugherty >>>>>>> Reply-To: ? ? ? daniel.daugherty at oracle.com >>>>>>> To: ? ? Zhengyu Gu >>>>>>> CC: ? ? hotspot-runtime-dev-confidential >>>>>>> , volker-simonis at gmail.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thumbs up on the code. >>>>>>> >>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>> so this review should go out on that alias also (and the webrev >>>>>>> copied to cr.openjdk.java.net) >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>> >>>>>>>> This is a simple fix that moves Decoder initialization to step 60 in >>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs >>>>>>>> file >>>>>>>> header. >>>>>>>> >>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>> ? ?from SAP with proposed patch. >>>>>>>> The >>>>>>>> solution >>>>>>>> was to move decoder initialization code to >>>>>>>> print_C_frame() function, but it is less optimal, since decoder will >>>>>>>> have to be initialized and uninitialized every time in/out of the >>>>>>>> print_C_frame() function. >>>>>>>> >>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>> >>>>>>>> Testcase: >>>>>>>> ?A simple Java program with JNI call that crashes VM: >>>>>>>> >>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>> jclass) >>>>>>>> { >>>>>>>> ?int* p = NULL; >>>>>>>> ?*p = 1; >>>>>>>> } >>>>>>>> >>>>>>>> Without fix, hs file header: >>>>>>>> >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>> pid=7860, >>>>>>>> tid=4140 >>>>>>>> # >>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>>>>>> windows-x86 ) >>>>>>>> # Problematic frame: >>>>>>>> # C ?[mydll.dll+0x11308] >>>>>>>> # >>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>> code. >>>>>>>> # See problematic frame for where to report the bug. >>>>>>>> # >>>>>>>> >>>>>>>> >>>>>>>> With fix: >>>>>>>> >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # ?EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>> pid=1652, >>>>>>>> tid=5964 >>>>>>>> # >>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>>>>>> windows-x86 ) >>>>>>>> # Problematic frame: >>>>>>>> # C ?[mydll.dll+0x11308] ?Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>> # >>>>>>>> # Failed to write core dump. Minidumps are not enabled by default on >>>>>>>> client versions of Windows >>>>>>>> # >>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>> code. >>>>>>>> # See problematic frame for where to report the bug. >>>>>>>> # >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Zhengyu >>> > > From daniel.daugherty at oracle.com Wed Jul 20 08:54:30 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Jul 2011 09:54:30 -0600 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E26EA4C.6020105@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> Message-ID: <4E26FA36.8030408@oracle.com> Zhengyu, I just tried to access your previous webrev on cr.openjdk.java.net without any issues. I don't know whether your upload issue was transient or not, but it is possible that you can upload the revised webrev now. The webrev URL below doesn't do Volker or anyone else on the OpenJDK alias any good so getting a webrev uploaded as soon as possible would be a good thing... Dan On 7/20/11 8:46 AM, Zhengyu Gu wrote: > Hi, > > Sorry for delay. I am having trouble to upload webrev to > cr.openjdk.java.net, probably due to re-ip here. > > This revision, Decoder class is reverted back to AllStatic. > Decoder::initialize() is added at Step 60, and Decoder won't be > uninitialized. > > Here is the link to internal webrev: > http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ > > Here is the diff: > > bash-3.00$ hg diff > diff --git a/src/share/vm/utilities/decoder.hpp > b/src/share/vm/utilities/decoder.hpp > --- a/src/share/vm/utilities/decoder.hpp > +++ b/src/share/vm/utilities/decoder.hpp > @@ -45,7 +45,7 @@ class ElfFile; > #endif // _WINDOWS > > > -class Decoder: public StackObj { > +class Decoder: AllStatic { > > public: > // status code for decoding native C frame > @@ -61,9 +61,6 @@ class Decoder: public StackObj { > }; > > public: > - Decoder() { initialize(); }; > - ~Decoder() { uninitialize(); }; > - > static bool can_decode_C_frame_in_vm(); > > static void initialize(); > diff --git a/src/share/vm/utilities/vmError.cpp > b/src/share/vm/utilities/vmError.cpp > --- a/src/share/vm/utilities/vmError.cpp > +++ b/src/share/vm/utilities/vmError.cpp > @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { > ); > > STEP(60, "(printing problematic frame)") > + // initialize decoder to decode C frames > + Decoder::initialize(); > > // Print current frame if we have a context (i.e. it's a crash) > if (_context) { > @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { > // see if it's a valid frame > if (fr.pc()) { > st->print_cr("Native frames: (J=compiled Java code, > j=interpreted, Vv=VM code, C=native code)"); > - > - // initialize decoder to decode C frames > - Decoder decoder; > > int count = 0; > while (count++ < StackPrintLimit) { > > > Thanks, > > -Zhengyu > > > On 7/18/2011 10:24 AM, Volker Simonis wrote: >> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu >> wrote: >>> I have to disagree, I would much prefer to revert back it AllStatic >>> implementation. Followings are the reasons: >>> >>> 1. Uninitialize() was intended to shutdown decoder in low memory >>> scenarios, >>> as the decoder is a secondary function. It may not be very clear in >>> this >>> usecase, but it is a scenario in the project I am currently working on. >>> >> I don't know what project you are working on, but in the Hotspot as we >> can see it, the Decoder::decode() functionality is only accessed from >> os::dll_address_to_function_name(). This in turn is only called from >> two places: >> - from the VM error handler (in vmError.cpp) trough >> frame::print_on_error() which calls it trough print_C_frame() >> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >> >>> 2. Performance: Initial/uninitial decoder for decoding every symbol, >>> definitely not optimal. In Unix implementation, it was programmed to >>> maintain a symbol cache, which will not completely defeated, as it >>> has to >>> reopen/reparse elf file to decoder every frame. Again, decoder >>> performance >>> will be one of key factors for my other project. >> I didn't propose to create a new Decoder object for the decoding of >> each symbol. Instead a decoder object could be passed into >> os::dll_address_to_function_name() and frame::print_on_error(). The >> user of the functionality could then decide how long he wants to keep >> the Decoder object and its resources alive. In the case of the >> FlatProfiler this would probably be the whole VM lifetime, for the >> vmError use case it would be probably for the time of a complete stack >> trace. >> >>> I will post new webrev to reflect AllStatic implementation. >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>> What about making the Decoder::decode() and all the other methods in >>>> the Decoder class instance methods? >>>> Then it would be clear that users of the decode() method would have to >>>> create (and initialize) a Decode object and it would be their >>>> responsibility when they create it and and when they uninitialize and >>>> clean it up. Depending on the platform, the Decoder class may still >>>> decide to keep its resources globally (as static data members) or just >>>> for the lifetime of a Decoder object. >>>> >>>> With the current solution the problem is (as pointed out by David) >>>> that it is not clear for callers if they have to do initialization or >>>> not, and this even differs between Unix and Windows. >>>> >>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>> >>>> Regards, >>>> Vovlker >>>> >>>> On Sat, Jul 16, 2011 at 12:59 AM, David >>>> Holmes >>>> wrote: >>>>> John Coomes said the following on 07/16/11 07:01: >>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>> Forward to openjdk for review: >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>> The change looks correct. >>>>>> >>>>>> It's not new in this change, but I find it strange that static >>>>>> initialization of Decoder is triggered by creating an unused >>>>>> instance. >>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>> there'd be no need for the comment: >>>>>> >>>>>> // initialize decoder to decode C frames >>>>>> >>>>>> Decoder should also be changed to inherit from AllStatic instead of >>>>>> StackObj, but that's getting beyond this bug fix. >>>>> This is extremely confusing code. We have static data being >>>>> manipulated >>>>> by >>>>> stack-scoped local instances, where the constructor does an >>>>> initialize >>>>> function and the destructor does an uninitalize that cleans up >>>>> various >>>>> resources. In addition we have a static function on Windows: >>>>> >>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>> initialize(); >>>>> return _can_decode_in_vm; >>>>> } >>>>> >>>>> which initializes but never cleans up! And the use of these two >>>>> mechanism >>>>> can be interspersed. >>>>> >>>>> To top it off we create the Decoder instances in places where >>>>> there is >>>>> absolutely no indication that somewhere down in the call chain the >>>>> Decoder >>>>> functionality will be used! This is truly awful code. >>>>> >>>>> Volker's patch to move the Decoder into print_C_frame would seem much >>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>> initialize() >>>>> in can_decode_C_frame_in_vm, and I don't see why we should be working >>>>> with >>>>> static functions instead of the Decoder object that was created. >>>>> >>>>> Zhengyu is concerned that the repeated init/un-init might be too >>>>> much if >>>>> moved into print_C_frame, but his fix goes to the other extreme by >>>>> giving >>>>> the Decoder "global" scope in the error reporting process so we >>>>> won't do >>>>> any >>>>> cleanup until right at the end (where we will presumably terminate >>>>> the >>>>> process) - so this seems to defeat the purpose of having the >>>>> cleanup code >>>>> in >>>>> the first place. >>>>> >>>>> Given that we are in the process of dying I don't see that we >>>>> should be >>>>> overly concerned about overhead so I'd be inclined to go with >>>>> Volker's >>>>> fix >>>>> and at least do the init and cleanup in the location where the >>>>> Decoder is >>>>> actually used. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> -John >>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: Code review request: 7067266 Decoder class not >>>>>>> properly initialized on Windows >>>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>> From: Daniel D. Daugherty >>>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>>> To: Zhengyu Gu >>>>>>> CC: hotspot-runtime-dev-confidential >>>>>>> , >>>>>>> volker-simonis at gmail.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thumbs up on the code. >>>>>>> >>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>> so this review should go out on that alias also (and the webrev >>>>>>> copied to cr.openjdk.java.net) >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>> This is a simple fix that moves Decoder initialization to step >>>>>>>> 60 in >>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in >>>>>>>> hs file >>>>>>>> header. >>>>>>>> >>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>> from SAP with proposed >>>>>>>> patch. The >>>>>>>> solution >>>>>>>> was to move decoder initialization code to >>>>>>>> print_C_frame() function, but it is less optimal, since decoder >>>>>>>> will >>>>>>>> have to be initialized and uninitialized every time in/out of the >>>>>>>> print_C_frame() function. >>>>>>>> >>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>> >>>>>>>> Testcase: >>>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>>> >>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>> jclass) >>>>>>>> { >>>>>>>> int* p = NULL; >>>>>>>> *p = 1; >>>>>>>> } >>>>>>>> >>>>>>>> Without fix, hs file header: >>>>>>>> >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>> pid=7860, >>>>>>>> tid=4140 >>>>>>>> # >>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, >>>>>>>> sharing >>>>>>>> windows-x86 ) >>>>>>>> # Problematic frame: >>>>>>>> # C [mydll.dll+0x11308] >>>>>>>> # >>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>> code. >>>>>>>> # See problematic frame for where to report the bug. >>>>>>>> # >>>>>>>> >>>>>>>> >>>>>>>> With fix: >>>>>>>> >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>> pid=1652, >>>>>>>> tid=5964 >>>>>>>> # >>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed >>>>>>>> mode >>>>>>>> windows-x86 ) >>>>>>>> # Problematic frame: >>>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>> # >>>>>>>> # Failed to write core dump. Minidumps are not enabled by >>>>>>>> default on >>>>>>>> client versions of Windows >>>>>>>> # >>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>> code. >>>>>>>> # See problematic frame for where to report the bug. >>>>>>>> # >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Zhengyu >>> > > From tom.rodriguez at oracle.com Wed Jul 20 09:40:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 20 Jul 2011 09:40:31 -0700 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <4E269F2C.60108@oracle.com> References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> <4E2501E5.8020205@oracle.com> <4E269F2C.60108@oracle.com> Message-ID: <85425204-9EBA-45C4-A69C-AEA137537519@oracle.com> On Jul 20, 2011, at 2:26 AM, David Holmes wrote: > Hi Tom, > > Thomas Rodriguez said the following on 07/20/11 00:09: >> You can use ik->java_mirror()->obj_field(offset) to read static fields. I don't know why the others are done as they are. maybe just history. > > Is there a different way to calculate the offset in this case? I tried this using the existing static_unassigned_stacktrace_offset and while I had no problems reading that value and setting it into the Throwable, as soon as I tried to access the stacktrace field containing that value I got a SEGV in LinkResolver::resolve_invokevirtual Sorry, my suggestion uses real offsets but static_field_addr uses an offset from the base of the static field area and I didn't notice that. You really should be looking up the offset using compute_offset instead of hardcoding it though. That will return the real offset needed by obj_field. If you hardcode it then adding static fields to Throwable could create a mismatch between the real layout and the JVM. The Reference static fields have the same problem though I guess we've never cared about the potential mismatch issues. > > I must admit I was a bit puzzled by your suggestion. The java_mirror() is the oop for the Class object, but I didn't think that we stored static fields as instance fields of the Class object ??? That was done as part of 7017732. ik->static_field_addr is doing this behind your back: address instanceKlass::static_field_addr(int offset) { return (address)(offset + instanceMirrorKlass::offset_of_static_fields() + (intptr_t)java_mirror()); } I really should have fixed these uses instead of papering over them. tom > > Thanks, > David > >> tom >> On Jul 18, 2011, at 9:02 PM, David Holmes wrote: >>> Paul Hohensee said the following on 07/19/11 13:32: >>>> Looks good, except, could you use obj_field() in unassigned_stacktrace() instead of checking UseCompressedOops there? >>> Thanks Paul. >>> >>> I don't think I can use obj_field() as it is for accessing instances and this is a static field. I copied the code for reading the static field from the java.lang.ref functions: >>> >>> 2286 // Support for java_lang_ref_Reference >>> 2287 oop java_lang_ref_Reference::pending_list_lock() { >>> 2288 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >>> 2289 address addr = ik->static_field_addr(static_lock_offset); >>> 2290 if (UseCompressedOops) { >>> 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >>> 2292 } else { >>> 2293 return oopDesc::load_decode_heap_oop((oop*)addr); >>> 2294 } >>> 2295 } >>> 2296 >>> 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { >>> 2298 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >>> 2299 address addr = ik->static_field_addr(static_pending_offset); >>> 2300 // XXX This might not be HeapWord aligned, almost rather be char *. >>> 2301 return (HeapWord*)addr; >>> 2302 } >>> 2303 >>> 2304 oop java_lang_ref_Reference::pending_list() { >>> 2305 char *addr = (char *)pending_list_addr(); >>> 2306 if (UseCompressedOops) { >>> 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >>> 2308 } else { >>> 2309 return oopDesc::load_decode_heap_oop((oop*)addr); >>> 2310 } >>> 2311 } >>> >>> David >>> ----- >>> >>>> Paul >>>> On 7/7/11 1:25 AM, David Holmes wrote: >>>>> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >>>>> >>>>> This is a simple fix in the VM to honour the Throwable immutability protocol that was defined for Java 7. Pre-allocated Throwable instances are normally immutable, but that is not the case for a group of pre-allocated OutOfMemoryError instances. To conform to the protocol, when we set the backtrace (VM representation of the stackTrace) we have to set the stackTrace field to the sentinel value stored in the static Throwable.UNASSIGNED_STACK field. >>>>> >>>>> With this fix in place the workaround in Throwable.java, under 7045138, can be backed out. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> From David.Holmes at oracle.com Wed Jul 20 14:17:17 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2011 07:17:17 +1000 Subject: Request for review: 7046490 - Preallocated OOME objects should obey Throwable stack trace protocol In-Reply-To: <85425204-9EBA-45C4-A69C-AEA137537519@oracle.com> References: <4E154353.8070601@oracle.com> <4E24FAB6.2030305@oracle.com> <4E2501E5.8020205@oracle.com> <4E269F2C.60108@oracle.com> <85425204-9EBA-45C4-A69C-AEA137537519@oracle.com> Message-ID: <4E2745DD.6040907@oracle.com> Tom Rodriguez said the following on 07/21/11 02:40: > On Jul 20, 2011, at 2:26 AM, David Holmes wrote: > >> Hi Tom, >> >> Thomas Rodriguez said the following on 07/20/11 00:09: >>> You can use ik->java_mirror()->obj_field(offset) to read static fields. I don't know why the others are done as they are. maybe just history. >> Is there a different way to calculate the offset in this case? I tried this using the existing static_unassigned_stacktrace_offset and while I had no problems reading that value and setting it into the Throwable, as soon as I tried to access the stacktrace field containing that value I got a SEGV in LinkResolver::resolve_invokevirtual > > Sorry, my suggestion uses real offsets but static_field_addr uses an offset from the base of the static field area and I didn't notice that. You really should be looking up the offset using compute_offset instead of hardcoding it though. That will return the real offset needed by obj_field. If you hardcode it then adding static fields to Throwable could create a mismatch between the real layout and the JVM. The Reference static fields have the same problem though I guess we've never cared about the potential mismatch issues. So Throwable is one of the classes that seems to have to use hard-coded offsets - see compute_hard_coded_offsets(). It may be that if I don't try to compute the offset until I actually need it then it might be okay, but this is moving from a trivial fix to something more elaborate. So I'm going to stick with my original fix if that is ok. We can file a RFE to update these old-style static offset calculations to the new scheme. >> I must admit I was a bit puzzled by your suggestion. The java_mirror() is the oop for the Class object, but I didn't think that we stored static fields as instance fields of the Class object ??? > > That was done as part of 7017732. ik->static_field_addr is doing this behind your back: Thanks for the info (and thanks to to Krystal). Hard to keep track of everything these days :) Cheers, David ----- > address instanceKlass::static_field_addr(int offset) { > return (address)(offset + instanceMirrorKlass::offset_of_static_fields() + (intptr_t)java_mirror()); > } > > I really should have fixed these uses instead of papering over them. > > tom > >> Thanks, >> David >> >>> tom >>> On Jul 18, 2011, at 9:02 PM, David Holmes wrote: >>>> Paul Hohensee said the following on 07/19/11 13:32: >>>>> Looks good, except, could you use obj_field() in unassigned_stacktrace() instead of checking UseCompressedOops there? >>>> Thanks Paul. >>>> >>>> I don't think I can use obj_field() as it is for accessing instances and this is a static field. I copied the code for reading the static field from the java.lang.ref functions: >>>> >>>> 2286 // Support for java_lang_ref_Reference >>>> 2287 oop java_lang_ref_Reference::pending_list_lock() { >>>> 2288 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >>>> 2289 address addr = ik->static_field_addr(static_lock_offset); >>>> 2290 if (UseCompressedOops) { >>>> 2291 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >>>> 2292 } else { >>>> 2293 return oopDesc::load_decode_heap_oop((oop*)addr); >>>> 2294 } >>>> 2295 } >>>> 2296 >>>> 2297 HeapWord *java_lang_ref_Reference::pending_list_addr() { >>>> 2298 instanceKlass* ik = instanceKlass::cast(SystemDictionary::Reference_klass()); >>>> 2299 address addr = ik->static_field_addr(static_pending_offset); >>>> 2300 // XXX This might not be HeapWord aligned, almost rather be char *. >>>> 2301 return (HeapWord*)addr; >>>> 2302 } >>>> 2303 >>>> 2304 oop java_lang_ref_Reference::pending_list() { >>>> 2305 char *addr = (char *)pending_list_addr(); >>>> 2306 if (UseCompressedOops) { >>>> 2307 return oopDesc::load_decode_heap_oop((narrowOop *)addr); >>>> 2308 } else { >>>> 2309 return oopDesc::load_decode_heap_oop((oop*)addr); >>>> 2310 } >>>> 2311 } >>>> >>>> David >>>> ----- >>>> >>>>> Paul >>>>> On 7/7/11 1:25 AM, David Holmes wrote: >>>>>> http://cr.openjdk.java.net/~dholmes/7046490/webrev/ >>>>>> >>>>>> This is a simple fix in the VM to honour the Throwable immutability protocol that was defined for Java 7. Pre-allocated Throwable instances are normally immutable, but that is not the case for a group of pre-allocated OutOfMemoryError instances. To conform to the protocol, when we set the backtrace (VM representation of the stackTrace) we have to set the stackTrace field to the sentinel value stored in the static Throwable.UNASSIGNED_STACK field. >>>>>> >>>>>> With this fix in place the workaround in Throwable.java, under 7045138, can be backed out. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> > From David.Holmes at oracle.com Wed Jul 20 14:29:38 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 21 Jul 2011 07:29:38 +1000 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> Message-ID: <4E2748C2.3090600@oracle.com> Volker Simonis said the following on 07/21/11 01:29: > I must say that I in general don't like the idea to have a static > method which is dependent on another static method being called > before. This is just an implicit dependency which is not documented > nor enforced anywhere. > > Your patch may fix the current problem, but what if somebody will use > VMError::print_stack_trace() or frame::print_on_error() in the future. > How can he know that he will have to initialize Decoder first? I have to agree. The initialization code should be called from the methods that need it - as is actually done in one Windows case. Further, if we aren't going to do any cleanup then what is the point of having uninitialize ? Seems to be dead code. David > Regards, > Volker > > On Wed, Jul 20, 2011 at 4:46 PM, Zhengyu Gu wrote: >> Hi, >> >> Sorry for delay. I am having trouble to upload webrev to >> cr.openjdk.java.net, probably due to re-ip here. >> >> This revision, Decoder class is reverted back to AllStatic. >> Decoder::initialize() is added at Step 60, and Decoder won't be >> uninitialized. >> >> Here is the link to internal webrev: >> http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ >> >> Here is the diff: >> >> bash-3.00$ hg diff >> diff --git a/src/share/vm/utilities/decoder.hpp >> b/src/share/vm/utilities/decoder.hpp >> --- a/src/share/vm/utilities/decoder.hpp >> +++ b/src/share/vm/utilities/decoder.hpp >> @@ -45,7 +45,7 @@ class ElfFile; >> #endif // _WINDOWS >> >> >> -class Decoder: public StackObj { >> +class Decoder: AllStatic { >> >> public: >> // status code for decoding native C frame >> @@ -61,9 +61,6 @@ class Decoder: public StackObj { >> }; >> >> public: >> - Decoder() { initialize(); }; >> - ~Decoder() { uninitialize(); }; >> - >> static bool can_decode_C_frame_in_vm(); >> >> static void initialize(); >> diff --git a/src/share/vm/utilities/vmError.cpp >> b/src/share/vm/utilities/vmError.cpp >> --- a/src/share/vm/utilities/vmError.cpp >> +++ b/src/share/vm/utilities/vmError.cpp >> @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { >> ); >> >> STEP(60, "(printing problematic frame)") >> + // initialize decoder to decode C frames >> + Decoder::initialize(); >> >> // Print current frame if we have a context (i.e. it's a crash) >> if (_context) { >> @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { >> // see if it's a valid frame >> if (fr.pc()) { >> st->print_cr("Native frames: (J=compiled Java code, j=interpreted, >> Vv=VM code, C=native code)"); >> - >> - // initialize decoder to decode C frames >> - Decoder decoder; >> >> int count = 0; >> while (count++ < StackPrintLimit) { >> >> >> Thanks, >> >> -Zhengyu >> >> >> On 7/18/2011 10:24 AM, Volker Simonis wrote: >>> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu wrote: >>>> I have to disagree, I would much prefer to revert back it AllStatic >>>> implementation. Followings are the reasons: >>>> >>>> 1. Uninitialize() was intended to shutdown decoder in low memory >>>> scenarios, >>>> as the decoder is a secondary function. It may not be very clear in this >>>> usecase, but it is a scenario in the project I am currently working on. >>>> >>> I don't know what project you are working on, but in the Hotspot as we >>> can see it, the Decoder::decode() functionality is only accessed from >>> os::dll_address_to_function_name(). This in turn is only called from >>> two places: >>> - from the VM error handler (in vmError.cpp) trough >>> frame::print_on_error() which calls it trough print_C_frame() >>> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >>> >>>> 2. Performance: Initial/uninitial decoder for decoding every symbol, >>>> definitely not optimal. In Unix implementation, it was programmed to >>>> maintain a symbol cache, which will not completely defeated, as it has to >>>> reopen/reparse elf file to decoder every frame. Again, decoder >>>> performance >>>> will be one of key factors for my other project. >>> I didn't propose to create a new Decoder object for the decoding of >>> each symbol. Instead a decoder object could be passed into >>> os::dll_address_to_function_name() and frame::print_on_error(). The >>> user of the functionality could then decide how long he wants to keep >>> the Decoder object and its resources alive. In the case of the >>> FlatProfiler this would probably be the whole VM lifetime, for the >>> vmError use case it would be probably for the time of a complete stack >>> trace. >>> >>>> I will post new webrev to reflect AllStatic implementation. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>>> What about making the Decoder::decode() and all the other methods in >>>>> the Decoder class instance methods? >>>>> Then it would be clear that users of the decode() method would have to >>>>> create (and initialize) a Decode object and it would be their >>>>> responsibility when they create it and and when they uninitialize and >>>>> clean it up. Depending on the platform, the Decoder class may still >>>>> decide to keep its resources globally (as static data members) or just >>>>> for the lifetime of a Decoder object. >>>>> >>>>> With the current solution the problem is (as pointed out by David) >>>>> that it is not clear for callers if they have to do initialization or >>>>> not, and this even differs between Unix and Windows. >>>>> >>>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>>> >>>>> Regards, >>>>> Vovlker >>>>> >>>>> On Sat, Jul 16, 2011 at 12:59 AM, David Holmes >>>>> wrote: >>>>>> John Coomes said the following on 07/16/11 07:01: >>>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>>> Forward to openjdk for review: >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>>> The change looks correct. >>>>>>> >>>>>>> It's not new in this change, but I find it strange that static >>>>>>> initialization of Decoder is triggered by creating an unused instance. >>>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>>> there'd be no need for the comment: >>>>>>> >>>>>>> // initialize decoder to decode C frames >>>>>>> >>>>>>> Decoder should also be changed to inherit from AllStatic instead of >>>>>>> StackObj, but that's getting beyond this bug fix. >>>>>> This is extremely confusing code. We have static data being manipulated >>>>>> by >>>>>> stack-scoped local instances, where the constructor does an initialize >>>>>> function and the destructor does an uninitalize that cleans up various >>>>>> resources. In addition we have a static function on Windows: >>>>>> >>>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>>> initialize(); >>>>>> return _can_decode_in_vm; >>>>>> } >>>>>> >>>>>> which initializes but never cleans up! And the use of these two >>>>>> mechanism >>>>>> can be interspersed. >>>>>> >>>>>> To top it off we create the Decoder instances in places where there is >>>>>> absolutely no indication that somewhere down in the call chain the >>>>>> Decoder >>>>>> functionality will be used! This is truly awful code. >>>>>> >>>>>> Volker's patch to move the Decoder into print_C_frame would seem much >>>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>>> initialize() >>>>>> in can_decode_C_frame_in_vm, and I don't see why we should be working >>>>>> with >>>>>> static functions instead of the Decoder object that was created. >>>>>> >>>>>> Zhengyu is concerned that the repeated init/un-init might be too much >>>>>> if >>>>>> moved into print_C_frame, but his fix goes to the other extreme by >>>>>> giving >>>>>> the Decoder "global" scope in the error reporting process so we won't >>>>>> do >>>>>> any >>>>>> cleanup until right at the end (where we will presumably terminate the >>>>>> process) - so this seems to defeat the purpose of having the cleanup >>>>>> code >>>>>> in >>>>>> the first place. >>>>>> >>>>>> Given that we are in the process of dying I don't see that we should be >>>>>> overly concerned about overhead so I'd be inclined to go with Volker's >>>>>> fix >>>>>> and at least do the init and cleanup in the location where the Decoder >>>>>> is >>>>>> actually used. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> -John >>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: Re: Code review request: 7067266 Decoder class not >>>>>>>> properly initialized on Windows >>>>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>>> From: Daniel D. Daugherty >>>>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>>>> To: Zhengyu Gu >>>>>>>> CC: hotspot-runtime-dev-confidential >>>>>>>> , volker-simonis at gmail.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thumbs up on the code. >>>>>>>> >>>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>>> so this review should go out on that alias also (and the webrev >>>>>>>> copied to cr.openjdk.java.net) >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>>> This is a simple fix that moves Decoder initialization to step 60 in >>>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" in hs >>>>>>>>> file >>>>>>>>> header. >>>>>>>>> >>>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>>> from SAP with proposed patch. >>>>>>>>> The >>>>>>>>> solution >>>>>>>>> was to move decoder initialization code to >>>>>>>>> print_C_frame() function, but it is less optimal, since decoder will >>>>>>>>> have to be initialized and uninitialized every time in/out of the >>>>>>>>> print_C_frame() function. >>>>>>>>> >>>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>>> >>>>>>>>> Testcase: >>>>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>>>> >>>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>>> jclass) >>>>>>>>> { >>>>>>>>> int* p = NULL; >>>>>>>>> *p = 1; >>>>>>>>> } >>>>>>>>> >>>>>>>>> Without fix, hs file header: >>>>>>>>> >>>>>>>>> # >>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>> # >>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>>> pid=7860, >>>>>>>>> tid=4140 >>>>>>>>> # >>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, sharing >>>>>>>>> windows-x86 ) >>>>>>>>> # Problematic frame: >>>>>>>>> # C [mydll.dll+0x11308] >>>>>>>>> # >>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>>> code. >>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>> # >>>>>>>>> >>>>>>>>> >>>>>>>>> With fix: >>>>>>>>> >>>>>>>>> # >>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>> # >>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>>> pid=1652, >>>>>>>>> tid=5964 >>>>>>>>> # >>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug mixed mode >>>>>>>>> windows-x86 ) >>>>>>>>> # Problematic frame: >>>>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>>> # >>>>>>>>> # Failed to write core dump. Minidumps are not enabled by default on >>>>>>>>> client versions of Windows >>>>>>>>> # >>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>>> code. >>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>> # >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Zhengyu >> From zhengyu.gu at oracle.com Thu Jul 21 06:12:24 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 21 Jul 2011 09:12:24 -0400 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E2748C2.3090600@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> <4E2748C2.3090600@oracle.com> Message-ID: <4E2825B8.3000602@oracle.com> On 7/20/2011 5:29 PM, David Holmes wrote: > Volker Simonis said the following on 07/21/11 01:29: >> I must say that I in general don't like the idea to have a static >> method which is dependent on another static method being called >> before. This is just an implicit dependency which is not documented >> nor enforced anywhere. >> >> Your patch may fix the current problem, but what if somebody will use >> VMError::print_stack_trace() or frame::print_on_error() in the future. >> How can he know that he will have to initialize Decoder first? > > I have to agree. The initialization code should be called from the > methods that need it - as is actually done in one Windows case. > Then singleton object makes more sense. I still view Decoder as optional service, it can be shutdown silently, and output undecoded C frame does not imply a bug. We do see the scenarios in nightly tests. > Further, if we aren't going to do any cleanup then what is the point > of having uninitialize ? Seems to be dead code. > There is no reason to uninitialize in this case, but there is a usecase (after integrates VM diagnostic functions): when VM thinks that it is running out of memory. Symbol cache can grow substantially on Unix platforms. -Zhengyu > David > > >> Regards, >> Volker >> >> On Wed, Jul 20, 2011 at 4:46 PM, Zhengyu Gu >> wrote: >>> Hi, >>> >>> Sorry for delay. I am having trouble to upload webrev to >>> cr.openjdk.java.net, probably due to re-ip here. >>> >>> This revision, Decoder class is reverted back to AllStatic. >>> Decoder::initialize() is added at Step 60, and Decoder won't be >>> uninitialized. >>> >>> Here is the link to internal webrev: >>> http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ >>> >>> Here is the diff: >>> >>> bash-3.00$ hg diff >>> diff --git a/src/share/vm/utilities/decoder.hpp >>> b/src/share/vm/utilities/decoder.hpp >>> --- a/src/share/vm/utilities/decoder.hpp >>> +++ b/src/share/vm/utilities/decoder.hpp >>> @@ -45,7 +45,7 @@ class ElfFile; >>> #endif // _WINDOWS >>> >>> >>> -class Decoder: public StackObj { >>> +class Decoder: AllStatic { >>> >>> public: >>> // status code for decoding native C frame >>> @@ -61,9 +61,6 @@ class Decoder: public StackObj { >>> }; >>> >>> public: >>> - Decoder() { initialize(); }; >>> - ~Decoder() { uninitialize(); }; >>> - >>> static bool can_decode_C_frame_in_vm(); >>> >>> static void initialize(); >>> diff --git a/src/share/vm/utilities/vmError.cpp >>> b/src/share/vm/utilities/vmError.cpp >>> --- a/src/share/vm/utilities/vmError.cpp >>> +++ b/src/share/vm/utilities/vmError.cpp >>> @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { >>> ); >>> >>> STEP(60, "(printing problematic frame)") >>> + // initialize decoder to decode C frames >>> + Decoder::initialize(); >>> >>> // Print current frame if we have a context (i.e. it's a crash) >>> if (_context) { >>> @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { >>> // see if it's a valid frame >>> if (fr.pc()) { >>> st->print_cr("Native frames: (J=compiled Java code, >>> j=interpreted, >>> Vv=VM code, C=native code)"); >>> - >>> - // initialize decoder to decode C frames >>> - Decoder decoder; >>> >>> int count = 0; >>> while (count++ < StackPrintLimit) { >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>> On 7/18/2011 10:24 AM, Volker Simonis wrote: >>>> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu >>>> wrote: >>>>> I have to disagree, I would much prefer to revert back it AllStatic >>>>> implementation. Followings are the reasons: >>>>> >>>>> 1. Uninitialize() was intended to shutdown decoder in low memory >>>>> scenarios, >>>>> as the decoder is a secondary function. It may not be very clear >>>>> in this >>>>> usecase, but it is a scenario in the project I am currently >>>>> working on. >>>>> >>>> I don't know what project you are working on, but in the Hotspot as we >>>> can see it, the Decoder::decode() functionality is only accessed from >>>> os::dll_address_to_function_name(). This in turn is only called from >>>> two places: >>>> - from the VM error handler (in vmError.cpp) trough >>>> frame::print_on_error() which calls it trough print_C_frame() >>>> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >>>> >>>>> 2. Performance: Initial/uninitial decoder for decoding every symbol, >>>>> definitely not optimal. In Unix implementation, it was programmed to >>>>> maintain a symbol cache, which will not completely defeated, as it >>>>> has to >>>>> reopen/reparse elf file to decoder every frame. Again, decoder >>>>> performance >>>>> will be one of key factors for my other project. >>>> I didn't propose to create a new Decoder object for the decoding of >>>> each symbol. Instead a decoder object could be passed into >>>> os::dll_address_to_function_name() and frame::print_on_error(). The >>>> user of the functionality could then decide how long he wants to keep >>>> the Decoder object and its resources alive. In the case of the >>>> FlatProfiler this would probably be the whole VM lifetime, for the >>>> vmError use case it would be probably for the time of a complete stack >>>> trace. >>>> >>>>> I will post new webrev to reflect AllStatic implementation. >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>>>> What about making the Decoder::decode() and all the other methods in >>>>>> the Decoder class instance methods? >>>>>> Then it would be clear that users of the decode() method would >>>>>> have to >>>>>> create (and initialize) a Decode object and it would be their >>>>>> responsibility when they create it and and when they uninitialize >>>>>> and >>>>>> clean it up. Depending on the platform, the Decoder class may still >>>>>> decide to keep its resources globally (as static data members) or >>>>>> just >>>>>> for the lifetime of a Decoder object. >>>>>> >>>>>> With the current solution the problem is (as pointed out by David) >>>>>> that it is not clear for callers if they have to do >>>>>> initialization or >>>>>> not, and this even differs between Unix and Windows. >>>>>> >>>>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>>>> >>>>>> Regards, >>>>>> Vovlker >>>>>> >>>>>> On Sat, Jul 16, 2011 at 12:59 AM, David >>>>>> Holmes >>>>>> wrote: >>>>>>> John Coomes said the following on 07/16/11 07:01: >>>>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>>>> Forward to openjdk for review: >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>>>> The change looks correct. >>>>>>>> >>>>>>>> It's not new in this change, but I find it strange that static >>>>>>>> initialization of Decoder is triggered by creating an unused >>>>>>>> instance. >>>>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>>>> there'd be no need for the comment: >>>>>>>> >>>>>>>> // initialize decoder to decode C frames >>>>>>>> >>>>>>>> Decoder should also be changed to inherit from AllStatic >>>>>>>> instead of >>>>>>>> StackObj, but that's getting beyond this bug fix. >>>>>>> This is extremely confusing code. We have static data being >>>>>>> manipulated >>>>>>> by >>>>>>> stack-scoped local instances, where the constructor does an >>>>>>> initialize >>>>>>> function and the destructor does an uninitalize that cleans up >>>>>>> various >>>>>>> resources. In addition we have a static function on Windows: >>>>>>> >>>>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>>>> initialize(); >>>>>>> return _can_decode_in_vm; >>>>>>> } >>>>>>> >>>>>>> which initializes but never cleans up! And the use of these two >>>>>>> mechanism >>>>>>> can be interspersed. >>>>>>> >>>>>>> To top it off we create the Decoder instances in places where >>>>>>> there is >>>>>>> absolutely no indication that somewhere down in the call chain the >>>>>>> Decoder >>>>>>> functionality will be used! This is truly awful code. >>>>>>> >>>>>>> Volker's patch to move the Decoder into print_C_frame would seem >>>>>>> much >>>>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>>>> initialize() >>>>>>> in can_decode_C_frame_in_vm, and I don't see why we should be >>>>>>> working >>>>>>> with >>>>>>> static functions instead of the Decoder object that was created. >>>>>>> >>>>>>> Zhengyu is concerned that the repeated init/un-init might be too >>>>>>> much >>>>>>> if >>>>>>> moved into print_C_frame, but his fix goes to the other extreme by >>>>>>> giving >>>>>>> the Decoder "global" scope in the error reporting process so we >>>>>>> won't >>>>>>> do >>>>>>> any >>>>>>> cleanup until right at the end (where we will presumably >>>>>>> terminate the >>>>>>> process) - so this seems to defeat the purpose of having the >>>>>>> cleanup >>>>>>> code >>>>>>> in >>>>>>> the first place. >>>>>>> >>>>>>> Given that we are in the process of dying I don't see that we >>>>>>> should be >>>>>>> overly concerned about overhead so I'd be inclined to go with >>>>>>> Volker's >>>>>>> fix >>>>>>> and at least do the init and cleanup in the location where the >>>>>>> Decoder >>>>>>> is >>>>>>> actually used. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> -John >>>>>>>> >>>>>>>>> -------- Original Message -------- >>>>>>>>> Subject: Re: Code review request: 7067266 Decoder class >>>>>>>>> not >>>>>>>>> properly initialized on Windows >>>>>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>>>> From: Daniel D. Daugherty >>>>>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>>>>> To: Zhengyu Gu >>>>>>>>> CC: hotspot-runtime-dev-confidential >>>>>>>>> , >>>>>>>>> volker-simonis at gmail.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thumbs up on the code. >>>>>>>>> >>>>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>>>> so this review should go out on that alias also (and the webrev >>>>>>>>> copied to cr.openjdk.java.net) >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>>>> This is a simple fix that moves Decoder initialization to >>>>>>>>>> step 60 in >>>>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" >>>>>>>>>> in hs >>>>>>>>>> file >>>>>>>>>> header. >>>>>>>>>> >>>>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>>>> from SAP with proposed >>>>>>>>>> patch. >>>>>>>>>> The >>>>>>>>>> solution >>>>>>>>>> was to move decoder initialization code to >>>>>>>>>> print_C_frame() function, but it is less optimal, since >>>>>>>>>> decoder will >>>>>>>>>> have to be initialized and uninitialized every time in/out of >>>>>>>>>> the >>>>>>>>>> print_C_frame() function. >>>>>>>>>> >>>>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>>>> >>>>>>>>>> Testcase: >>>>>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>>>>> >>>>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>>>> jclass) >>>>>>>>>> { >>>>>>>>>> int* p = NULL; >>>>>>>>>> *p = 1; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Without fix, hs file header: >>>>>>>>>> >>>>>>>>>> # >>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>> Environment: >>>>>>>>>> # >>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>>>> pid=7860, >>>>>>>>>> tid=4140 >>>>>>>>>> # >>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, >>>>>>>>>> sharing >>>>>>>>>> windows-x86 ) >>>>>>>>>> # Problematic frame: >>>>>>>>>> # C [mydll.dll+0x11308] >>>>>>>>>> # >>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>>>> code. >>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>> # >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With fix: >>>>>>>>>> >>>>>>>>>> # >>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>> Environment: >>>>>>>>>> # >>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>>>> pid=1652, >>>>>>>>>> tid=5964 >>>>>>>>>> # >>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug >>>>>>>>>> mixed mode >>>>>>>>>> windows-x86 ) >>>>>>>>>> # Problematic frame: >>>>>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>>>> # >>>>>>>>>> # Failed to write core dump. Minidumps are not enabled by >>>>>>>>>> default on >>>>>>>>>> client versions of Windows >>>>>>>>>> # >>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>>>> code. >>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>> # >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Zhengyu >>> From David.Holmes at oracle.com Thu Jul 21 17:32:27 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2011 10:32:27 +1000 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E2825B8.3000602@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> <4E2748C2.3090600@oracle.com> <4E2825B8.3000602@oracle.com> Message-ID: <4E28C51B.2060903@oracle.com> Zhengyu Gu said the following on 07/21/11 23:12: > > On 7/20/2011 5:29 PM, David Holmes wrote: >> Volker Simonis said the following on 07/21/11 01:29: >>> I must say that I in general don't like the idea to have a static >>> method which is dependent on another static method being called >>> before. This is just an implicit dependency which is not documented >>> nor enforced anywhere. >>> >>> Your patch may fix the current problem, but what if somebody will use >>> VMError::print_stack_trace() or frame::print_on_error() in the future. >>> How can he know that he will have to initialize Decoder first? >> >> I have to agree. The initialization code should be called from the >> methods that need it - as is actually done in one Windows case. >> > Then singleton object makes more sense. I still view Decoder as optional > service, it can be shutdown silently, and output undecoded C frame does > not imply a bug. We do see the scenarios in nightly tests. If you consider it a service with explicit init/uninit then it doesn't really matter whether it is all static or a singleton instance. The issue in question is where the calls to init/uninit get placed. If the service is lazy-initialized then the initialization should be done within the operations that need it. The decision of when to "uninitialize" is more interesting if it is really just a "please free up some resources" request. >> Further, if we aren't going to do any cleanup then what is the point >> of having uninitialize ? Seems to be dead code. >> > There is no reason to uninitialize in this case, but there is a usecase > (after integrates VM diagnostic functions): when VM thinks that it is > running out of memory. Symbol cache can grow substantially on Unix > platforms. Are you saying that frame decoding will be used in contexts other than as part of fatal error handling? If so then you will need to synchronize access to these resources that can be cleaned up. In which case it it may be better to address this current bug within that larger piece of work. David ----- > > -Zhengyu > >> David >> >> >>> Regards, >>> Volker >>> >>> On Wed, Jul 20, 2011 at 4:46 PM, Zhengyu Gu >>> wrote: >>>> Hi, >>>> >>>> Sorry for delay. I am having trouble to upload webrev to >>>> cr.openjdk.java.net, probably due to re-ip here. >>>> >>>> This revision, Decoder class is reverted back to AllStatic. >>>> Decoder::initialize() is added at Step 60, and Decoder won't be >>>> uninitialized. >>>> >>>> Here is the link to internal webrev: >>>> http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ >>>> >>>> Here is the diff: >>>> >>>> bash-3.00$ hg diff >>>> diff --git a/src/share/vm/utilities/decoder.hpp >>>> b/src/share/vm/utilities/decoder.hpp >>>> --- a/src/share/vm/utilities/decoder.hpp >>>> +++ b/src/share/vm/utilities/decoder.hpp >>>> @@ -45,7 +45,7 @@ class ElfFile; >>>> #endif // _WINDOWS >>>> >>>> >>>> -class Decoder: public StackObj { >>>> +class Decoder: AllStatic { >>>> >>>> public: >>>> // status code for decoding native C frame >>>> @@ -61,9 +61,6 @@ class Decoder: public StackObj { >>>> }; >>>> >>>> public: >>>> - Decoder() { initialize(); }; >>>> - ~Decoder() { uninitialize(); }; >>>> - >>>> static bool can_decode_C_frame_in_vm(); >>>> >>>> static void initialize(); >>>> diff --git a/src/share/vm/utilities/vmError.cpp >>>> b/src/share/vm/utilities/vmError.cpp >>>> --- a/src/share/vm/utilities/vmError.cpp >>>> +++ b/src/share/vm/utilities/vmError.cpp >>>> @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { >>>> ); >>>> >>>> STEP(60, "(printing problematic frame)") >>>> + // initialize decoder to decode C frames >>>> + Decoder::initialize(); >>>> >>>> // Print current frame if we have a context (i.e. it's a crash) >>>> if (_context) { >>>> @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { >>>> // see if it's a valid frame >>>> if (fr.pc()) { >>>> st->print_cr("Native frames: (J=compiled Java code, >>>> j=interpreted, >>>> Vv=VM code, C=native code)"); >>>> - >>>> - // initialize decoder to decode C frames >>>> - Decoder decoder; >>>> >>>> int count = 0; >>>> while (count++ < StackPrintLimit) { >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> On 7/18/2011 10:24 AM, Volker Simonis wrote: >>>>> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu Gu >>>>> wrote: >>>>>> I have to disagree, I would much prefer to revert back it AllStatic >>>>>> implementation. Followings are the reasons: >>>>>> >>>>>> 1. Uninitialize() was intended to shutdown decoder in low memory >>>>>> scenarios, >>>>>> as the decoder is a secondary function. It may not be very clear >>>>>> in this >>>>>> usecase, but it is a scenario in the project I am currently >>>>>> working on. >>>>>> >>>>> I don't know what project you are working on, but in the Hotspot as we >>>>> can see it, the Decoder::decode() functionality is only accessed from >>>>> os::dll_address_to_function_name(). This in turn is only called from >>>>> two places: >>>>> - from the VM error handler (in vmError.cpp) trough >>>>> frame::print_on_error() which calls it trough print_C_frame() >>>>> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >>>>> >>>>>> 2. Performance: Initial/uninitial decoder for decoding every symbol, >>>>>> definitely not optimal. In Unix implementation, it was programmed to >>>>>> maintain a symbol cache, which will not completely defeated, as it >>>>>> has to >>>>>> reopen/reparse elf file to decoder every frame. Again, decoder >>>>>> performance >>>>>> will be one of key factors for my other project. >>>>> I didn't propose to create a new Decoder object for the decoding of >>>>> each symbol. Instead a decoder object could be passed into >>>>> os::dll_address_to_function_name() and frame::print_on_error(). The >>>>> user of the functionality could then decide how long he wants to keep >>>>> the Decoder object and its resources alive. In the case of the >>>>> FlatProfiler this would probably be the whole VM lifetime, for the >>>>> vmError use case it would be probably for the time of a complete stack >>>>> trace. >>>>> >>>>>> I will post new webrev to reflect AllStatic implementation. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>>>>> What about making the Decoder::decode() and all the other methods in >>>>>>> the Decoder class instance methods? >>>>>>> Then it would be clear that users of the decode() method would >>>>>>> have to >>>>>>> create (and initialize) a Decode object and it would be their >>>>>>> responsibility when they create it and and when they uninitialize >>>>>>> and >>>>>>> clean it up. Depending on the platform, the Decoder class may still >>>>>>> decide to keep its resources globally (as static data members) or >>>>>>> just >>>>>>> for the lifetime of a Decoder object. >>>>>>> >>>>>>> With the current solution the problem is (as pointed out by David) >>>>>>> that it is not clear for callers if they have to do >>>>>>> initialization or >>>>>>> not, and this even differs between Unix and Windows. >>>>>>> >>>>>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>>>>> >>>>>>> Regards, >>>>>>> Vovlker >>>>>>> >>>>>>> On Sat, Jul 16, 2011 at 12:59 AM, David >>>>>>> Holmes >>>>>>> wrote: >>>>>>>> John Coomes said the following on 07/16/11 07:01: >>>>>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>>>>> Forward to openjdk for review: >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>>>>> The change looks correct. >>>>>>>>> >>>>>>>>> It's not new in this change, but I find it strange that static >>>>>>>>> initialization of Decoder is triggered by creating an unused >>>>>>>>> instance. >>>>>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>>>>> there'd be no need for the comment: >>>>>>>>> >>>>>>>>> // initialize decoder to decode C frames >>>>>>>>> >>>>>>>>> Decoder should also be changed to inherit from AllStatic >>>>>>>>> instead of >>>>>>>>> StackObj, but that's getting beyond this bug fix. >>>>>>>> This is extremely confusing code. We have static data being >>>>>>>> manipulated >>>>>>>> by >>>>>>>> stack-scoped local instances, where the constructor does an >>>>>>>> initialize >>>>>>>> function and the destructor does an uninitalize that cleans up >>>>>>>> various >>>>>>>> resources. In addition we have a static function on Windows: >>>>>>>> >>>>>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>>>>> initialize(); >>>>>>>> return _can_decode_in_vm; >>>>>>>> } >>>>>>>> >>>>>>>> which initializes but never cleans up! And the use of these two >>>>>>>> mechanism >>>>>>>> can be interspersed. >>>>>>>> >>>>>>>> To top it off we create the Decoder instances in places where >>>>>>>> there is >>>>>>>> absolutely no indication that somewhere down in the call chain the >>>>>>>> Decoder >>>>>>>> functionality will be used! This is truly awful code. >>>>>>>> >>>>>>>> Volker's patch to move the Decoder into print_C_frame would seem >>>>>>>> much >>>>>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>>>>> initialize() >>>>>>>> in can_decode_C_frame_in_vm, and I don't see why we should be >>>>>>>> working >>>>>>>> with >>>>>>>> static functions instead of the Decoder object that was created. >>>>>>>> >>>>>>>> Zhengyu is concerned that the repeated init/un-init might be too >>>>>>>> much >>>>>>>> if >>>>>>>> moved into print_C_frame, but his fix goes to the other extreme by >>>>>>>> giving >>>>>>>> the Decoder "global" scope in the error reporting process so we >>>>>>>> won't >>>>>>>> do >>>>>>>> any >>>>>>>> cleanup until right at the end (where we will presumably >>>>>>>> terminate the >>>>>>>> process) - so this seems to defeat the purpose of having the >>>>>>>> cleanup >>>>>>>> code >>>>>>>> in >>>>>>>> the first place. >>>>>>>> >>>>>>>> Given that we are in the process of dying I don't see that we >>>>>>>> should be >>>>>>>> overly concerned about overhead so I'd be inclined to go with >>>>>>>> Volker's >>>>>>>> fix >>>>>>>> and at least do the init and cleanup in the location where the >>>>>>>> Decoder >>>>>>>> is >>>>>>>> actually used. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> -John >>>>>>>>> >>>>>>>>>> -------- Original Message -------- >>>>>>>>>> Subject: Re: Code review request: 7067266 Decoder class >>>>>>>>>> not >>>>>>>>>> properly initialized on Windows >>>>>>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>>>>> From: Daniel D. Daugherty >>>>>>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>>>>>> To: Zhengyu Gu >>>>>>>>>> CC: hotspot-runtime-dev-confidential >>>>>>>>>> , >>>>>>>>>> volker-simonis at gmail.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thumbs up on the code. >>>>>>>>>> >>>>>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>>>>> so this review should go out on that alias also (and the webrev >>>>>>>>>> copied to cr.openjdk.java.net) >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>>>>> This is a simple fix that moves Decoder initialization to >>>>>>>>>>> step 60 in >>>>>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" >>>>>>>>>>> in hs >>>>>>>>>>> file >>>>>>>>>>> header. >>>>>>>>>>> >>>>>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>>>>> from SAP with proposed >>>>>>>>>>> patch. >>>>>>>>>>> The >>>>>>>>>>> solution >>>>>>>>>>> was to move decoder initialization code to >>>>>>>>>>> print_C_frame() function, but it is less optimal, since >>>>>>>>>>> decoder will >>>>>>>>>>> have to be initialized and uninitialized every time in/out of >>>>>>>>>>> the >>>>>>>>>>> print_C_frame() function. >>>>>>>>>>> >>>>>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>>>>> >>>>>>>>>>> Testcase: >>>>>>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>>>>>> >>>>>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>>>>> jclass) >>>>>>>>>>> { >>>>>>>>>>> int* p = NULL; >>>>>>>>>>> *p = 1; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Without fix, hs file header: >>>>>>>>>>> >>>>>>>>>>> # >>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>> Environment: >>>>>>>>>>> # >>>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>>>>> pid=7860, >>>>>>>>>>> tid=4140 >>>>>>>>>>> # >>>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, >>>>>>>>>>> sharing >>>>>>>>>>> windows-x86 ) >>>>>>>>>>> # Problematic frame: >>>>>>>>>>> # C [mydll.dll+0x11308] >>>>>>>>>>> # >>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>>>>> code. >>>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>>> # >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> With fix: >>>>>>>>>>> >>>>>>>>>>> # >>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>> Environment: >>>>>>>>>>> # >>>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>>>>> pid=1652, >>>>>>>>>>> tid=5964 >>>>>>>>>>> # >>>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug >>>>>>>>>>> mixed mode >>>>>>>>>>> windows-x86 ) >>>>>>>>>>> # Problematic frame: >>>>>>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>>>>> # >>>>>>>>>>> # Failed to write core dump. Minidumps are not enabled by >>>>>>>>>>> default on >>>>>>>>>>> client versions of Windows >>>>>>>>>>> # >>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>>>>> # The crash happened outside the Java Virtual Machine in native >>>>>>>>>>> code. >>>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>>> # >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Zhengyu >>>> > From david.holmes at oracle.com Fri Jul 22 02:43:01 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 22 Jul 2011 09:43:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7046490: Preallocated OOME objects should obey Throwable stack trace protocol Message-ID: <20110722094306.0E93B47640@hg.openjdk.java.net> Changeset: 0b80db433fcb Author: dholmes Date: 2011-07-22 00:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0b80db433fcb 7046490: Preallocated OOME objects should obey Throwable stack trace protocol Summary: Update the OOME stacktrace to contain Throwable.UNASSIGNED_STACK when the backtrace is filled in Reviewed-by: mchung, phh ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp From zhengyu.gu at oracle.com Fri Jul 22 07:30:30 2011 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 22 Jul 2011 10:30:30 -0400 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E28C51B.2060903@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> <4E2748C2.3090600@oracle.com> <4E2825B8.3000602@oracle.com> <4E28C51B.2060903@oracle.com> Message-ID: <4E298986.6050705@oracle.com> > If you consider it a service with explicit init/uninit then it doesn't > really matter whether it is all static or a singleton instance. The > issue in question is where the calls to init/uninit get placed. If the > service is lazy-initialized then the initialization should be done > within the operations that need it. The decision of when to > "uninitialize" is more interesting if it is really just a "please free > up some resources" request. > The advantage of singleton instance is to initialize Decoder at Decoder::getInstance(), and not add initialize() call on every method. >>> Further, if we aren't going to do any cleanup then what is the point >>> of having uninitialize ? Seems to be dead code. >>> >> There is no reason to uninitialize in this case, but there is a >> usecase (after integrates VM diagnostic functions): when VM thinks >> that it is running out of memory. Symbol cache can grow substantially >> on Unix platforms. > > Are you saying that frame decoding will be used in contexts other than > as part of fatal error handling? If so then you will need to > synchronize access to these resources that can be cleaned up. In which > case it it may be better to address this current bug within that > larger piece of work. > Yes, I don't intend to address those issues with this bug. Thanks, -Zhengyu > David > ----- > >> >> -Zhengyu >> >>> David >>> >>> >>>> Regards, >>>> Volker >>>> >>>> On Wed, Jul 20, 2011 at 4:46 PM, Zhengyu Gu >>>> wrote: >>>>> Hi, >>>>> >>>>> Sorry for delay. I am having trouble to upload webrev to >>>>> cr.openjdk.java.net, probably due to re-ip here. >>>>> >>>>> This revision, Decoder class is reverted back to AllStatic. >>>>> Decoder::initialize() is added at Step 60, and Decoder won't be >>>>> uninitialized. >>>>> >>>>> Here is the link to internal webrev: >>>>> http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ >>>>> >>>>> Here is the diff: >>>>> >>>>> bash-3.00$ hg diff >>>>> diff --git a/src/share/vm/utilities/decoder.hpp >>>>> b/src/share/vm/utilities/decoder.hpp >>>>> --- a/src/share/vm/utilities/decoder.hpp >>>>> +++ b/src/share/vm/utilities/decoder.hpp >>>>> @@ -45,7 +45,7 @@ class ElfFile; >>>>> #endif // _WINDOWS >>>>> >>>>> >>>>> -class Decoder: public StackObj { >>>>> +class Decoder: AllStatic { >>>>> >>>>> public: >>>>> // status code for decoding native C frame >>>>> @@ -61,9 +61,6 @@ class Decoder: public StackObj { >>>>> }; >>>>> >>>>> public: >>>>> - Decoder() { initialize(); }; >>>>> - ~Decoder() { uninitialize(); }; >>>>> - >>>>> static bool can_decode_C_frame_in_vm(); >>>>> >>>>> static void initialize(); >>>>> diff --git a/src/share/vm/utilities/vmError.cpp >>>>> b/src/share/vm/utilities/vmError.cpp >>>>> --- a/src/share/vm/utilities/vmError.cpp >>>>> +++ b/src/share/vm/utilities/vmError.cpp >>>>> @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { >>>>> ); >>>>> >>>>> STEP(60, "(printing problematic frame)") >>>>> + // initialize decoder to decode C frames >>>>> + Decoder::initialize(); >>>>> >>>>> // Print current frame if we have a context (i.e. it's a crash) >>>>> if (_context) { >>>>> @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { >>>>> // see if it's a valid frame >>>>> if (fr.pc()) { >>>>> st->print_cr("Native frames: (J=compiled Java code, >>>>> j=interpreted, >>>>> Vv=VM code, C=native code)"); >>>>> - >>>>> - // initialize decoder to decode C frames >>>>> - Decoder decoder; >>>>> >>>>> int count = 0; >>>>> while (count++ < StackPrintLimit) { >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>> On 7/18/2011 10:24 AM, Volker Simonis wrote: >>>>>> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu >>>>>> Gu wrote: >>>>>>> I have to disagree, I would much prefer to revert back it AllStatic >>>>>>> implementation. Followings are the reasons: >>>>>>> >>>>>>> 1. Uninitialize() was intended to shutdown decoder in low memory >>>>>>> scenarios, >>>>>>> as the decoder is a secondary function. It may not be very clear >>>>>>> in this >>>>>>> usecase, but it is a scenario in the project I am currently >>>>>>> working on. >>>>>>> >>>>>> I don't know what project you are working on, but in the Hotspot >>>>>> as we >>>>>> can see it, the Decoder::decode() functionality is only accessed >>>>>> from >>>>>> os::dll_address_to_function_name(). This in turn is only called from >>>>>> two places: >>>>>> - from the VM error handler (in vmError.cpp) trough >>>>>> frame::print_on_error() which calls it trough print_C_frame() >>>>>> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >>>>>> >>>>>>> 2. Performance: Initial/uninitial decoder for decoding every >>>>>>> symbol, >>>>>>> definitely not optimal. In Unix implementation, it was >>>>>>> programmed to >>>>>>> maintain a symbol cache, which will not completely defeated, as >>>>>>> it has to >>>>>>> reopen/reparse elf file to decoder every frame. Again, decoder >>>>>>> performance >>>>>>> will be one of key factors for my other project. >>>>>> I didn't propose to create a new Decoder object for the decoding of >>>>>> each symbol. Instead a decoder object could be passed into >>>>>> os::dll_address_to_function_name() and frame::print_on_error(). The >>>>>> user of the functionality could then decide how long he wants to >>>>>> keep >>>>>> the Decoder object and its resources alive. In the case of the >>>>>> FlatProfiler this would probably be the whole VM lifetime, for the >>>>>> vmError use case it would be probably for the time of a complete >>>>>> stack >>>>>> trace. >>>>>> >>>>>>> I will post new webrev to reflect AllStatic implementation. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >>>>>>> >>>>>>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>>>>>> What about making the Decoder::decode() and all the other >>>>>>>> methods in >>>>>>>> the Decoder class instance methods? >>>>>>>> Then it would be clear that users of the decode() method would >>>>>>>> have to >>>>>>>> create (and initialize) a Decode object and it would be their >>>>>>>> responsibility when they create it and and when they >>>>>>>> uninitialize and >>>>>>>> clean it up. Depending on the platform, the Decoder class may >>>>>>>> still >>>>>>>> decide to keep its resources globally (as static data members) >>>>>>>> or just >>>>>>>> for the lifetime of a Decoder object. >>>>>>>> >>>>>>>> With the current solution the problem is (as pointed out by David) >>>>>>>> that it is not clear for callers if they have to do >>>>>>>> initialization or >>>>>>>> not, and this even differs between Unix and Windows. >>>>>>>> >>>>>>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vovlker >>>>>>>> >>>>>>>> On Sat, Jul 16, 2011 at 12:59 AM, David >>>>>>>> Holmes >>>>>>>> wrote: >>>>>>>>> John Coomes said the following on 07/16/11 07:01: >>>>>>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>>>>>> Forward to openjdk for review: >>>>>>>>>>> >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>>>>>> The change looks correct. >>>>>>>>>> >>>>>>>>>> It's not new in this change, but I find it strange that static >>>>>>>>>> initialization of Decoder is triggered by creating an unused >>>>>>>>>> instance. >>>>>>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>>>>>> there'd be no need for the comment: >>>>>>>>>> >>>>>>>>>> // initialize decoder to decode C frames >>>>>>>>>> >>>>>>>>>> Decoder should also be changed to inherit from AllStatic >>>>>>>>>> instead of >>>>>>>>>> StackObj, but that's getting beyond this bug fix. >>>>>>>>> This is extremely confusing code. We have static data being >>>>>>>>> manipulated >>>>>>>>> by >>>>>>>>> stack-scoped local instances, where the constructor does an >>>>>>>>> initialize >>>>>>>>> function and the destructor does an uninitalize that cleans up >>>>>>>>> various >>>>>>>>> resources. In addition we have a static function on Windows: >>>>>>>>> >>>>>>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>>>>>> initialize(); >>>>>>>>> return _can_decode_in_vm; >>>>>>>>> } >>>>>>>>> >>>>>>>>> which initializes but never cleans up! And the use of these two >>>>>>>>> mechanism >>>>>>>>> can be interspersed. >>>>>>>>> >>>>>>>>> To top it off we create the Decoder instances in places where >>>>>>>>> there is >>>>>>>>> absolutely no indication that somewhere down in the call chain >>>>>>>>> the >>>>>>>>> Decoder >>>>>>>>> functionality will be used! This is truly awful code. >>>>>>>>> >>>>>>>>> Volker's patch to move the Decoder into print_C_frame would >>>>>>>>> seem much >>>>>>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>>>>>> initialize() >>>>>>>>> in can_decode_C_frame_in_vm, and I don't see why we should be >>>>>>>>> working >>>>>>>>> with >>>>>>>>> static functions instead of the Decoder object that was created. >>>>>>>>> >>>>>>>>> Zhengyu is concerned that the repeated init/un-init might be >>>>>>>>> too much >>>>>>>>> if >>>>>>>>> moved into print_C_frame, but his fix goes to the other >>>>>>>>> extreme by >>>>>>>>> giving >>>>>>>>> the Decoder "global" scope in the error reporting process so >>>>>>>>> we won't >>>>>>>>> do >>>>>>>>> any >>>>>>>>> cleanup until right at the end (where we will presumably >>>>>>>>> terminate the >>>>>>>>> process) - so this seems to defeat the purpose of having the >>>>>>>>> cleanup >>>>>>>>> code >>>>>>>>> in >>>>>>>>> the first place. >>>>>>>>> >>>>>>>>> Given that we are in the process of dying I don't see that we >>>>>>>>> should be >>>>>>>>> overly concerned about overhead so I'd be inclined to go with >>>>>>>>> Volker's >>>>>>>>> fix >>>>>>>>> and at least do the init and cleanup in the location where the >>>>>>>>> Decoder >>>>>>>>> is >>>>>>>>> actually used. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> -John >>>>>>>>>> >>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>> Subject: Re: Code review request: 7067266 Decoder >>>>>>>>>>> class not >>>>>>>>>>> properly initialized on Windows >>>>>>>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>>>>>> From: Daniel D. Daugherty >>>>>>>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>>>>>>> To: Zhengyu Gu >>>>>>>>>>> CC: hotspot-runtime-dev-confidential >>>>>>>>>>> , >>>>>>>>>>> volker-simonis at gmail.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thumbs up on the code. >>>>>>>>>>> >>>>>>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>>>>>> so this review should go out on that alias also (and the webrev >>>>>>>>>>> copied to cr.openjdk.java.net) >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>>>>>> This is a simple fix that moves Decoder initialization to >>>>>>>>>>>> step 60 in >>>>>>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" >>>>>>>>>>>> in hs >>>>>>>>>>>> file >>>>>>>>>>>> header. >>>>>>>>>>>> >>>>>>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>>>>>> from SAP with proposed >>>>>>>>>>>> patch. >>>>>>>>>>>> The >>>>>>>>>>>> solution >>>>>>>>>>>> was to move decoder initialization code to >>>>>>>>>>>> print_C_frame() function, but it is less optimal, since >>>>>>>>>>>> decoder will >>>>>>>>>>>> have to be initialized and uninitialized every time in/out >>>>>>>>>>>> of the >>>>>>>>>>>> print_C_frame() function. >>>>>>>>>>>> >>>>>>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Testcase: >>>>>>>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>>>>>>> >>>>>>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>>>>>> jclass) >>>>>>>>>>>> { >>>>>>>>>>>> int* p = NULL; >>>>>>>>>>>> *p = 1; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Without fix, hs file header: >>>>>>>>>>>> >>>>>>>>>>>> # >>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>> Environment: >>>>>>>>>>>> # >>>>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>>>>>> pid=7860, >>>>>>>>>>>> tid=4140 >>>>>>>>>>>> # >>>>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, >>>>>>>>>>>> sharing >>>>>>>>>>>> windows-x86 ) >>>>>>>>>>>> # Problematic frame: >>>>>>>>>>>> # C [mydll.dll+0x11308] >>>>>>>>>>>> # >>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>>>>> # The crash happened outside the Java Virtual Machine in >>>>>>>>>>>> native >>>>>>>>>>>> code. >>>>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>>>> # >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> With fix: >>>>>>>>>>>> >>>>>>>>>>>> # >>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>> Environment: >>>>>>>>>>>> # >>>>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>>>>>> pid=1652, >>>>>>>>>>>> tid=5964 >>>>>>>>>>>> # >>>>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug >>>>>>>>>>>> mixed mode >>>>>>>>>>>> windows-x86 ) >>>>>>>>>>>> # Problematic frame: >>>>>>>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>>>>>> # >>>>>>>>>>>> # Failed to write core dump. Minidumps are not enabled by >>>>>>>>>>>> default on >>>>>>>>>>>> client versions of Windows >>>>>>>>>>>> # >>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>>>>>> # The crash happened outside the Java Virtual Machine in >>>>>>>>>>>> native >>>>>>>>>>>> code. >>>>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>>>> # >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Zhengyu >>>>> >> From coleen.phillimore at oracle.com Sat Jul 23 10:15:29 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 23 Jul 2011 17:15:29 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 10 new changesets Message-ID: <20110723171549.B809C4769D@hg.openjdk.java.net> Changeset: 3fbb609d9e96 Author: kvn Date: 2011-07-14 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3fbb609d9e96 7067288: compiler regression test Test7052494 timeouts with client VM Summary: Test is modified to reduce number of iterations in test5() and test6(). Reviewed-by: never, iveresov ! test/compiler/7052494/Test7052494.java Changeset: 341a57af9b0a Author: never Date: 2011-07-15 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/341a57af9b0a 6990212: JSR 292 JVMTI MethodEnter hook is not called for JSR 292 bootstrap and target methods Summary: check for single stepping when dispatching invokes from method handles Reviewed-by: coleenp, twisti, kvn, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp + test/compiler/6990212/Test6990212.java Changeset: d9dc0a55c848 Author: schien Date: 2011-05-20 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d9dc0a55c848 Added tag jdk7-b143 for changeset c149193c768b ! .hgtags Changeset: 278445be9145 Author: trims Date: 2011-05-24 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/278445be9145 Added tag hs21-b13 for changeset c149193c768b ! .hgtags Changeset: 01e01c25d24a Author: trims Date: 2011-05-24 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/01e01c25d24a Merge ! .hgtags Changeset: e6e7d76b2bd3 Author: mr Date: 2011-05-24 15:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e6e7d76b2bd3 7048009: Update .jcheck/conf files for JDK 8 Reviewed-by: jjh ! .jcheck/conf Changeset: 968305b802ee Author: trims Date: 2011-07-23 01:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/968305b802ee Merge Changeset: 8e5d4aa73a8c Author: trims Date: 2011-07-22 23:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8e5d4aa73a8c 7069176: Update the JDK version numbers in Hotspot for JDK 8 Summary: Change JDK_MINOR_VER and JDK_PREVIOUS_VERSION to reflect JDK8 values Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0cc8a70952c3 Author: trims Date: 2011-07-22 23:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0cc8a70952c3 7070061: Adjust Hotspot make/jprt.properties for new JDK8 settings Summary: Fix so the JPRT can build with -release jdk8 now Reviewed-by: ohair ! make/jprt.properties Changeset: 8107273fd204 Author: coleenp Date: 2011-07-23 10:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8107273fd204 Merge From David.Holmes at oracle.com Sun Jul 24 19:14:15 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 25 Jul 2011 12:14:15 +1000 Subject: Fwd: Code review request: 7067266 Decoder class not properly initialized on Windows In-Reply-To: <4E298986.6050705@oracle.com> References: <4E20867A.7070400@oracle.com> <20000.43691.685390.246755@oracle.com> <4E20C645.2050405@oracle.com> <4E24398D.5000506@oracle.com> <4E26EA4C.6020105@oracle.com> <4E2748C2.3090600@oracle.com> <4E2825B8.3000602@oracle.com> <4E28C51B.2060903@oracle.com> <4E298986.6050705@oracle.com> Message-ID: <4E2CD177.1010607@oracle.com> Zhengyu Gu said the following on 07/23/11 00:30: > >> If you consider it a service with explicit init/uninit then it doesn't >> really matter whether it is all static or a singleton instance. The >> issue in question is where the calls to init/uninit get placed. If the >> service is lazy-initialized then the initialization should be done >> within the operations that need it. The decision of when to >> "uninitialize" is more interesting if it is really just a "please free >> up some resources" request. >> > The advantage of singleton instance is to initialize Decoder at > Decoder::getInstance(), and not add initialize() call on every method. True. >>>> Further, if we aren't going to do any cleanup then what is the point >>>> of having uninitialize ? Seems to be dead code. >>>> >>> There is no reason to uninitialize in this case, but there is a >>> usecase (after integrates VM diagnostic functions): when VM thinks >>> that it is running out of memory. Symbol cache can grow substantially >>> on Unix platforms. >> >> Are you saying that frame decoding will be used in contexts other than >> as part of fatal error handling? If so then you will need to >> synchronize access to these resources that can be cleaned up. In which >> case it it may be better to address this current bug within that >> larger piece of work. >> > Yes, I don't intend to address those issues with this bug. Then I suggest, again, simply leaving this bug and dealing with it as part of this larger project. Cheers, David > Thanks, > > -Zhengyu > > >> David >> ----- >> >>> >>> -Zhengyu >>> >>>> David >>>> >>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> On Wed, Jul 20, 2011 at 4:46 PM, Zhengyu Gu >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Sorry for delay. I am having trouble to upload webrev to >>>>>> cr.openjdk.java.net, probably due to re-ip here. >>>>>> >>>>>> This revision, Decoder class is reverted back to AllStatic. >>>>>> Decoder::initialize() is added at Step 60, and Decoder won't be >>>>>> uninitialized. >>>>>> >>>>>> Here is the link to internal webrev: >>>>>> http://j2se.east.sun.com/~zg131198/7067266/webrev.01/ >>>>>> >>>>>> Here is the diff: >>>>>> >>>>>> bash-3.00$ hg diff >>>>>> diff --git a/src/share/vm/utilities/decoder.hpp >>>>>> b/src/share/vm/utilities/decoder.hpp >>>>>> --- a/src/share/vm/utilities/decoder.hpp >>>>>> +++ b/src/share/vm/utilities/decoder.hpp >>>>>> @@ -45,7 +45,7 @@ class ElfFile; >>>>>> #endif // _WINDOWS >>>>>> >>>>>> >>>>>> -class Decoder: public StackObj { >>>>>> +class Decoder: AllStatic { >>>>>> >>>>>> public: >>>>>> // status code for decoding native C frame >>>>>> @@ -61,9 +61,6 @@ class Decoder: public StackObj { >>>>>> }; >>>>>> >>>>>> public: >>>>>> - Decoder() { initialize(); }; >>>>>> - ~Decoder() { uninitialize(); }; >>>>>> - >>>>>> static bool can_decode_C_frame_in_vm(); >>>>>> >>>>>> static void initialize(); >>>>>> diff --git a/src/share/vm/utilities/vmError.cpp >>>>>> b/src/share/vm/utilities/vmError.cpp >>>>>> --- a/src/share/vm/utilities/vmError.cpp >>>>>> +++ b/src/share/vm/utilities/vmError.cpp >>>>>> @@ -453,6 +453,8 @@ void VMError::report(outputStream* st) { >>>>>> ); >>>>>> >>>>>> STEP(60, "(printing problematic frame)") >>>>>> + // initialize decoder to decode C frames >>>>>> + Decoder::initialize(); >>>>>> >>>>>> // Print current frame if we have a context (i.e. it's a crash) >>>>>> if (_context) { >>>>>> @@ -565,9 +567,6 @@ void VMError::report(outputStream* st) { >>>>>> // see if it's a valid frame >>>>>> if (fr.pc()) { >>>>>> st->print_cr("Native frames: (J=compiled Java code, >>>>>> j=interpreted, >>>>>> Vv=VM code, C=native code)"); >>>>>> - >>>>>> - // initialize decoder to decode C frames >>>>>> - Decoder decoder; >>>>>> >>>>>> int count = 0; >>>>>> while (count++ < StackPrintLimit) { >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> >>>>>> On 7/18/2011 10:24 AM, Volker Simonis wrote: >>>>>>> On Mon, Jul 18, 2011 at 3:47 PM, Zhengyu >>>>>>> Gu wrote: >>>>>>>> I have to disagree, I would much prefer to revert back it AllStatic >>>>>>>> implementation. Followings are the reasons: >>>>>>>> >>>>>>>> 1. Uninitialize() was intended to shutdown decoder in low memory >>>>>>>> scenarios, >>>>>>>> as the decoder is a secondary function. It may not be very clear >>>>>>>> in this >>>>>>>> usecase, but it is a scenario in the project I am currently >>>>>>>> working on. >>>>>>>> >>>>>>> I don't know what project you are working on, but in the Hotspot >>>>>>> as we >>>>>>> can see it, the Decoder::decode() functionality is only accessed >>>>>>> from >>>>>>> os::dll_address_to_function_name(). This in turn is only called from >>>>>>> two places: >>>>>>> - from the VM error handler (in vmError.cpp) trough >>>>>>> frame::print_on_error() which calls it trough print_C_frame() >>>>>>> - from the FlatProfiler trough trough FlatProfiler::record_vm_tick() >>>>>>> >>>>>>>> 2. Performance: Initial/uninitial decoder for decoding every >>>>>>>> symbol, >>>>>>>> definitely not optimal. In Unix implementation, it was >>>>>>>> programmed to >>>>>>>> maintain a symbol cache, which will not completely defeated, as >>>>>>>> it has to >>>>>>>> reopen/reparse elf file to decoder every frame. Again, decoder >>>>>>>> performance >>>>>>>> will be one of key factors for my other project. >>>>>>> I didn't propose to create a new Decoder object for the decoding of >>>>>>> each symbol. Instead a decoder object could be passed into >>>>>>> os::dll_address_to_function_name() and frame::print_on_error(). The >>>>>>> user of the functionality could then decide how long he wants to >>>>>>> keep >>>>>>> the Decoder object and its resources alive. In the case of the >>>>>>> FlatProfiler this would probably be the whole VM lifetime, for the >>>>>>> vmError use case it would be probably for the time of a complete >>>>>>> stack >>>>>>> trace. >>>>>>> >>>>>>>> I will post new webrev to reflect AllStatic implementation. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Zhengyu >>>>>>>> >>>>>>>> On 7/18/2011 5:25 AM, Volker Simonis wrote: >>>>>>>>> What about making the Decoder::decode() and all the other >>>>>>>>> methods in >>>>>>>>> the Decoder class instance methods? >>>>>>>>> Then it would be clear that users of the decode() method would >>>>>>>>> have to >>>>>>>>> create (and initialize) a Decode object and it would be their >>>>>>>>> responsibility when they create it and and when they >>>>>>>>> uninitialize and >>>>>>>>> clean it up. Depending on the platform, the Decoder class may >>>>>>>>> still >>>>>>>>> decide to keep its resources globally (as static data members) >>>>>>>>> or just >>>>>>>>> for the lifetime of a Decoder object. >>>>>>>>> >>>>>>>>> With the current solution the problem is (as pointed out by David) >>>>>>>>> that it is not clear for callers if they have to do >>>>>>>>> initialization or >>>>>>>>> not, and this even differs between Unix and Windows. >>>>>>>>> >>>>>>>>> @Zhengyu: will you prepare a new webrev or should I submit one? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Vovlker >>>>>>>>> >>>>>>>>> On Sat, Jul 16, 2011 at 12:59 AM, David >>>>>>>>> Holmes >>>>>>>>> wrote: >>>>>>>>>> John Coomes said the following on 07/16/11 07:01: >>>>>>>>>>> Zhengyu Gu (zhengyu.gu at oracle.com) wrote: >>>>>>>>>>>> Forward to openjdk for review: >>>>>>>>>>>> >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7067266/webrev.00/ >>>>>>>>>>> The change looks correct. >>>>>>>>>>> >>>>>>>>>>> It's not new in this change, but I find it strange that static >>>>>>>>>>> initialization of Decoder is triggered by creating an unused >>>>>>>>>>> instance. >>>>>>>>>>> It'd be clearer to call Decoder::initialize() instead, and then >>>>>>>>>>> there'd be no need for the comment: >>>>>>>>>>> >>>>>>>>>>> // initialize decoder to decode C frames >>>>>>>>>>> >>>>>>>>>>> Decoder should also be changed to inherit from AllStatic >>>>>>>>>>> instead of >>>>>>>>>>> StackObj, but that's getting beyond this bug fix. >>>>>>>>>> This is extremely confusing code. We have static data being >>>>>>>>>> manipulated >>>>>>>>>> by >>>>>>>>>> stack-scoped local instances, where the constructor does an >>>>>>>>>> initialize >>>>>>>>>> function and the destructor does an uninitalize that cleans up >>>>>>>>>> various >>>>>>>>>> resources. In addition we have a static function on Windows: >>>>>>>>>> >>>>>>>>>> bool Decoder::can_decode_C_frame_in_vm() { >>>>>>>>>> initialize(); >>>>>>>>>> return _can_decode_in_vm; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> which initializes but never cleans up! And the use of these two >>>>>>>>>> mechanism >>>>>>>>>> can be interspersed. >>>>>>>>>> >>>>>>>>>> To top it off we create the Decoder instances in places where >>>>>>>>>> there is >>>>>>>>>> absolutely no indication that somewhere down in the call chain >>>>>>>>>> the >>>>>>>>>> Decoder >>>>>>>>>> functionality will be used! This is truly awful code. >>>>>>>>>> >>>>>>>>>> Volker's patch to move the Decoder into print_C_frame would >>>>>>>>>> seem much >>>>>>>>>> cleaner, but even it doesn't go far enough as we have redundant >>>>>>>>>> initialize() >>>>>>>>>> in can_decode_C_frame_in_vm, and I don't see why we should be >>>>>>>>>> working >>>>>>>>>> with >>>>>>>>>> static functions instead of the Decoder object that was created. >>>>>>>>>> >>>>>>>>>> Zhengyu is concerned that the repeated init/un-init might be >>>>>>>>>> too much >>>>>>>>>> if >>>>>>>>>> moved into print_C_frame, but his fix goes to the other >>>>>>>>>> extreme by >>>>>>>>>> giving >>>>>>>>>> the Decoder "global" scope in the error reporting process so >>>>>>>>>> we won't >>>>>>>>>> do >>>>>>>>>> any >>>>>>>>>> cleanup until right at the end (where we will presumably >>>>>>>>>> terminate the >>>>>>>>>> process) - so this seems to defeat the purpose of having the >>>>>>>>>> cleanup >>>>>>>>>> code >>>>>>>>>> in >>>>>>>>>> the first place. >>>>>>>>>> >>>>>>>>>> Given that we are in the process of dying I don't see that we >>>>>>>>>> should be >>>>>>>>>> overly concerned about overhead so I'd be inclined to go with >>>>>>>>>> Volker's >>>>>>>>>> fix >>>>>>>>>> and at least do the init and cleanup in the location where the >>>>>>>>>> Decoder >>>>>>>>>> is >>>>>>>>>> actually used. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -John >>>>>>>>>>> >>>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>>> Subject: Re: Code review request: 7067266 Decoder >>>>>>>>>>>> class not >>>>>>>>>>>> properly initialized on Windows >>>>>>>>>>>> Date: Fri, 15 Jul 2011 11:52:44 -0600 >>>>>>>>>>>> From: Daniel D. Daugherty >>>>>>>>>>>> Reply-To: daniel.daugherty at oracle.com >>>>>>>>>>>> To: Zhengyu Gu >>>>>>>>>>>> CC: hotspot-runtime-dev-confidential >>>>>>>>>>>> , >>>>>>>>>>>> volker-simonis at gmail.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thumbs up on the code. >>>>>>>>>>>> >>>>>>>>>>>> Zhengyu, this came in via hotspot-runtime-dev at openjdk.java.net >>>>>>>>>>>> so this review should go out on that alias also (and the webrev >>>>>>>>>>>> copied to cr.openjdk.java.net) >>>>>>>>>>>> >>>>>>>>>>>> Dan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/15/11 11:26 AM, Zhengyu Gu wrote: >>>>>>>>>>>>> This is a simple fix that moves Decoder initialization to >>>>>>>>>>>>> step 60 in >>>>>>>>>>>>> vmError.cpp, so the decoder can decode "Problematic frame:" >>>>>>>>>>>>> in hs >>>>>>>>>>>>> file >>>>>>>>>>>>> header. >>>>>>>>>>>>> >>>>>>>>>>>>> The bug was reported by volker-simonis at gmail.com >>>>>>>>>>>>> from SAP with proposed >>>>>>>>>>>>> patch. >>>>>>>>>>>>> The >>>>>>>>>>>>> solution >>>>>>>>>>>>> was to move decoder initialization code to >>>>>>>>>>>>> print_C_frame() function, but it is less optimal, since >>>>>>>>>>>>> decoder will >>>>>>>>>>>>> have to be initialized and uninitialized every time in/out >>>>>>>>>>>>> of the >>>>>>>>>>>>> print_C_frame() function. >>>>>>>>>>>>> >>>>>>>>>>>>> CR: http://monaco.sfbay.sun.com/detail.jsf?cr=7067266 >>>>>>>>>>>>> Webrev: http://j2se.east.sun.com/~zg131198/7067266/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Testcase: >>>>>>>>>>>>> A simple Java program with JNI call that crashes VM: >>>>>>>>>>>>> >>>>>>>>>>>>> JNIEXPORT void JNICALL Java_jni_1excpt_Main_crashVM (JNIEnv *, >>>>>>>>>>>>> jclass) >>>>>>>>>>>>> { >>>>>>>>>>>>> int* p = NULL; >>>>>>>>>>>>> *p = 1; >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Without fix, hs file header: >>>>>>>>>>>>> >>>>>>>>>>>>> # >>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>>> Environment: >>>>>>>>>>>>> # >>>>>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5b431308, >>>>>>>>>>>>> pid=7860, >>>>>>>>>>>>> tid=4140 >>>>>>>>>>>>> # >>>>>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (19.0-b09 mixed mode, >>>>>>>>>>>>> sharing >>>>>>>>>>>>> windows-x86 ) >>>>>>>>>>>>> # Problematic frame: >>>>>>>>>>>>> # C [mydll.dll+0x11308] >>>>>>>>>>>>> # >>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>> # http://java.sun.com/webapps/bugreport/crash.jsp >>>>>>>>>>>>> # The crash happened outside the Java Virtual Machine in >>>>>>>>>>>>> native >>>>>>>>>>>>> code. >>>>>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>>>>> # >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> With fix: >>>>>>>>>>>>> >>>>>>>>>>>>> # >>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>>> Environment: >>>>>>>>>>>>> # >>>>>>>>>>>>> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x5c981308, >>>>>>>>>>>>> pid=1652, >>>>>>>>>>>>> tid=5964 >>>>>>>>>>>>> # >>>>>>>>>>>>> # JRE version: 6.0_23-b05 >>>>>>>>>>>>> # Java VM: Java HotSpot(TM) Client VM (21.0-b16-fastdebug >>>>>>>>>>>>> mixed mode >>>>>>>>>>>>> windows-x86 ) >>>>>>>>>>>>> # Problematic frame: >>>>>>>>>>>>> # C [mydll.dll+0x11308] Java_jni_1excpt_Main_crashVM+0x28 >>>>>>>>>>>>> # >>>>>>>>>>>>> # Failed to write core dump. Minidumps are not enabled by >>>>>>>>>>>>> default on >>>>>>>>>>>>> client versions of Windows >>>>>>>>>>>>> # >>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>> # http://bugreport.sun.com/bugreport/crash.jsp >>>>>>>>>>>>> # The crash happened outside the Java Virtual Machine in >>>>>>>>>>>>> native >>>>>>>>>>>>> code. >>>>>>>>>>>>> # See problematic frame for where to report the bug. >>>>>>>>>>>>> # >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Zhengyu >>>>>> >>> > From vladimir.kozlov at oracle.com Mon Jul 25 10:14:03 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jul 2011 10:14:03 -0700 Subject: [Fwd: Request for review (S): 6865265 JVM crashes with "missing exception handler" error] Message-ID: <4E2DA45B.6040807@oracle.com> Forwarding to RT since runtime code is also involved. Vladimir -------- Original Message -------- Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error Date: Mon, 25 Jul 2011 18:58:58 +0200 From: Volker Simonis To: hotspot compiler Although I've found a tiny test case for 6865265 and a small fix for the problem, I'm still not sure if my fix is complete. I would appreciate it very much if somebody could review my (somewhat lengthy) explanation for the fix and answer the two questions I encountered. Both, the explanation of the fix and the questions are in the webrev at: http://www.progdoc.de/webrev/6865265/ Regards, Volker From keith.mcguigan at oracle.com Mon Jul 25 11:18:01 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 25 Jul 2011 14:18:01 -0400 Subject: [Fwd: Request for review (S): 6865265 JVM crashes with "missing exception handler" error] In-Reply-To: <4E2DA45B.6040807@oracle.com> References: <4E2DA45B.6040807@oracle.com> Message-ID: <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> I think the code looks ok, but why not use a Handle for the "original_exception" in runtime.cpp -- then you don't need to worry about the GC case either. As to the question about the verifier comparing by name, this is correct (in that this is what the verifier spec requires, IIRC), but intuitively it makes sense anyway because the class's current class loader is the initiating loader for any referenced class that might need to be loaded. Thus two different references to classes with the same name will always resolve to the same class implementation so a system dictionary lookup is unnecessary. The verifier actively attempts to NOT load or initialize classes when it can, but in some cases it must, unfortunately. -- - Keith On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: > Forwarding to RT since runtime code is also involved. > > Vladimir > > -------- Original Message -------- > Subject: Request for review (S): 6865265 JVM crashes with "missing > exception handler" error > Date: Mon, 25 Jul 2011 18:58:58 +0200 > From: Volker Simonis > To: hotspot compiler > > Although I've found a tiny test case for 6865265 and a small fix for > the problem, I'm still not sure if my fix is complete. > > I would appreciate it very much if somebody could review my (somewhat > lengthy) explanation for the fix and answer the two questions I > encountered. > Both, the explanation of the fix and the questions are in the webrev > at: > > http://www.progdoc.de/webrev/6865265/ > > Regards, > Volker From vladimir.kozlov at oracle.com Mon Jul 25 11:19:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Jul 2011 11:19:32 -0700 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error In-Reply-To: <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> References: <4E2DA45B.6040807@oracle.com> <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> Message-ID: <4E2DB3B4.6040007@oracle.com> Resending to all. Keith McGuigan wrote: > > I think the code looks ok, but why not use a Handle for the > "original_exception" in runtime.cpp -- then you don't need to worry > about the GC case either. > > As to the question about the verifier comparing by name, this is correct > (in that this is what the verifier spec requires, IIRC), but intuitively > it makes sense anyway because the class's current class loader is the > initiating loader for any referenced class that might need to be > loaded. Thus two different references to classes with the same name > will always resolve to the same class implementation so a system > dictionary lookup is unnecessary. The verifier actively attempts to NOT > load or initialize classes when it can, but in some cases it must, > unfortunately. > > -- > - Keith > > > On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: > >> Forwarding to RT since runtime code is also involved. >> >> Vladimir >> >> -------- Original Message -------- >> Subject: Request for review (S): 6865265 JVM crashes with "missing >> exception handler" error >> Date: Mon, 25 Jul 2011 18:58:58 +0200 >> From: Volker Simonis >> To: hotspot compiler >> >> Although I've found a tiny test case for 6865265 and a small fix for >> the problem, I'm still not sure if my fix is complete. >> >> I would appreciate it very much if somebody could review my (somewhat >> lengthy) explanation for the fix and answer the two questions I >> encountered. >> Both, the explanation of the fix and the questions are in the webrev at: >> >> http://www.progdoc.de/webrev/6865265/ >> >> Regards, >> Volker > From volker.simonis at gmail.com Tue Jul 26 10:20:49 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Jul 2011 19:20:49 +0200 Subject: Request for review (S): 6865265 JVM crashes with "missing exception handler" error In-Reply-To: <4E2DB3B4.6040007@oracle.com> References: <4E2DA45B.6040807@oracle.com> <6C3604DF-B1DE-48C3-BAD6-6D9A50C1836B@oracle.com> <4E2DB3B4.6040007@oracle.com> Message-ID: Hi, I've made "original_exception" a Handle as suggested by Keith. Here's the new webrev: http://www.progdoc.de/webrev/6865265.v2 Regarding Keith' comments about the verification process: he's right, 'VerificationType::is_reference_assignable_from()' loads both references with the same class loader (the initiating one in this case). Initially I though that verifying if an Exception class in the class file's exception table is "java.lang.Throwable" only by name may be not enough, because a custom system class loader could load a bogus Throwable class which is different from the one loaded by the boot class loader. But I've just verified that such a scenario is prohibited by 'ClassLoader.defineClass()' which is final and rejects the loading of classes from the 'java.' package. Regards, Volker On Mon, Jul 25, 2011 at 8:19 PM, Vladimir Kozlov wrote: > Resending to all. > > Keith McGuigan wrote: >> >> I think the code looks ok, but why not use a Handle for the >> "original_exception" in runtime.cpp -- then you don't need to worry about >> the GC case either. >> >> As to the question about the verifier comparing by name, this is correct >> (in that this is what the verifier spec requires, IIRC), but intuitively it >> makes sense anyway because the class's current class loader is the >> initiating loader for any referenced class that might need to be loaded. >> ?Thus two different references to classes with the same name will always >> resolve to the same class implementation so a system dictionary lookup is >> unnecessary. ?The verifier actively attempts to NOT load or initialize >> classes when it can, but in some cases it must, unfortunately. >> >> -- >> - Keith >> >> >> On Jul 25, 2011, at 1:14 PM, Vladimir Kozlov wrote: >> >>> Forwarding to RT since runtime code is also involved. >>> >>> Vladimir >>> >>> -------- Original Message -------- >>> Subject: Request for review (S): 6865265 JVM crashes with "missing >>> exception handler" error >>> Date: Mon, 25 Jul 2011 18:58:58 +0200 >>> From: Volker Simonis >>> To: hotspot compiler >>> >>> Although I've found a tiny test case for 6865265 and a small fix for >>> the problem, I'm still not sure if my fix is complete. >>> >>> I would appreciate it very much if somebody could review my (somewhat >>> lengthy) explanation for the fix and answer the two questions I >>> encountered. >>> Both, the explanation of the fix and the questions are in the webrev at: >>> >>> http://www.progdoc.de/webrev/6865265/ >>> >>> Regards, >>> Volker >> > From coleen.phillimore at oracle.com Tue Jul 26 11:45:53 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jul 2011 14:45:53 -0400 Subject: gatekeeping Message-ID: <4E2F0B61.40605@oracle.com> http://j2se.us.oracle.com/web/bin/view/HotspotRuntime/GateKeepingInfo philli% hg version Mercurial Distributed SCM (version 1.7.3) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2010 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. philli% which hg /opt/csw/bin/hg scripts attached: /net/philli.us.oracle.com/scratch1/coleenp/gk/{hg_merge.csh,hg_checkin.csh} argument is target repository that you want to go back to. hotspot-runtime-dev at openjdk.java.net notification Also copy /home/coleenp/.hgrc http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/latest/ Bugs: report bug and put sqebug in the keyword and the full test name. look in /home/coleenp/bin/ssh_agent cd rt-merge-to-hotspot-{main,rt} hg fout === shows changes that are going back towards target repository From coleen.phillimore at oracle.com Tue Jul 26 11:56:35 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Jul 2011 14:56:35 -0400 Subject: gatekeeping In-Reply-To: <4E2F0B61.40605@oracle.com> References: <4E2F0B61.40605@oracle.com> Message-ID: <4E2F0DE3.9020801@oracle.com> oops, ignore this. I sent it by mistake (trying to get email to auto-complete the openjdk address). On 7/26/2011 2:45 PM, Coleen Phillimore wrote: > http://j2se.us.oracle.com/web/bin/view/HotspotRuntime/GateKeepingInfo > > philli% hg version > Mercurial Distributed SCM (version 1.7.3) > (see http://mercurial.selenic.com for more information) > > Copyright (C) 2005-2010 Matt Mackall and others > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > philli% which hg > /opt/csw/bin/hg > > scripts attached: > > /net/philli.us.oracle.com/scratch1/coleenp/gk/{hg_merge.csh,hg_checkin.csh} > argument is target repository that you want to go back to. > > hotspot-runtime-dev at openjdk.java.net notification > > Also copy /home/coleenp/.hgrc > > http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/latest/ > > Bugs: report bug and put sqebug in the keyword and the full test name. > > look in /home/coleenp/bin/ssh_agent > > cd rt-merge-to-hotspot-{main,rt} > > hg fout === shows changes that are going back towards target > repository From keith.mcguigan at oracle.com Thu Jul 28 17:21:49 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Fri, 29 Jul 2011 00:21:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7072341: enable hotspot builds on Linux 3.0 Message-ID: <20110729002154.6DB38477C4@hg.openjdk.java.net> Changeset: ca1f1753c866 Author: andrew Date: 2011-07-28 14:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca1f1753c866 7072341: enable hotspot builds on Linux 3.0 Summary: Add "3" to list of allowable versions Reviewed-by: kamg, chrisphi ! make/linux/Makefile From ahughes at redhat.com Thu Jul 28 17:26:42 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 29 Jul 2011 01:26:42 +0100 Subject: hg: hsx/hotspot-rt/hotspot: 7072341: enable hotspot builds on Linux 3.0 In-Reply-To: <20110729002154.6DB38477C4@hg.openjdk.java.net> References: <20110729002154.6DB38477C4@hg.openjdk.java.net> Message-ID: <20110729002642.GC22822@rivendell.middle-earth.co.uk> On 00:21 Fri 29 Jul , keith.mcguigan at oracle.com wrote: > Changeset: ca1f1753c866 > Author: andrew > Date: 2011-07-28 14:10 -0400 > URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ca1f1753c866 > > 7072341: enable hotspot builds on Linux 3.0 > Summary: Add "3" to list of allowable versions > Reviewed-by: kamg, chrisphi > > ! make/linux/Makefile > Thanks Keith. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37