From jeremymanson at google.com Fri Jun 5 14:25:39 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 5 Jun 2009 14:25:39 -0700 Subject: JVMTI OOM handling when arrays / objects are too large Message-ID: Hi folks, I was talking to some of the HS team at JavaOne, and they encouraged me to send some of the patches that we are working on at Google back to Sun. (Everyone at Google is covered under a blanket SCA, so we can contribute back anything done by any Googler). To get started and test the waters, and because I have never tried to contribute to OpenJDK before, I thought I would send on a nearly-trivial fix that I made last year in response to a user complaint. The issue was that when the user specifies -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError command would not be executed. I've attached the patch. Let me know what I should do to proceed. Thanks! Jeremy -------------- next part -------------- # HG changeset patch # User jeremymanson at iago.mtv.corp.google.com # Date 1244235210 25200 # Node ID cf2fd9253952b92e24b982f83ba1bc2faf584e8b # Parent aa0c48844632739a1efa8ff78f24ff4017fda89f JVMTI does not execute post_resource_exhausted when allocating arrays close to Integer.MAX_VALUE. diff -r aa0c48844632 -r cf2fd9253952 src/share/vm/gc_interface/collectedHeap.inline.hpp --- a/src/share/vm/gc_interface/collectedHeap.inline.hpp Thu May 14 10:57:58 2009 -0700 +++ b/src/share/vm/gc_interface/collectedHeap.inline.hpp Fri Jun 05 13:53:30 2009 -0700 @@ -135,28 +135,14 @@ HeapWord* CollectedHeap::common_mem_allo } - if (!gc_overhead_limit_was_exceeded) { - // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support - report_java_out_of_memory("Java heap space"); - - if (JvmtiExport::should_post_resource_exhausted()) { - JvmtiExport::post_resource_exhausted( - JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, - "Java heap space"); - } - - THROW_OOP_0(Universe::out_of_memory_error_java_heap()); + if (!gc_overhead_limit_was_exceeded) { + THROW_OOM("Java heap space", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, + Universe::out_of_memory_error_java_heap()); } else { - // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support - report_java_out_of_memory("GC overhead limit exceeded"); - - if (JvmtiExport::should_post_resource_exhausted()) { - JvmtiExport::post_resource_exhausted( - JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, - "GC overhead limit exceeded"); - } - - THROW_OOP_0(Universe::out_of_memory_error_gc_overhead_limit()); + THROW_OOM("GC overhead limit exceeded", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, + Universe::out_of_memory_error_gc_overhead_limit()); } } @@ -191,16 +177,10 @@ HeapWord* CollectedHeap::common_permanen "Unexpected exception, will result in uninitialized storage"); return result; } - // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support - report_java_out_of_memory("PermGen space"); - if (JvmtiExport::should_post_resource_exhausted()) { - JvmtiExport::post_resource_exhausted( - JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR, - "PermGen space"); - } - - THROW_OOP_0(Universe::out_of_memory_error_perm_gen()); + THROW_OOM("PermGen space", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR, + Universe::out_of_memory_error_perm_gen()); } HeapWord* CollectedHeap::common_permanent_mem_allocate_init(size_t size, TRAPS) { diff -r aa0c48844632 -r cf2fd9253952 src/share/vm/oops/arrayKlass.cpp --- a/src/share/vm/oops/arrayKlass.cpp Thu May 14 10:57:58 2009 -0700 +++ b/src/share/vm/oops/arrayKlass.cpp Fri Jun 05 13:53:30 2009 -0700 @@ -140,7 +140,10 @@ objArrayOop arrayKlass::allocate_arrayAr THROW_0(vmSymbols::java_lang_NegativeArraySizeException()); } if (length > arrayOopDesc::max_array_length(T_ARRAY)) { - THROW_OOP_0(Universe::out_of_memory_error_array_size()); + THROW_OOM("Java heap space", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | + JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, + Universe::out_of_memory_error_array_size()); } int size = objArrayOopDesc::object_size(length); klassOop k = array_klass(n+dimension(), CHECK_0); diff -r aa0c48844632 -r cf2fd9253952 src/share/vm/oops/instanceKlass.cpp --- a/src/share/vm/oops/instanceKlass.cpp Thu May 14 10:57:58 2009 -0700 +++ b/src/share/vm/oops/instanceKlass.cpp Fri Jun 05 13:53:30 2009 -0700 @@ -497,7 +497,10 @@ objArrayOop instanceKlass::allocate_objA objArrayOop instanceKlass::allocate_objArray(int n, int length, TRAPS) { if (length < 0) THROW_0(vmSymbols::java_lang_NegativeArraySizeException()); if (length > arrayOopDesc::max_array_length(T_OBJECT)) { - THROW_OOP_0(Universe::out_of_memory_error_array_size()); + THROW_OOM("Java heap space", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | + JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, + Universe::out_of_memory_error_array_size()); } int size = objArrayOopDesc::object_size(length); klassOop ak = array_klass(n, CHECK_NULL); diff -r aa0c48844632 -r cf2fd9253952 src/share/vm/oops/objArrayKlass.cpp --- a/src/share/vm/oops/objArrayKlass.cpp Thu May 14 10:57:58 2009 -0700 +++ b/src/share/vm/oops/objArrayKlass.cpp Fri Jun 05 13:53:30 2009 -0700 @@ -39,7 +39,10 @@ objArrayOop objArrayKlass::allocate(int assert(a->is_parsable(), "Can't publish unless parsable"); return a; } else { - THROW_OOP_0(Universe::out_of_memory_error_array_size()); + THROW_OOM("Java heap space", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | + JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, + Universe::out_of_memory_error_array_size()); } } else { THROW_0(vmSymbols::java_lang_NegativeArraySizeException()); diff -r aa0c48844632 -r cf2fd9253952 src/share/vm/oops/typeArrayKlass.cpp --- a/src/share/vm/oops/typeArrayKlass.cpp Thu May 14 10:57:58 2009 -0700 +++ b/src/share/vm/oops/typeArrayKlass.cpp Fri Jun 05 13:53:30 2009 -0700 @@ -80,7 +80,10 @@ typeArrayOop typeArrayKlass::allocate(in assert(t->is_parsable(), "Don't publish unless parsable"); return t; } else { - THROW_OOP_0(Universe::out_of_memory_error_array_size()); + THROW_OOM("Java heap space", + JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | + JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP, + Universe::out_of_memory_error_array_size()); } } else { THROW_0(vmSymbols::java_lang_NegativeArraySizeException()); diff -r aa0c48844632 -r cf2fd9253952 src/share/vm/utilities/exceptions.hpp --- a/src/share/vm/utilities/exceptions.hpp Thu May 14 10:57:58 2009 -0700 +++ b/src/share/vm/utilities/exceptions.hpp Fri Jun 05 13:53:30 2009 -0700 @@ -240,6 +240,15 @@ class Exceptions { #define THROW_NULL(name) THROW_(name, NULL) #define THROW_MSG_NULL(name, message) THROW_MSG_(name, message, NULL) +#define THROW_OOM(message, flags, exception) \ + do { \ + report_java_out_of_memory((message)); \ + if (JvmtiExport::should_post_resource_exhausted()) { \ + JvmtiExport::post_resource_exhausted((flags), (message)); \ + } \ + THROW_OOP_0((exception)); \ + } while (0) + // The CATCH macro checks that no exception has been thrown by a function; it is used at // call sites about which is statically known that the callee cannot throw an exception // even though it is declared with TRAPS. From Tim.Bell at Sun.COM Fri Jun 5 16:31:00 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 05 Jun 2009 16:31:00 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: Message-ID: <4A29AAB4.5070902@sun.com> Hi Jeremy > I was talking to some of the HS team at JavaOne, and they encouraged > me to send some of the patches that we are working on at Google back > to Sun. (Everyone at Google is covered under a blanket SCA, so we can > contribute back anything done by any Googler). > > To get started and test the waters, and because I have never tried to > contribute to OpenJDK before, I thought I would send on a > nearly-trivial fix that I made last year in response to a user > complaint. The issue was that when the user specifies > -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory > allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError > command would not be executed. I've attached the patch. Let me know > what I should do to proceed. I created a bugzilla report for this issue: https://bugs.openjdk.java.net/show_bug.cgi?id=100067 That way we won't lose it in a pile of email. Tim From jeremymanson at google.com Sat Jun 6 09:38:29 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Sat, 6 Jun 2009 09:38:29 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A29AAB4.5070902@sun.com> References: <4A29AAB4.5070902@sun.com> Message-ID: Thanks Tim! Martin Buchholz tells me that three things have to happen to get a patch in: 1) Someone inside Sun has to file a bug. Usually, this seems to be in the other bug database, but I guess it doesn't matter? 2) Two OpenJDK members have to review it (in practice). Is my understanding correct? Jeremy On Fri, Jun 5, 2009 at 4:31 PM, Tim Bell wrote: > Hi Jeremy >> >> I was talking to some of the HS team at JavaOne, and they encouraged >> me to send some of the patches that we are working on at Google back >> to Sun. ?(Everyone at Google is covered under a blanket SCA, so we can >> contribute back anything done by any Googler). >> >> To get started and test the waters, and because I have never tried to >> contribute to OpenJDK before, I thought I would send on a >> nearly-trivial fix that I made last year in response to a user >> complaint. ?The issue was that when the user specifies >> -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory >> allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError >> command would not be executed. ?I've attached the patch. ?Let me know >> what I should do to proceed. > > I created a bugzilla report for this issue: > > https://bugs.openjdk.java.net/show_bug.cgi?id=100067 > > That way we won't lose it in a pile of email. > > Tim > From Tim.Bell at Sun.COM Sun Jun 7 12:31:32 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sun, 07 Jun 2009 12:31:32 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A29AAB4.5070902@sun.com> Message-ID: <4A2C1594.9020602@sun.com> Hi Jeremy > Martin Buchholz tells me that three things have to happen to get a patch in: Hi Martin :-) > 1) Someone inside Sun has to file a bug. Usually, this seems to be in > the other bug database, but I guess it doesn't matter? We hope to get a bridge working between the external bugzilla system (good!) and the internal, proprietary bug tracking system (bad!). Hopefully after we all recover from JavaOne week. > 2) Two OpenJDK members have to review it (in practice). One reviewer is required until the late stages of a release, then two reviewers. Of course, more reviewers are always better. > Is my understanding correct? What are the chances of getting a jtreg test case for this issue? Tests that attempt to exhaust the heap are usually problematical, but it would be worth a try. Nice to have if we can get a test. Tim > Jeremy > > On Fri, Jun 5, 2009 at 4:31 PM, Tim Bell wrote: >> Hi Jeremy >>> I was talking to some of the HS team at JavaOne, and they encouraged >>> me to send some of the patches that we are working on at Google back >>> to Sun. (Everyone at Google is covered under a blanket SCA, so we can >>> contribute back anything done by any Googler). >>> >>> To get started and test the waters, and because I have never tried to >>> contribute to OpenJDK before, I thought I would send on a >>> nearly-trivial fix that I made last year in response to a user >>> complaint. The issue was that when the user specifies >>> -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory >>> allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError >>> command would not be executed. I've attached the patch. Let me know >>> what I should do to proceed. >> I created a bugzilla report for this issue: >> >> https://bugs.openjdk.java.net/show_bug.cgi?id=100067 >> >> That way we won't lose it in a pile of email. >> >> Tim >> From martinrb at google.com Mon Jun 8 11:41:28 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 Jun 2009 11:41:28 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> Message-ID: <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> The ever-popular test jdk/test/java/lang/ProcessBuilder/Basic.java has infrastructure for testing this fix. It would still be quite annoying to write portably, involving 3 separate JDKs. Martin On Mon, Jun 8, 2009 at 11:31, Jeremy Manson wrote: > This one happens to be pretty easy to trigger. I'm not sure how to > put together a jtreg test, but the following code works: > > public class OOM { > public static void main(String[] args) throws Exception { > int size = Integer.MAX_VALUE; > Integer[] props = new Integer[size]; > } > } > > And then invoke it: > > java -XX:OnOutOfMemoryError="echo PASS" OOM > > If it prints out "PASS", it works. My understanding is that jtreg > tests fail by throwing an exception, so this whole thing would > probably have to be wrapped in another Java program that throws an > exception if it doesn't see "PASS" in the output. > > Jeremy > > On Sun, Jun 7, 2009 at 12:31 PM, Tim Bell wrote: > > Hi Jeremy > >> > >> Martin Buchholz tells me that three things have to happen to get a patch > >> in: > > > > Hi Martin :-) > > > >> 1) Someone inside Sun has to file a bug. Usually, this seems to be in > >> the other bug database, but I guess it doesn't matter? > > > > We hope to get a bridge working between the external bugzilla system > > (good!) and the internal, proprietary bug tracking system (bad!). > > Hopefully after we all recover from JavaOne week. > > > >> 2) Two OpenJDK members have to review it (in practice). > > > > One reviewer is required until the late stages of a release, then > > two reviewers. Of course, more reviewers are always better. > > > >> Is my understanding correct? > > > > What are the chances of getting a jtreg test case for this issue? > > > > Tests that attempt to exhaust the heap are usually problematical, > > but it would be worth a try. Nice to have if we can get a test. > > > > Tim > > > > > >> Jeremy > >> > >> On Fri, Jun 5, 2009 at 4:31 PM, Tim Bell wrote: > >>> > >>> Hi Jeremy > >>>> > >>>> I was talking to some of the HS team at JavaOne, and they encouraged > >>>> me to send some of the patches that we are working on at Google back > >>>> to Sun. (Everyone at Google is covered under a blanket SCA, so we can > >>>> contribute back anything done by any Googler). > >>>> > >>>> To get started and test the waters, and because I have never tried to > >>>> contribute to OpenJDK before, I thought I would send on a > >>>> nearly-trivial fix that I made last year in response to a user > >>>> complaint. The issue was that when the user specifies > >>>> -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory > >>>> allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError > >>>> command would not be executed. I've attached the patch. Let me know > >>>> what I should do to proceed. > >>> > >>> I created a bugzilla report for this issue: > >>> > >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100067 > >>> > >>> That way we won't lose it in a pile of email. > >>> > >>> Tim > >>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090608/05e04a0f/attachment.html From jeremymanson at google.com Mon Jun 8 11:31:25 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 8 Jun 2009 11:31:25 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A2C1594.9020602@sun.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> Message-ID: This one happens to be pretty easy to trigger. I'm not sure how to put together a jtreg test, but the following code works: public class OOM { public static void main(String[] args) throws Exception { int size = Integer.MAX_VALUE; Integer[] props = new Integer[size]; } } And then invoke it: java -XX:OnOutOfMemoryError="echo PASS" OOM If it prints out "PASS", it works. My understanding is that jtreg tests fail by throwing an exception, so this whole thing would probably have to be wrapped in another Java program that throws an exception if it doesn't see "PASS" in the output. Jeremy On Sun, Jun 7, 2009 at 12:31 PM, Tim Bell wrote: > Hi Jeremy >> >> Martin Buchholz tells me that three things have to happen to get a patch >> in: > > Hi Martin :-) > >> 1) Someone inside Sun has to file a bug. ?Usually, this seems to be in >> the other bug database, but I guess it doesn't matter? > > We hope to get a bridge working between the external bugzilla system > (good!) and the internal, proprietary bug tracking system (bad!). > Hopefully after we all recover from JavaOne week. > >> 2) Two OpenJDK members have to review it (in practice). > > One reviewer is required until the late stages of a release, then > two reviewers. ?Of course, more reviewers are always better. > >> Is my understanding correct? > > What are the chances of getting a jtreg test case for this issue? > > Tests that attempt to exhaust the heap are usually problematical, > but it would be worth a try. ?Nice to have if we can get a test. > > Tim > > >> Jeremy >> >> On Fri, Jun 5, 2009 at 4:31 PM, Tim Bell wrote: >>> >>> Hi Jeremy >>>> >>>> I was talking to some of the HS team at JavaOne, and they encouraged >>>> me to send some of the patches that we are working on at Google back >>>> to Sun. ?(Everyone at Google is covered under a blanket SCA, so we can >>>> contribute back anything done by any Googler). >>>> >>>> To get started and test the waters, and because I have never tried to >>>> contribute to OpenJDK before, I thought I would send on a >>>> nearly-trivial fix that I made last year in response to a user >>>> complaint. ?The issue was that when the user specifies >>>> -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory >>>> allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError >>>> command would not be executed. ?I've attached the patch. ?Let me know >>>> what I should do to proceed. >>> >>> I created a bugzilla report for this issue: >>> >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100067 >>> >>> That way we won't lose it in a pile of email. >>> >>> Tim >>> > > From john.coomes at sun.com Fri Jun 12 00:00:49 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 07:00:49 +0000 Subject: hg: jdk7/hotspot-rt: 6 new changesets Message-ID: <20090612070049.3DA41E507@hg.openjdk.java.net> Changeset: a942ea653d97 Author: aph Date: 2009-04-17 15:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/a942ea653d97 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/sanity-rules.gmk Changeset: f5ab6d6ae4b1 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/f5ab6d6ae4b1 Merge - make/jprt.config Changeset: 37fad8722d92 Author: ohair Date: 2009-03-26 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/37fad8722d92 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config Changeset: b284e021293c Author: ohair Date: 2009-05-08 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/b284e021293c Merge Changeset: 39565502682c Author: ohair Date: 2009-05-15 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/39565502682c Merge Changeset: 472c21584cfd Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/472c21584cfd Added tag jdk7-b60 for changeset 39565502682c ! .hgtags From john.coomes at sun.com Fri Jun 12 00:07:22 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 07:07:22 +0000 Subject: hg: jdk7/hotspot-rt/corba: 6 new changesets Message-ID: <20090612070728.61CF1E50D@hg.openjdk.java.net> Changeset: 7b47536c234e Author: ohair Date: 2009-03-26 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/7b47536c234e 6822374: Windows: detect X64 when PROCESSOR_IDENTIFIER contains EM64T or Intel64 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell ! make/common/shared/Platform.gmk - make/jprt.config Changeset: 39aa6ae82075 Author: ohair Date: 2009-05-08 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/39aa6ae82075 Merge Changeset: da27d54e06bd Author: ohair Date: 2009-05-15 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/da27d54e06bd Merge Changeset: 5dcbe748e580 Author: ohair Date: 2009-05-19 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/5dcbe748e580 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: f1e1cccbd13a Author: ohair Date: 2009-05-19 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/f1e1cccbd13a 6733313: corba build warnings: /bin/sh: gcc: not found Reviewed-by: tbell ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-sun.gmk Changeset: e906b16a12a9 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/e906b16a12a9 Added tag jdk7-b60 for changeset f1e1cccbd13a ! .hgtags From john.coomes at sun.com Fri Jun 12 00:18:33 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 07:18:33 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 8 new changesets Message-ID: <20090612071845.B34FAE512@hg.openjdk.java.net> Changeset: 19c316392d9e Author: aph Date: 2009-04-17 15:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/19c316392d9e 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile ! make/build.xml Changeset: 7967d26b229c Author: aph Date: 2009-04-20 19:00 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/7967d26b229c 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 04af70c1189c Author: ohair Date: 2009-05-06 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/04af70c1189c 6837665: Deal with windows ant problem where commas in -D options do not work Reviewed-by: xdono ! make/Makefile ! make/build.properties Changeset: 44e5ca2a846c Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/44e5ca2a846c Merge Changeset: 0ea9bb9c6ddc Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/0ea9bb9c6ddc Merge - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: cdc8761f136a Author: ohair Date: 2009-05-15 13:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/cdc8761f136a Merge Changeset: 259aef5045a1 Author: ohair Date: 2009-05-19 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/259aef5045a1 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: f1ac756616ea Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/f1ac756616ea Added tag jdk7-b60 for changeset 259aef5045a1 ! .hgtags From john.coomes at sun.com Fri Jun 12 00:25:13 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 07:25:13 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 8 new changesets Message-ID: <20090612072523.EC796E517@hg.openjdk.java.net> Changeset: a92183572d99 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/a92183572d99 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile ! make/build.xml Changeset: ab30d5761947 Author: aph Date: 2009-04-20 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/ab30d5761947 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 35c29ff8d904 Author: ohair Date: 2009-05-06 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/35c29ff8d904 6837665: Deal with windows ant problem where commas in -D options do not work Reviewed-by: xdono ! make/Makefile ! make/build.properties Changeset: d95fec0fa489 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/d95fec0fa489 Merge ! make/Makefile ! make/build.xml - src/share/classes/com/sun/tools/internal/txw2/AntErrorListener.java - src/share/classes/com/sun/tools/internal/txw2/ConsoleErrorReporter.java - src/share/classes/com/sun/tools/internal/txw2/ErrorListener.java - src/share/classes/com/sun/tools/internal/txw2/Main.java - src/share/classes/com/sun/tools/internal/txw2/NameUtil.java - src/share/classes/com/sun/tools/internal/txw2/RELAXNGLoader.java - src/share/classes/com/sun/tools/internal/txw2/SchemaBuilder.java - src/share/classes/com/sun/tools/internal/txw2/TxwOptions.java - src/share/classes/com/sun/tools/internal/txw2/TxwTask.java - src/share/classes/com/sun/tools/internal/txw2/XmlSchemaLoader.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/AnnotationsImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/CommentListImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DataPatternBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DatatypeFactory.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/DivImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/ElementAnnotationBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/GrammarSectionImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/SchemaBuilderImpl.java - src/share/classes/com/sun/tools/internal/txw2/builder/relaxng/package.html - src/share/classes/com/sun/tools/internal/txw2/builder/xsd/XmlSchemaBuilder.java - src/share/classes/com/sun/tools/internal/txw2/builder/xsd/package.html - src/share/classes/com/sun/tools/internal/txw2/model/Attribute.java - src/share/classes/com/sun/tools/internal/txw2/model/CycleIterator.java - src/share/classes/com/sun/tools/internal/txw2/model/Data.java - src/share/classes/com/sun/tools/internal/txw2/model/Define.java - src/share/classes/com/sun/tools/internal/txw2/model/Element.java - src/share/classes/com/sun/tools/internal/txw2/model/Empty.java - src/share/classes/com/sun/tools/internal/txw2/model/Grammar.java - src/share/classes/com/sun/tools/internal/txw2/model/Leaf.java - src/share/classes/com/sun/tools/internal/txw2/model/List.java - src/share/classes/com/sun/tools/internal/txw2/model/Node.java - src/share/classes/com/sun/tools/internal/txw2/model/NodeSet.java - src/share/classes/com/sun/tools/internal/txw2/model/Ref.java - src/share/classes/com/sun/tools/internal/txw2/model/Text.java - src/share/classes/com/sun/tools/internal/txw2/model/Value.java - src/share/classes/com/sun/tools/internal/txw2/model/WriterNode.java - src/share/classes/com/sun/tools/internal/txw2/model/XmlNode.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/AttributeProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/ElementProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/LeafElementProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/Prop.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/ValueProp.java - src/share/classes/com/sun/tools/internal/txw2/model/prop/XmlItemProp.java - src/share/classes/com/sun/tools/internal/ws/processor/Processor.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorAction.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorActionVersion.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorConstants.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorNotificationListener.java - src/share/classes/com/sun/tools/internal/ws/processor/ProcessorOptions.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ClassModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/Configuration.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ConfigurationException.java - src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerChainInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/HandlerInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/ModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/WSDLModelInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ClassModelParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/CustomizationParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/InputParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/JAXWSBindingInfoParser.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/ParserUtil.java - src/share/classes/com/sun/tools/internal/ws/processor/config/parser/Reader.java - src/share/classes/com/sun/tools/internal/ws/processor/generator/JAXBTypeGenerator.java - src/share/classes/com/sun/tools/internal/ws/processor/generator/SimpleToBoxedUtil.java - src/share/classes/com/sun/tools/internal/ws/processor/modeler/ModelerUtils.java - src/share/classes/com/sun/tools/internal/ws/processor/modeler/annotation/WebServiceReferenceCollector.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ClientProcessorEnvironment.java - src/share/classes/com/sun/tools/internal/ws/processor/util/GeneratedFileInfo.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironment.java - src/share/classes/com/sun/tools/internal/ws/processor/util/ProcessorEnvironmentBase.java - src/share/classes/com/sun/tools/internal/ws/util/JAXWSClassFactory.java - src/share/classes/com/sun/tools/internal/ws/util/JavaCompilerHelper.java - src/share/classes/com/sun/tools/internal/ws/util/MapBase.java - src/share/classes/com/sun/tools/internal/ws/util/ToolBase.java - src/share/classes/com/sun/tools/internal/ws/util/xml/NodeListIterator.java - src/share/classes/com/sun/tools/internal/ws/util/xml/NullEntityResolver.java - src/share/classes/com/sun/tools/internal/ws/util/xml/PrettyPrintingXmlWriter.java - src/share/classes/com/sun/tools/internal/ws/util/xml/XmlWriter.java - src/share/classes/com/sun/tools/internal/ws/wscompile/ActionConstants.java - src/share/classes/com/sun/tools/internal/ws/wscompile/CompileTool.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/BuiltInTypes.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/Schema.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaAttribute.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaDocument.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaElement.java - src/share/classes/com/sun/tools/internal/ws/wsdl/document/schema/SchemaEntity.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extensible.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/Extension.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParserContext.java - src/share/classes/com/sun/tools/internal/ws/wsdl/framework/WriterContext.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandler.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/ExtensionHandlerBase.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaExtensionHandler.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaParser.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/SchemaWriter.java - src/share/classes/com/sun/tools/internal/ws/wsdl/parser/WSDLWriter.java - src/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/DOM4JLocator.java - src/share/classes/com/sun/tools/internal/xjc/util/XMLStreamReaderToContentHandler.java - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.png - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/packages.vsd - src/share/classes/com/sun/xml/internal/bind/v2/doc-files/readme.txt - src/share/classes/com/sun/xml/internal/ws/binding/http/HTTPBindingImpl.java - src/share/classes/com/sun/xml/internal/ws/binding/soap/SOAPBindingImpl.java - src/share/classes/com/sun/xml/internal/ws/client/AsyncHandlerService.java - src/share/classes/com/sun/xml/internal/ws/client/ClientConfigurationException.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoBase.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListImpl.java - src/share/classes/com/sun/xml/internal/ws/client/ContactInfoListIteratorBase.java - src/share/classes/com/sun/xml/internal/ws/client/ContextMap.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFBase.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFContext.java - src/share/classes/com/sun/xml/internal/ws/client/EndpointIFInvocationHandler.java - src/share/classes/com/sun/xml/internal/ws/client/InternalBindingProvider.java - src/share/classes/com/sun/xml/internal/ws/client/PortInfoBase.java - src/share/classes/com/sun/xml/internal/ws/client/ServiceContext.java - src/share/classes/com/sun/xml/internal/ws/client/ServiceContextBuilder.java - src/share/classes/com/sun/xml/internal/ws/client/WSFuture.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchBase.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/DispatchContext.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/ResponseImpl.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchContactInfoList.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/DispatchDelegate.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchSerializer.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/encoding/DispatchUtil.java - src/share/classes/com/sun/xml/internal/ws/client/dispatch/impl/protocol/MessageDispatcherHelper.java - src/share/classes/com/sun/xml/internal/ws/encoding/EncoderDecoderBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentMarshaller.java - src/share/classes/com/sun/xml/internal/ws/encoding/JAXWSAttachmentUnmarshaller.java - src/share/classes/com/sun/xml/internal/ws/encoding/internal/InternalEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBeanInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBBridgeInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/JAXBTypeSerializer.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayload.java - src/share/classes/com/sun/xml/internal/ws/encoding/jaxb/RpcLitPayloadSerializer.java - src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/EncoderUtils.java - src/share/classes/com/sun/xml/internal/ws/encoding/simpletype/SimpleTypeConstants.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/ClientEncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/EncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEPTFactory.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/SOAPVersion.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/ServerEncoderDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAP12XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/client/SOAPXMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/AttachmentBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/BodyBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/DelegateBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/HeaderBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/InternalMessage.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/MessageInfoBase.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/internal/SOAP12NotUnderstoodHeaderBlock.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCode.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultCodeEnum.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReason.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultReasonText.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/FaultSubcode.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAP12FaultInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPFaultInfo.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgCreateException.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/message/SOAPMsgFactoryCreateException.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/ProviderSED.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAP12XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/soap/server/SOAPXMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLDecoder.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEPTFactory.java - src/share/classes/com/sun/xml/internal/ws/encoding/xml/XMLEncoder.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerChainCaller.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/HandlerResolverImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/MessageContextUtil.java - src/share/classes/com/sun/xml/internal/ws/handler/SHDSOAPMessageContext.java - src/share/classes/com/sun/xml/internal/ws/handler/SOAPHandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLHandlerContext.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageContextImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/XMLLogicalMessageImpl.java - src/share/classes/com/sun/xml/internal/ws/handler/package-info.java - src/share/classes/com/sun/xml/internal/ws/model/CheckedException.java - src/share/classes/com/sun/xml/internal/ws/model/ExceptionType.java - src/share/classes/com/sun/xml/internal/ws/model/JavaMethod.java - src/share/classes/com/sun/xml/internal/ws/model/Mode.java - src/share/classes/com/sun/xml/internal/ws/model/Parameter.java - src/share/classes/com/sun/xml/internal/ws/model/ParameterBinding.java - src/share/classes/com/sun/xml/internal/ws/model/RuntimeModel.java - src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPBinding.java - src/share/classes/com/sun/xml/internal/ws/model/soap/SOAPRuntimeModel.java - src/share/classes/com/sun/xml/internal/ws/model/soap/Style.java - src/share/classes/com/sun/xml/internal/ws/model/soap/Use.java - src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModeler.java - src/share/classes/com/sun/xml/internal/ws/modeler/RuntimeModelerException.java - src/share/classes/com/sun/xml/internal/ws/pept/Delegate.java - src/share/classes/com/sun/xml/internal/ws/pept/encoding/Decoder.java - src/share/classes/com/sun/xml/internal/ws/pept/encoding/Encoder.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/Acceptor.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfo.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoList.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/ContactInfoListIterator.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/EPTFactory.java - src/share/classes/com/sun/xml/internal/ws/pept/ept/MessageInfo.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/MessageStruct.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/Stub.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/TargetFinder.java - src/share/classes/com/sun/xml/internal/ws/pept/presentation/Tie.java - src/share/classes/com/sun/xml/internal/ws/pept/protocol/Interceptors.java - src/share/classes/com/sun/xml/internal/ws/pept/protocol/MessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/client/SOAPMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/ProviderSOAPMD.java - src/share/classes/com/sun/xml/internal/ws/protocol/soap/server/SOAPMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/client/XMLMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/ProviderXMLMD.java - src/share/classes/com/sun/xml/internal/ws/protocol/xml/server/XMLMessageDispatcher.java - src/share/classes/com/sun/xml/internal/ws/server/AppMsgContextImpl.java - src/share/classes/com/sun/xml/internal/ws/server/DocInfo.java - src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryBase.java - src/share/classes/com/sun/xml/internal/ws/server/EPTFactoryFactoryBase.java - src/share/classes/com/sun/xml/internal/ws/server/PeptTie.java - src/share/classes/com/sun/xml/internal/ws/server/RuntimeContext.java - src/share/classes/com/sun/xml/internal/ws/server/RuntimeEndpointInfo.java - src/share/classes/com/sun/xml/internal/ws/server/TargetFinderImpl.java - src/share/classes/com/sun/xml/internal/ws/server/Tie.java - src/share/classes/com/sun/xml/internal/ws/server/XMLEPTFactoryImpl.java - src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderModel.java - src/share/classes/com/sun/xml/internal/ws/server/provider/ProviderPeptTie.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Binding.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/ClientTransportFactoryTypes.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/InternalSoapEncoder.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Invoker.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/MessageContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/MtomCallback.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/RuntimeEndpointInfo.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SOAPMessageContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/StubBase.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegate.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/SystemHandlerDelegateFactory.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/Tie.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/WSConnection.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/WebServiceContext.java - src/share/classes/com/sun/xml/internal/ws/spi/runtime/package-info.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamReaderFactory.java - src/share/classes/com/sun/xml/internal/ws/streaming/XMLStreamWriterFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/WSConnectionImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/http/client/HttpClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointDocInfo.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/EndpointEntityResolver.java - src/share/classes/com/sun/xml/internal/ws/transport/http/server/WebServiceContextImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/local/LocalMessage.java - src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransport.java - src/share/classes/com/sun/xml/internal/ws/transport/local/client/LocalClientTransportFactory.java - src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalConnectionImpl.java - src/share/classes/com/sun/xml/internal/ws/transport/local/server/LocalWSContextImpl.java - src/share/classes/com/sun/xml/internal/ws/util/Base64Util.java - src/share/classes/com/sun/xml/internal/ws/util/MessageInfoUtil.java - src/share/classes/com/sun/xml/internal/ws/util/NullIterator.java - src/share/classes/com/sun/xml/internal/ws/util/SOAPConnectionUtil.java - src/share/classes/com/sun/xml/internal/ws/util/SOAPUtil.java - src/share/classes/com/sun/xml/internal/ws/util/SunStAXReflection.java - src/share/classes/com/sun/xml/internal/ws/util/XMLConnectionUtil.java - src/share/classes/com/sun/xml/internal/ws/util/xml/XMLStreamReaderToContentHandler.java - src/share/classes/com/sun/xml/internal/ws/wsdl/WSDLContext.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Binding.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/BindingOperation.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Message.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Part.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Port.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortType.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/PortTypeOperation.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/Service.java - src/share/classes/com/sun/xml/internal/ws/wsdl/parser/WSDLDocument.java - src/share/classes/com/sun/xml/internal/ws/wsdl/writer/WSDLOutputResolver.java - src/share/classes/com/sun/xml/internal/xsom/impl/util/ConcatIterator.java - src/share/classes/com/sun/xml/internal/xsom/impl/util/FilterIterator.java Changeset: 1626ba49a98e Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/1626ba49a98e Merge Changeset: af4d62e31af8 Author: ohair Date: 2009-05-15 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/af4d62e31af8 Merge Changeset: 3b054db3e277 Author: ohair Date: 2009-05-19 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/3b054db3e277 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: aeabf802f2a1 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/aeabf802f2a1 Added tag jdk7-b60 for changeset 3b054db3e277 ! .hgtags From john.coomes at sun.com Fri Jun 12 00:32:58 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 07:32:58 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 31 new changesets Message-ID: <20090612073939.762CAE51E@hg.openjdk.java.net> Changeset: 9ad7e6462145 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9ad7e6462145 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/common/Defs-linux.gmk ! make/sun/awt/mawt.gmk Changeset: 5ceb9eb621d1 Author: chegar Date: 2009-05-07 17:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5ceb9eb621d1 6837982: SCTP API docs not being generated. Summary: Update docs makefile to build javadoc for the com.sun.nio.sctp package. Reviewed-by: jccollet, alanb, weijun ! make/docs/Makefile Changeset: 86d2541a9ba2 Author: xdono Date: 2009-05-07 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/86d2541a9ba2 Merge - src/share/native/java/util/zip/ZipEntry.c - src/share/native/sun/java2d/pipe/RenderBuffer.c - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: 39d93fb6926c Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/39d93fb6926c Merge Changeset: 6ca1c622dd6e Author: ohair Date: 2009-05-07 18:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6ca1c622dd6e 6835803: Type error in src/windows/native/sun/windows/awt_Window.cpp Reviewed-by: prr ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 7ec6857812d2 Author: ohair Date: 2009-05-08 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7ec6857812d2 Merge ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 9eeeeee69368 Author: ohair Date: 2009-05-15 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/9eeeeee69368 6841873: Fix windows redist default location for msvc runtime dlls Reviewed-by: tbell ! make/common/shared/Defs-windows.gmk Changeset: 97064d73976f Author: ohair Date: 2009-05-15 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/97064d73976f Merge Changeset: fdbc48164a8b Author: ohair Date: 2009-05-18 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fdbc48164a8b 6842023: Improve test reliability, Increase timeout factor on jtreg tests, etc. Reviewed-by: tbell ! make/jprt.properties ! test/Makefile ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/util/ResourceBundle/RestrictedBundleTest.java ! test/java/util/WeakHashMap/GCDuringIteration.java Changeset: c06d30bd8c69 Author: andrew Date: 2009-05-21 16:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c06d30bd8c69 6841728: Make building the Nimbus L 'n' F optional (100054) Summary: Add DISABLE_NIMBUS variable to prevent Nimbus subdirs being built Reviewed-by: mr, ohair ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile ! make/tools/Makefile Changeset: 238591c80bc5 Author: aph Date: 2009-05-21 18:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/238591c80bc5 6839133: lcms 1.18 update breaks ICC_ProfileRGB Tests Reviewed-by: avu, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: f62f7fcc9965 Author: art Date: 2009-05-15 15:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f62f7fcc9965 6678385: Random java.lang.StackOverflowError from various JDKs Reviewed-by: stayer ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/MotifDnDConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/WindowPropertyGetter.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java + src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTranslateCoordinates.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 019fd945ebc5 Author: yan Date: 2009-05-18 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/019fd945ebc5 6834525: PIT: RowToleranceTransitivityTest test fail with crash on rhel4 x86 and rhel 5x86 Summary: do not try to use released XKB resources Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 875524a2b311 Author: anthony Date: 2009-05-19 12:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/875524a2b311 6811219: Deadlock java AWT in XWarningWindow Summary: The locking scheme has been re-architected, the code slightly refactored. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 5eaa495dc929 Author: anthony Date: 2009-05-19 14:14 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5eaa495dc929 6812298: Dynamic GraphicsConfig changes don't work on X11 platforms Summary: The peer gets recreated if the visual of the new GC differs from the previous one Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: ac08fa3d6c98 Author: anthony Date: 2009-05-19 14:43 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ac08fa3d6c98 6833444: _BOOTDIR1/_BOOTDIR2 on MS Windows should be consistent with other platforms Summary: Added optional _BOOTDIR3 that provides the J: path for the BOOTDIR on Windows Reviewed-by: ohair, xdono ! make/common/Sanity.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 315f315b8d3c Author: anthony Date: 2009-05-19 17:03 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/315f315b8d3c 6839999: Cumulative fix for 6762511 and 6838003 Summary: Adds support for ARGB and ABGR X11 surfaces. Reviewed-by: art, yan ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 ! src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: b33466bb2fed Author: art Date: 2009-05-21 12:29 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b33466bb2fed 6794764: Translucent windows are completely repainted on every paint event, on Windows 6719382: Printing of AWT components on windows is not working 6726866: Repainting artifacts when resizing or dragging JInternalFrames in non-opaque toplevel 6683775: Painting artifacts is seen when panel is made setOpaque(false) for a translucent window Reviewed-by: anthony, tdv, alexp ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WObjectPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + test/javax/swing/JComponent/6683775/bug6683775.java + test/javax/swing/JInternalFrame/6726866/bug6726866.html + test/javax/swing/JInternalFrame/6726866/bug6726866.java Changeset: 97ece6b3d84f Author: ant Date: 2009-05-21 15:04 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/97ece6b3d84f 6833019: KeyboardFocusManager.getCurrentKeyboardFocusManager() throws unspecified HeadlessException Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java Changeset: cfe73335a065 Author: dav Date: 2009-05-22 16:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cfe73335a065 6799099: All automatic regression tests that create Robot fail on X11 Reviewed-by: art, ant ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/xawt/XToolkit.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 52493efeb137 Author: dav Date: 2009-05-25 18:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/52493efeb137 6844750: Solaris build failed after 6799099 Reviewed-by: yan ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 7da360c3baf6 Author: yan Date: 2009-06-01 01:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7da360c3baf6 Merge Changeset: f29cd35647b1 Author: peytoia Date: 2009-05-12 15:21 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f29cd35647b1 6834474: (tz) Support tzdata2009g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 62bfe2674e48 Author: yan Date: 2009-05-14 00:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/62bfe2674e48 Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 455b357442c7 Author: peterz Date: 2009-05-14 18:12 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/455b357442c7 6741426: ClassCastException from ComboBoxEditableState (Nimbus LaF) in JDK 1.6.0_10 RC Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/nimbus/skin.laf + test/javax/swing/plaf/nimbus/Test6741426.java Changeset: af491a9b7c1d Author: peterz Date: 2009-05-15 12:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/af491a9b7c1d 6827581: Contextkey does not work in Nimbus Reviewed-by: rupashka ! src/share/classes/sun/swing/plaf/GTKKeybindings.java ! src/share/classes/sun/swing/plaf/WindowsKeybindings.java Changeset: 993a5f0fe2e0 Author: rupashka Date: 2009-05-15 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/993a5f0fe2e0 6713352: Deadlock in JFileChooser with synchronized custom FileSystemView Reviewed-by: malenkov, peterz ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java + test/javax/swing/JFileChooser/6713352/bug6713352.java Changeset: 019908df0313 Author: rupashka Date: 2009-05-28 18:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/019908df0313 6845805: Test for CR 6713352 is failed under Linux Reviewed-by: malenkov ! test/javax/swing/JFileChooser/6713352/bug6713352.java Changeset: 951ecbad4068 Author: yan Date: 2009-06-01 01:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/951ecbad4068 Merge Changeset: 0c3ef2d612a4 Author: yan Date: 2009-06-09 23:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0c3ef2d612a4 Merge ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt_Window.cpp Changeset: f72c0dc047b9 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f72c0dc047b9 Added tag jdk7-b60 for changeset 0c3ef2d612a4 ! .hgtags From john.coomes at sun.com Fri Jun 12 00:55:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 12 Jun 2009 07:55:28 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 8 new changesets Message-ID: <20090612075541.6BC53E523@hg.openjdk.java.net> Changeset: 4b72c2556789 Author: aph Date: 2009-04-17 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4b72c2556789 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: 321854d9ab19 Author: aph Date: 2009-04-20 19:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/321854d9ab19 6832141: Bug 100045 - Fix for 100028 breaks debug info for class files Summary: Correct fallout from 100028 patch Reviewed-by: ohair Contributed-by: Andrew Haley ! make/Makefile Changeset: f3d27f02683c Author: aph Date: 2009-05-06 18:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f3d27f02683c 6837665: Deal with windows ant problem where commas in -D options do not work Summary: Rewrite to avoid commas in -D options Reviewed-by: ohair ! make/Makefile ! make/build.xml Changeset: 43a781cc6473 Author: xdono Date: 2009-05-07 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/43a781cc6473 Merge Changeset: 846944dd48a4 Author: xdono Date: 2009-05-07 12:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/846944dd48a4 Merge Changeset: 65f2ee956fb9 Author: ohair Date: 2009-05-15 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/65f2ee956fb9 Merge Changeset: 5cdce469ea2a Author: ohair Date: 2009-05-19 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5cdce469ea2a 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad ! README - make/README Changeset: 522520757dd3 Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/522520757dd3 Added tag jdk7-b60 for changeset 5cdce469ea2a ! .hgtags From martinrb at google.com Fri Jun 12 19:51:08 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 12 Jun 2009 19:51:08 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> Message-ID: <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> I've called my own bluff and implemented a test case for this http://cr.openjdk.java.net/~martin/jvmti-oom/ Jeremy's original fix is in this hotspot webrev: http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/ Sun folks (Tim?), please take up the process issues: - please review test and fix - file one (or two?) "real" bugs or implement bugtraq-bugzilla-bridge very soon. It's non-traditional to have fixes cross the hotspot/jdk barrier, but this was the easiest way to write a test case. Martin On Mon, Jun 8, 2009 at 11:41, Martin Buchholz wrote: > The ever-popular test > jdk/test/java/lang/ProcessBuilder/Basic.java > has infrastructure for testing this fix. > It would still be quite annoying to write portably, > involving 3 separate JDKs. > > Martin > > > On Mon, Jun 8, 2009 at 11:31, Jeremy Manson wrote: > >> This one happens to be pretty easy to trigger. I'm not sure how to >> put together a jtreg test, but the following code works: >> >> public class OOM { >> public static void main(String[] args) throws Exception { >> int size = Integer.MAX_VALUE; >> Integer[] props = new Integer[size]; >> } >> } >> >> And then invoke it: >> >> java -XX:OnOutOfMemoryError="echo PASS" OOM >> >> If it prints out "PASS", it works. My understanding is that jtreg >> tests fail by throwing an exception, so this whole thing would >> probably have to be wrapped in another Java program that throws an >> exception if it doesn't see "PASS" in the output. >> >> Jeremy >> >> On Sun, Jun 7, 2009 at 12:31 PM, Tim Bell wrote: >> > Hi Jeremy >> >> >> >> Martin Buchholz tells me that three things have to happen to get a >> patch >> >> in: >> > >> > Hi Martin :-) >> > >> >> 1) Someone inside Sun has to file a bug. Usually, this seems to be in >> >> the other bug database, but I guess it doesn't matter? >> > >> > We hope to get a bridge working between the external bugzilla system >> > (good!) and the internal, proprietary bug tracking system (bad!). >> > Hopefully after we all recover from JavaOne week. >> > >> >> 2) Two OpenJDK members have to review it (in practice). >> > >> > One reviewer is required until the late stages of a release, then >> > two reviewers. Of course, more reviewers are always better. >> > >> >> Is my understanding correct? >> > >> > What are the chances of getting a jtreg test case for this issue? >> > >> > Tests that attempt to exhaust the heap are usually problematical, >> > but it would be worth a try. Nice to have if we can get a test. >> > >> > Tim >> > >> > >> >> Jeremy >> >> >> >> On Fri, Jun 5, 2009 at 4:31 PM, Tim Bell wrote: >> >>> >> >>> Hi Jeremy >> >>>> >> >>>> I was talking to some of the HS team at JavaOne, and they encouraged >> >>>> me to send some of the patches that we are working on at Google back >> >>>> to Sun. (Everyone at Google is covered under a blanket SCA, so we >> can >> >>>> contribute back anything done by any Googler). >> >>>> >> >>>> To get started and test the waters, and because I have never tried to >> >>>> contribute to OpenJDK before, I thought I would send on a >> >>>> nearly-trivial fix that I made last year in response to a user >> >>>> complaint. The issue was that when the user specifies >> >>>> -XX:OnOutOfMemoryError, and the OOM is thrown because a single memory >> >>>> allocation was too close to Integer.MAX_VALUE, the OnOutOfMemoryError >> >>>> command would not be executed. I've attached the patch. Let me know >> >>>> what I should do to proceed. >> >>> >> >>> I created a bugzilla report for this issue: >> >>> >> >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100067 >> >>> >> >>> That way we won't lose it in a pile of email. >> >>> >> >>> Tim >> >>> >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090612/4ff84874/attachment.html From Tim.Bell at Sun.COM Sat Jun 13 10:18:33 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sat, 13 Jun 2009 10:18:33 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> Message-ID: <4A33DF69.3030200@sun.com> Martin Buchholz wrote: > I've called my own bluff and implemented a test case for this > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > Jeremy's original fix is in this hotspot webrev: > http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/ > > Sun folks (Tim?), please take up the process issues: > - please review test and fix > - file one (or two?) "real" bugs or For the HotSpot VM side: > 6850957 hotspot/jvmti JVMTI OOM handling when arrays / objects are too large For the test case: > 6850958 java/classes_lang JVMTI OOM handling when arrays / objects are too large > It's non-traditional to have fixes cross the hotspot/jdk barrier, > but this was the easiest way to write a test case. This happens most often in the Serviceability area, for example when fixes hit JVM TI and JDWP code. You have another good example, where the most natural test case fits in JDK/test/java/lang/ProcessBuilder The parent bugzilla report is: https://bugs.openjdk.java.net/show_bug.cgi?id=100067 I filed two internal bug reports that should be visible on bugs.sun.com in a few working days. Using URL surgery, I predict the URLs will be: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850957 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850958 Later today I will set up a forest, apply the patches from the webrevs, and send it through JPRT. I want to see the HotSpot test results, as well as the new ProcessBuilder/Basic.java Tim From lev.serebryakov at sun.com Sun Jun 14 05:55:43 2009 From: lev.serebryakov at sun.com (lev.serebryakov at sun.com) Date: Sun, 14 Jun 2009 12:55:43 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 29 new changesets Message-ID: <20090614125640.926E8E5EB@hg.openjdk.java.net> Changeset: 93c14e5562c4 Author: twisti Date: 2009-05-06 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/93c14e5562c4 6823354: Add intrinsics for {Integer,Long}.{numberOfLeadingZeros,numberOfTrailingZeros}() Summary: These methods can be instrinsified by using bit scan, bit test, and population count instructions. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/runtime/globals.hpp + test/compiler/6823354/Test6823354.java Changeset: e85af0c0c94b Author: twisti Date: 2009-05-07 00:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e85af0c0c94b Merge Changeset: f53b154d959d Author: twisti Date: 2009-05-06 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f53b154d959d 6837906: compiler tests of 6636138 fail with IllegalAccessException Summary: The compiler tests of 6636138 fail with an IllegalAccessException. Reviewed-by: kvn ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: f2954231d190 Author: twisti Date: 2009-05-07 04:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f2954231d190 Merge Changeset: d0e0d6d824d8 Author: kvn Date: 2009-05-08 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d0e0d6d824d8 Merge ! src/share/vm/runtime/globals.hpp Changeset: c96bf21b756f Author: kvn Date: 2009-05-08 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c96bf21b756f 6788527: Server vm intermittently fails with assertion "live value must not be garbage" with fastdebug bits Summary: Cache Jvmti and DTrace flags used by Compiler. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp Changeset: 44ccd7a9065c Author: ohair Date: 2009-05-08 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/44ccd7a9065c 6839151: Add a JPRT default test of -Xshare:dump when new hotspot is built Reviewed-by: never, kvn ! make/jprt.properties ! test/Makefile Changeset: 900e4df4b0c3 Author: ohair Date: 2009-05-08 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/900e4df4b0c3 Merge Changeset: a9e116455022 Author: kvn Date: 2009-05-11 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a9e116455022 6832293: JIT compiler got wrong result in type checking with -server Summary: Check for an object array of interface in CmpPNode::sub(). Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6832293/Test.java Changeset: b2934faac289 Author: kvn Date: 2009-05-11 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b2934faac289 6836054: java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException Summary: Do not mark an allocation as scalar replaceable if its actual type in unknown statically. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 2056494941db Author: twisti Date: 2009-05-13 00:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2056494941db 6814842: Load shortening optimizations Summary: 6797305 handles load widening but no shortening which should be covered here. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/output_c.cpp + test/compiler/6814842/Test6814842.java Changeset: 5d4dd2f5f6a1 Author: aph Date: 2009-04-17 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5d4dd2f5f6a1 6829575: 100028: Debug information is incomplete or missing Summary: Enable debugging in many places Reviewed-by: ohair Contributed-by: Andrew Haley ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 7a485bc4da16 Author: xdono Date: 2009-05-07 10:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7a485bc4da16 Merge Changeset: 116b019a3961 Author: ohair Date: 2009-05-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/116b019a3961 6839126: Type error found by newer windows compiler Reviewed-by: never, kvn ! src/share/vm/adlc/filebuff.hpp Changeset: 27d660246893 Author: ohair Date: 2009-05-15 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/27d660246893 Merge ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: aabd393cf1ee Author: kvn Date: 2009-05-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/aabd393cf1ee 6772683: Thread.isInterrupted() fails to return true on multiprocessor PC Summary: Set the control edge for the field _interrupted load in inline_native_isInterrupted(). Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/6772683/InterruptedTest.java Changeset: 1851e1fb420e Author: kvn Date: 2009-05-27 12:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1851e1fb420e 6843752: missing code for an anti-dependent Phi in GCM Summary: Don't place a load below anti-dependent PHI. Reviewed-by: never, twisti ! src/share/vm/opto/gcm.cpp + test/compiler/6843752/Test.java Changeset: 273b2358ef1a Author: cfang Date: 2009-05-28 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/273b2358ef1a 6837146: Should perform unswitch before maximally unroll in loop transformation Summary: Move loop unswitch before maximally unroll Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 435f0808b826 Author: never Date: 2009-06-03 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/435f0808b826 6847305: solaris reorder mapfiles generate too many warnings Reviewed-by: kvn ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_COMPILER2_amd64 ! make/solaris/makefiles/reorder_COMPILER2_sparcv9 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc Changeset: 8b0b8998e1c3 Author: never Date: 2009-06-03 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8b0b8998e1c3 Merge Changeset: 085dd9ee61aa Author: never Date: 2009-06-03 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/085dd9ee61aa Merge Changeset: eacd97c88873 Author: cfang Date: 2009-06-05 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/eacd97c88873 6848466: frame::frame_size() assertion failure with -XX:+DebugDeoptimization Summary: add a RegisterMap* argument to frame::frame_size() to correctly compute the sender frame Reviewed-by: never ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe.cpp Changeset: 315a5d70b295 Author: iveresov Date: 2009-05-11 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/315a5d70b295 6484957: G1: parallel concurrent refinement 6826318: G1: remove traversal-based refinement code Summary: Removed traversal-based refinement code as it's no longer used. Made the concurrent refinement (queue-based) parallel. Reviewed-by: tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 215f81b4d9b3 Author: iveresov Date: 2009-05-18 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/215f81b4d9b3 6841831: G1: assert(contains_reference(from),"We just added it!") fires Summary: During parallel rset updating we have to make sure that the worker ids of the refinement threads do not intersect with the worker ids that can be claimed by the mutator threads. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 29e7d79232b9 Author: apetrusenko Date: 2009-05-19 04:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/29e7d79232b9 6819065: G1: eliminate high serial card table clearing time Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 7fd05714f579 Author: jcoomes Date: 2009-05-26 16:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7fd05714f579 Merge Changeset: fe1574da39fc Author: ysr Date: 2009-06-07 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fe1574da39fc 6848641: CMSCollector::_roots_scanning_options should be initialized Summary: The field is now initialized in the constructor. Reviewed-by: iveresov, jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: f89cf529c3c7 Author: iveresov Date: 2009-06-08 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f89cf529c3c7 6849122: G1: Typo introduced during implementation of the parallel refinement Summary: Typo fix Reviewed-by: jcoomes ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 7295839252de Author: jmasa Date: 2009-06-10 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7295839252de Merge From martinrb at google.com Sun Jun 14 12:37:29 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 14 Jun 2009 12:37:29 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A33DF69.3030200@sun.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> Message-ID: <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> I've polished the changes in preparation for committing. I'll commit once I have reviewer approval. You'll need to let me know which forest to commit to. Test webrev is now at: http://cr.openjdk.java.net/~martin/jvmti-oom-test/ Now has more tests and filled-in @bug line. Hotspot fix webrev is at: http://cr.openjdk.java.net/~martin/jvmti-oom/ I've hacked on my private copy of webrev to make the output more suitable for external contributors. I think it's time to again beg the hotspot integrators to be sure to run the java/lang and java/util/concurrent tests from the jdk repo before committing changes to MASTER. Martin On Sat, Jun 13, 2009 at 10:18, Tim Bell wrote: > Martin Buchholz wrote: > >> I've called my own bluff and implemented a test case for this >> http://cr.openjdk.java.net/~martin/jvmti-oom/ >> >> Jeremy's original fix is in this hotspot webrev: >> http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/ >> >> Sun folks (Tim?), please take up the process issues: >> - please review test and fix >> - file one (or two?) "real" bugs or >> > > For the HotSpot VM side: > >> 6850957 hotspot/jvmti JVMTI OOM handling when arrays / objects are too >> large >> > > For the test case: > >> 6850958 java/classes_lang JVMTI OOM handling when arrays / objects are too >> large >> > > > > It's non-traditional to have fixes cross the hotspot/jdk barrier, >> but this was the easiest way to write a test case. >> > > This happens most often in the Serviceability area, for example when fixes > hit JVM TI and JDWP code. You have another good example, where > the most natural test case fits in JDK/test/java/lang/ProcessBuilder > > The parent bugzilla report is: > > https://bugs.openjdk.java.net/show_bug.cgi?id=100067 > > I filed two internal bug reports that should be visible on bugs.sun.com > in a few working days. Using URL surgery, I predict the URLs will be: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850957 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850958 > > Later today I will set up a forest, apply the patches from the > webrevs, and send it through JPRT. I want to see the HotSpot > test results, as well as the new ProcessBuilder/Basic.java > > Tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090614/44b117b7/attachment.html From David.Holmes at Sun.COM Sun Jun 14 15:25:53 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 15 Jun 2009 08:25:53 +1000 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> Message-ID: <4A3578F1.6070401@sun.com> Martin, Jeremy, This change has been bugging me. I guess what I don't like is not the "fix" but the fact that we report OutOfMemoryError for this situation in the first place! We are not out-of-memory! We've been asked to allocate something that is impossible to allocate given the physical constraints of the memory system. The heap could actually be nearly empty! If I were executing a OOM handler using the "onError" mechanism I'm not sure I'd want it to run for this case. This fix makes this usage consistent with all the other OOM situations, but we post JVMTI resource exhausted events when the resource need not be exhausted at all! I'm not sure that is the right thing to do. Even assuming it is the right thing to do, this may impact some tests as it now generates additional JVMTI events. David Holmes Martin Buchholz said the following on 06/15/09 05:37: > I've polished the changes in preparation for committing. > I'll commit once I have reviewer approval. > You'll need to let me know which forest to commit to. > > Test webrev is now at: > http://cr.openjdk.java.net/~martin/jvmti-oom-test/ > > Now has more tests and filled-in @bug line. > > Hotspot fix webrev is at: > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > I've hacked on my private copy of webrev to make the output more > suitable for > external contributors. > > I think it's time to again beg the hotspot integrators > to be sure to run the java/lang and java/util/concurrent tests > from the jdk repo before committing changes to MASTER. > > Martin > > On Sat, Jun 13, 2009 at 10:18, Tim Bell > wrote: > > Martin Buchholz wrote: > > I've called my own bluff and implemented a test case for this > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > > Jeremy's original fix is in this hotspot webrev: > http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/ > > > Sun folks (Tim?), please take up the process issues: > - please review test and fix > - file one (or two?) "real" bugs or > > > For the HotSpot VM side: > > 6850957 hotspot/jvmti JVMTI OOM handling when arrays / objects > are too large > > > For the test case: > > 6850958 java/classes_lang JVMTI OOM handling when arrays / > objects are too large > > > > > It's non-traditional to have fixes cross the hotspot/jdk barrier, > but this was the easiest way to write a test case. > > > This happens most often in the Serviceability area, for example when > fixes hit JVM TI and JDWP code. You have another good example, where > the most natural test case fits in JDK/test/java/lang/ProcessBuilder > > The parent bugzilla report is: > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100067 > > I filed two internal bug reports that should be visible on > bugs.sun.com > in a few working days. Using URL surgery, I predict the URLs will be: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850957 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850958 > > Later today I will set up a forest, apply the patches from the > webrevs, and send it through JPRT. I want to see the HotSpot > test results, as well as the new ProcessBuilder/Basic.java > > Tim > > From martinrb at google.com Sun Jun 14 15:43:07 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 14 Jun 2009 15:43:07 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A3578F1.6070401@sun.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> Message-ID: <1ccfd1c10906141543r334afdebqf6ba5000d7a19304@mail.gmail.com> I'm far from an expert on jvmti or hotspot's error handling, but... If I've asked for a command to be run on OOME, having it not run feels very much like a bug. I agree that OOME might not perfectly match the situation, but is there a better course of action? I don't see any reasonable alternative to throwing OOME. Martin On Sun, Jun 14, 2009 at 15:25, David Holmes - Sun Microsystems < David.Holmes at sun.com> wrote: > Martin, Jeremy, > > This change has been bugging me. I guess what I don't like is not the "fix" > but the fact that we report OutOfMemoryError for this situation in the first > place! We are not out-of-memory! We've been asked to allocate something that > is impossible to allocate given the physical constraints of the memory > system. The heap could actually be nearly empty! If I were executing a OOM > handler using the "onError" mechanism I'm not sure I'd want it to run for > this case. > > This fix makes this usage consistent with all the other OOM situations, but > we post JVMTI resource exhausted events when the resource need not be > exhausted at all! I'm not sure that is the right thing to do. Even assuming > it is the right thing to do, this may impact some tests as it now generates > additional JVMTI events. > > David Holmes > > Martin Buchholz said the following on 06/15/09 05:37: > >> I've polished the changes in preparation for committing. >> I'll commit once I have reviewer approval. >> You'll need to let me know which forest to commit to. >> >> Test webrev is now at: >> http://cr.openjdk.java.net/~martin/jvmti-oom-test/ >> >> Now has more tests and filled-in @bug line. >> >> Hotspot fix webrev is at: >> http://cr.openjdk.java.net/~martin/jvmti-oom/ >> >> I've hacked on my private copy of webrev to make the output more suitable >> for >> external contributors. >> >> I think it's time to again beg the hotspot integrators >> to be sure to run the java/lang and java/util/concurrent tests >> from the jdk repo before committing changes to MASTER. >> >> Martin >> >> On Sat, Jun 13, 2009 at 10:18, Tim Bell > Tim.Bell at sun.com>> wrote: >> >> Martin Buchholz wrote: >> >> I've called my own bluff and implemented a test case for this >> http://cr.openjdk.java.net/~martin/jvmti-oom/ >> >> >> Jeremy's original fix is in this hotspot webrev: >> http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/ >> >> >> Sun folks (Tim?), please take up the process issues: >> - please review test and fix >> - file one (or two?) "real" bugs or >> >> >> For the HotSpot VM side: >> >> 6850957 hotspot/jvmti JVMTI OOM handling when arrays / objects >> are too large >> >> >> For the test case: >> >> 6850958 java/classes_lang JVMTI OOM handling when arrays / >> objects are too large >> >> >> >> >> It's non-traditional to have fixes cross the hotspot/jdk barrier, >> but this was the easiest way to write a test case. >> >> >> This happens most often in the Serviceability area, for example when >> fixes hit JVM TI and JDWP code. You have another good example, where >> the most natural test case fits in JDK/test/java/lang/ProcessBuilder >> >> The parent bugzilla report is: >> >> >> https://bugs.openjdk.java.net/show_bug.cgi?id=100067 >> >> I filed two internal bug reports that should be visible on >> bugs.sun.com >> in a few working days. Using URL surgery, I predict the URLs will be: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850957 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850958 >> >> Later today I will set up a forest, apply the patches from the >> webrevs, and send it through JPRT. I want to see the HotSpot >> test results, as well as the new ProcessBuilder/Basic.java >> >> Tim >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090614/8eb4afb5/attachment.html From David.Holmes at Sun.COM Sun Jun 14 16:22:55 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 15 Jun 2009 09:22:55 +1000 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906141543r334afdebqf6ba5000d7a19304@mail.gmail.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <1ccfd1c10906141543r334afdebqf6ba5000d7a19304@mail.gmail.com> Message-ID: <4A35864F.5030109@sun.com> Martin, I agree regarding the bug - this fix provides a consistent approach to all situations where an OOME is thrown. (You can consider this an additional review.) My meta-question is whether OOME should have been thrown for this case: it somehow seems wrong to me - I would not handle this error in the same way I would handle a true OOM, because this is obviously a simple programming error - but other than throwing an unspecified RuntimeException I don't see a better alternative. And it's a little late to change this now. My caution with the fix is that it will now post JVMTI events in circumstances where they were not previously posted. I doubt any real code will be affected by this, but it is possible that there is a test somewhere that may get upset by it. You know how sensitive some of our tests can be. ;) Cheers, David Martin Buchholz said the following on 06/15/09 08:43: > I'm far from an expert on jvmti or hotspot's error handling, but... > > If I've asked for a command to be run on OOME, > having it not run feels very much like a bug. > I agree that OOME might not perfectly match the situation, > but is there a better course of action? > I don't see any reasonable alternative to throwing OOME. > > Martin > > On Sun, Jun 14, 2009 at 15:25, David Holmes - Sun Microsystems > > wrote: > > Martin, Jeremy, > > This change has been bugging me. I guess what I don't like is not > the "fix" but the fact that we report OutOfMemoryError for this > situation in the first place! We are not out-of-memory! We've been > asked to allocate something that is impossible to allocate given the > physical constraints of the memory system. The heap could actually > be nearly empty! If I were executing a OOM handler using the > "onError" mechanism I'm not sure I'd want it to run for this case. > > This fix makes this usage consistent with all the other OOM > situations, but we post JVMTI resource exhausted events when the > resource need not be exhausted at all! I'm not sure that is the > right thing to do. Even assuming it is the right thing to do, this > may impact some tests as it now generates additional JVMTI events. > > David Holmes > > Martin Buchholz said the following on 06/15/09 05:37: > > I've polished the changes in preparation for committing. > I'll commit once I have reviewer approval. > You'll need to let me know which forest to commit to. > > Test webrev is now at: > http://cr.openjdk.java.net/~martin/jvmti-oom-test/ > > > Now has more tests and filled-in @bug line. > > Hotspot fix webrev is at: > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > > I've hacked on my private copy of webrev to make the output more > suitable for > external contributors. > > I think it's time to again beg the hotspot integrators > to be sure to run the java/lang and java/util/concurrent tests > from the jdk repo before committing changes to MASTER. > > Martin > > On Sat, Jun 13, 2009 at 10:18, Tim Bell >> wrote: > > Martin Buchholz wrote: > > I've called my own bluff and implemented a test case for this > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > > > > Jeremy's original fix is in this hotspot webrev: > http://cr.openjdk.java.net/~martin/jvmti-oom-hotspot/ > > > > > Sun folks (Tim?), please take up the process issues: > - please review test and fix > - file one (or two?) "real" bugs or > > > For the HotSpot VM side: > > 6850957 hotspot/jvmti JVMTI OOM handling when arrays / > objects > are too large > > > For the test case: > > 6850958 java/classes_lang JVMTI OOM handling when arrays / > objects are too large > > > > > It's non-traditional to have fixes cross the hotspot/jdk > barrier, > but this was the easiest way to write a test case. > > > This happens most often in the Serviceability area, for > example when > fixes hit JVM TI and JDWP code. You have another good > example, where > the most natural test case fits in > JDK/test/java/lang/ProcessBuilder > > The parent bugzilla report is: > > > https://bugs.openjdk.java.net/show_bug.cgi?id=100067 > > I filed two internal bug reports that should be visible on > bugs.sun.com > > in a few working days. Using URL surgery, I predict the URLs > will be: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850957 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850958 > > Later today I will set up a forest, apply the patches from the > webrevs, and send it through JPRT. I want to see the HotSpot > test results, as well as the new ProcessBuilder/Basic.java > > Tim > > > From Tomas.Hurka at Sun.COM Mon Jun 15 00:20:51 2009 From: Tomas.Hurka at Sun.COM (Tomas Hurka) Date: Mon, 15 Jun 2009 09:20:51 +0200 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> Message-ID: Hi Martin and David, On 14 Jun 2009, at 21:37, Martin Buchholz wrote: > I've polished the changes in preparation for committing. > I'll commit once I have reviewer approval. I have the same concern as David. I think that throwing OOME, in places where there is obviously a simple programming error, is not a good idea. Will it be possible to change it to throw IllegalArgumentException instead? I have one more comment about the patch itself - changes to src/share/ vm/gc_interface/collectedHeap.inline.hpp and src/share/vm/utilities/ exceptions.hpp are unrelated to the bugfix. I think it will be better to separate them to the different changeset. Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.dev.java.net Software Engineer, Developer Platforms Group Sun Microsystems, Praha Czech Republic From Tomas.Hurka at Sun.COM Mon Jun 15 01:53:16 2009 From: Tomas.Hurka at Sun.COM (Tomas Hurka) Date: Mon, 15 Jun 2009 10:53:16 +0200 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> Message-ID: <08515E44-8300-474B-BC96-640B4617FF28@Sun.COM> Hi Jeremy, On 15 Jun 2009, at 09:39, Jeremy Manson wrote: > Why is this a programming error? I thought it was just a VM > limitation. Well, maybe the error is probably not the right word. The point is that this is not OOME. You are right that it is VM limitation. > Surely the JVMS allows arrays of any nonnegative integral size, no? Sure, it does. Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.dev.java.net Software Engineer, Developer Platforms Group Sun Microsystems, Praha Czech Republic From Tomas.Hurka at Sun.COM Mon Jun 15 01:56:37 2009 From: Tomas.Hurka at Sun.COM (Tomas Hurka) Date: Mon, 15 Jun 2009 10:56:37 +0200 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> Message-ID: <0480F4FE-14F1-49D9-BBBA-71EA28D6041D@Sun.COM> Hi Jeremy, On 15 Jun 2009, at 09:53, Jeremy Manson wrote: > FWIW, I also think that having a call to new throw anything that isn't > an OOME is opening up a much larger compatibility can of worms than > anything else I intended with this patch. I understand. Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.dev.java.net Software Engineer, Developer Platforms Group Sun Microsystems, Praha Czech Republic From Alan.Bateman at Sun.COM Mon Jun 15 02:37:07 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 15 Jun 2009 10:37:07 +0100 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A3578F1.6070401@sun.com> References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> Message-ID: <4A361643.8040701@sun.com> David Holmes - Sun Microsystems wrote: > Martin, Jeremy, > > This change has been bugging me. I guess what I don't like is not the > "fix" but the fact that we report OutOfMemoryError for this situation > in the first place! We are not out-of-memory! We've been asked to > allocate something that is impossible to allocate given the physical > constraints of the memory system. The heap could actually be nearly > empty! If I were executing a OOM handler using the "onError" mechanism > I'm not sure I'd want it to run for this case. > > This fix makes this usage consistent with all the other OOM > situations, but we post JVMTI resource exhausted events when the > resource need not be exhausted at all! I'm not sure that is the right > thing to do. Even assuming it is the right thing to do, this may > impact some tests as it now generates additional JVMTI events. > > David Holmes I'm glad you brought this up. I added the heap dump and also this (undocumented) OnOutOfMemoryError option some time ago. My memory on this is hazy but I think we decided to deliberately not to generate a heap dump or run the data collection actions for this case because it's not really resource related. The JVM TI event came later. I agree it is bit inconsistent but the exception message for this case ("Requested array size exceeds VM limit") does help to identity the problem. The exception message and stack trace is lot more useful than a heap dump for this case. -Alan. From jeremymanson at google.com Mon Jun 15 00:39:57 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 15 Jun 2009 00:39:57 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A29AAB4.5070902@sun.com> <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> Message-ID: Hi Tomas (and David, presumably), Why is this a programming error? I thought it was just a VM limitation. Surely the JVMS allows arrays of any nonnegative integral size, no? Jeremy On Mon, Jun 15, 2009 at 12:20 AM, Tomas Hurka wrote: > Hi Martin and David, > > On 14 Jun 2009, at 21:37, Martin Buchholz wrote: > >> I've polished the changes in preparation for committing. >> I'll commit once I have reviewer approval. > > I have the same concern as David. I think that throwing OOME, in places > where there is obviously a simple programming error, is not a good idea. > Will it be possible to change it to throw IllegalArgumentException instead? > I have one more comment about the patch itself - changes to > src/share/vm/gc_interface/collectedHeap.inline.hpp and > src/share/vm/utilities/exceptions.hpp are unrelated to the bugfix. I think > it will be better to separate them to the different changeset. > > Bye, > -- > Tomas Hurka ? > NetBeans Profiler http://profiler.netbeans.org > VisualVM http://visualvm.dev.java.net > Software Engineer, Developer Platforms Group > Sun Microsystems, Praha Czech Republic > > From jeremymanson at google.com Mon Jun 15 00:53:49 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 15 Jun 2009 00:53:49 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> Message-ID: FWIW, I also think that having a call to new throw anything that isn't an OOME is opening up a much larger compatibility can of worms than anything else I intended with this patch. Jeremy On Mon, Jun 15, 2009 at 12:39 AM, Jeremy Manson wrote: > Hi Tomas (and David, presumably), > > Why is this a programming error? ?I thought it was just a VM > limitation. ?Surely the JVMS allows arrays of any nonnegative integral > size, no? > > Jeremy > > On Mon, Jun 15, 2009 at 12:20 AM, Tomas Hurka wrote: >> Hi Martin and David, >> >> On 14 Jun 2009, at 21:37, Martin Buchholz wrote: >> >>> I've polished the changes in preparation for committing. >>> I'll commit once I have reviewer approval. >> >> I have the same concern as David. I think that throwing OOME, in places >> where there is obviously a simple programming error, is not a good idea. >> Will it be possible to change it to throw IllegalArgumentException instead? >> I have one more comment about the patch itself - changes to >> src/share/vm/gc_interface/collectedHeap.inline.hpp and >> src/share/vm/utilities/exceptions.hpp are unrelated to the bugfix. I think >> it will be better to separate them to the different changeset. >> >> Bye, >> -- >> Tomas Hurka ? >> NetBeans Profiler http://profiler.netbeans.org >> VisualVM http://visualvm.dev.java.net >> Software Engineer, Developer Platforms Group >> Sun Microsystems, Praha Czech Republic >> >> > From jeremymanson at google.com Mon Jun 15 10:06:36 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 15 Jun 2009 10:06:36 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A361643.8040701@sun.com> References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> Message-ID: I'm not sure if the heap dump is as interesting as the fact that you are going to take some action when you do OnOutOfMemoryError. It is rather surprising to have specified that a particular action is taken when a OOME occurs, and have it not happen when an OOME occurs. I guess that because it is a limitation in the VM, you could throw VirtualMachineError instead. Jeremy On Mon, Jun 15, 2009 at 2:37 AM, Alan Bateman wrote: > David Holmes - Sun Microsystems wrote: >> >> Martin, Jeremy, >> >> This change has been bugging me. I guess what I don't like is not the >> "fix" but the fact that we report OutOfMemoryError for this situation in the >> first place! We are not out-of-memory! We've been asked to allocate >> something that is impossible to allocate given the physical constraints of >> the memory system. The heap could actually be nearly empty! If I were >> executing a OOM handler using the "onError" mechanism I'm not sure I'd want >> it to run for this case. >> >> This fix makes this usage consistent with all the other OOM situations, >> but we post JVMTI resource exhausted events when the resource need not be >> exhausted at all! I'm not sure that is the right thing to do. Even assuming >> it is the right thing to do, this may impact some tests as it now generates >> additional JVMTI events. >> >> David Holmes > > I'm glad you brought this up. I added the heap dump and also this > (undocumented) OnOutOfMemoryError option some time ago. My memory on this is > hazy but I think we decided to deliberately not to generate a heap dump or > run the data collection actions for this case because it's not really > resource related. The JVM TI event came later. I agree it is bit > inconsistent but the exception message for this case ("Requested array size > exceeds VM limit") does help to identity the problem. ?The exception message > and stack trace is lot more useful than a heap dump for this case. > > -Alan. > From martinrb at google.com Tue Jun 16 13:57:05 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 16 Jun 2009 13:57:05 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A361643.8040701@sun.com> References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> Message-ID: <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> The resolution of this is still uncertain. We have one approval I think, but all of the maintainers have expressed reluctance at making this change. I continue to agree with Jeremy and be in favor of making this change, but it's no big deal either way. Perhaps Alan's opinion is authoritative, since he was the author. Alan, perhaps you should give us an actual VETO, and we will shut up. Martin On Mon, Jun 15, 2009 at 02:37, Alan Bateman wrote: > David Holmes - Sun Microsystems wrote: > >> Martin, Jeremy, >> >> This change has been bugging me. I guess what I don't like is not the >> "fix" but the fact that we report OutOfMemoryError for this situation in the >> first place! We are not out-of-memory! We've been asked to allocate >> something that is impossible to allocate given the physical constraints of >> the memory system. The heap could actually be nearly empty! If I were >> executing a OOM handler using the "onError" mechanism I'm not sure I'd want >> it to run for this case. >> >> This fix makes this usage consistent with all the other OOM situations, >> but we post JVMTI resource exhausted events when the resource need not be >> exhausted at all! I'm not sure that is the right thing to do. Even assuming >> it is the right thing to do, this may impact some tests as it now generates >> additional JVMTI events. >> >> David Holmes >> > I'm glad you brought this up. I added the heap dump and also this > (undocumented) OnOutOfMemoryError option some time ago. My memory on this is > hazy but I think we decided to deliberately not to generate a heap dump or > run the data collection actions for this case because it's not really > resource related. The JVM TI event came later. I agree it is bit > inconsistent but the exception message for this case ("Requested array size > exceeds VM limit") does help to identity the problem. The exception message > and stack trace is lot more useful than a heap dump for this case. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090616/bf47c009/attachment.html From jeremymanson at google.com Tue Jun 16 22:16:44 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 16 Jun 2009 22:16:44 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> Message-ID: Not that I actually have a vote, but if Alan feels it is not worth making, I would go back to arguing for something like a VirtualMachineError to be thrown, because the behavior is out of spec. The current behavior - a sort-of-but-not-really OOME - is a little odd. Jeremy On Tue, Jun 16, 2009 at 1:57 PM, Martin Buchholz wrote: > The resolution of this is still uncertain. > We have one approval I think, > but all of the maintainers have expressed reluctance at making this change. > I continue to agree with Jeremy and be in favor of making this change, > but it's no big deal either way. > Perhaps Alan's opinion is authoritative, since he was the author. > Alan, perhaps you should give us an actual VETO, and we will shut up. > > Martin > > On Mon, Jun 15, 2009 at 02:37, Alan Bateman wrote: >> >> David Holmes - Sun Microsystems wrote: >>> >>> Martin, Jeremy, >>> >>> This change has been bugging me. I guess what I don't like is not the >>> "fix" but the fact that we report OutOfMemoryError for this situation in the >>> first place! We are not out-of-memory! We've been asked to allocate >>> something that is impossible to allocate given the physical constraints of >>> the memory system. The heap could actually be nearly empty! If I were >>> executing a OOM handler using the "onError" mechanism I'm not sure I'd want >>> it to run for this case. >>> >>> This fix makes this usage consistent with all the other OOM situations, >>> but we post JVMTI resource exhausted events when the resource need not be >>> exhausted at all! I'm not sure that is the right thing to do. Even assuming >>> it is the right thing to do, this may impact some tests as it now generates >>> additional JVMTI events. >>> >>> David Holmes >> >> I'm glad you brought this up. I added the heap dump and also this >> (undocumented) OnOutOfMemoryError option some time ago. My memory on this is >> hazy but I think we decided to deliberately not to generate a heap dump or >> run the data collection actions for this case because it's not really >> resource related. The JVM TI event came later. I agree it is bit >> inconsistent but the exception message for this case ("Requested array size >> exceeds VM limit") does help to identity the problem. ?The exception message >> and stack trace is lot more useful than a heap dump for this case. >> >> -Alan. > > From Y.S.Ramakrishna at Sun.COM Wed Jun 17 00:19:43 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Wed, 17 Jun 2009 00:19:43 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> Message-ID: <4A38990F.4050700@sun.com> I am not a language spec expert, so this opinion is offered merely as more grist for the on-going discussion mill... Jeremy Manson wrote: > Not that I actually have a vote, but if Alan feels it is not worth > making, I would go back to arguing for something like a > VirtualMachineError to be thrown, because the behavior is out of spec. > The current behavior - a sort-of-but-not-really OOME - is a little > odd. > I agree with Jeremy and others in that the inconsistency in treatment of OOM is not particularly pleasant. "Something like a VirtualMachineError" would be fine, except in as much as a literal reading of the description of VirtualMachineError from the docs makes it sound somewhat inappropriate for the current purpose:- > Thrown to indicate that the Java Virtual Machine is broken or has run > out of resources necessary for it to continue operating. Can a VirtualMachineError be caught and ignored? (The implied inability to continue operating sounds particularly ominous ;-) In fact, OutOfMemoryError (OOME) seems to me to be entirely appropriate since we have been asked to allocate an object that we happen to be unable to (whether that's because all available memory is exhausted or that we never had that much memory available because of physical or other limitations of the JVM is, I think, somewhat orthogonal, and is detail that is anyway available in the detail string). Anyway, I'd personally vote (even though I do not have a vote in this matter either, coming as i do from the GC team) for accepting the patch submitted, keeping the OOME, and bringing it in line with other OOME in terms of respecting the OnOutOfMemory hook. (I agree with Alan and others that dumping the heap is irrelevant and might be avoided, but if that's what it takes for consistency, I am guessing that's fine too.) PS: Note that this does not constitute a review of the code, but rather a voice in favour of the approach taken in the submitted patch. my $0.02. -- ramki > Jeremy > > On Tue, Jun 16, 2009 at 1:57 PM, Martin Buchholz wrote: > >> The resolution of this is still uncertain. >> We have one approval I think, >> but all of the maintainers have expressed reluctance at making this change. >> I continue to agree with Jeremy and be in favor of making this change, >> but it's no big deal either way. >> Perhaps Alan's opinion is authoritative, since he was the author. >> Alan, perhaps you should give us an actual VETO, and we will shut up. >> >> Martin >> >> On Mon, Jun 15, 2009 at 02:37, Alan Bateman wrote: >> >>> David Holmes - Sun Microsystems wrote: >>> >>>> Martin, Jeremy, >>>> >>>> This change has been bugging me. I guess what I don't like is not the >>>> "fix" but the fact that we report OutOfMemoryError for this situation in the >>>> first place! We are not out-of-memory! We've been asked to allocate >>>> something that is impossible to allocate given the physical constraints of >>>> the memory system. The heap could actually be nearly empty! If I were >>>> executing a OOM handler using the "onError" mechanism I'm not sure I'd want >>>> it to run for this case. >>>> >>>> This fix makes this usage consistent with all the other OOM situations, >>>> but we post JVMTI resource exhausted events when the resource need not be >>>> exhausted at all! I'm not sure that is the right thing to do. Even assuming >>>> it is the right thing to do, this may impact some tests as it now generates >>>> additional JVMTI events. >>>> >>>> David Holmes >>>> >>> I'm glad you brought this up. I added the heap dump and also this >>> (undocumented) OnOutOfMemoryError option some time ago. My memory on this is >>> hazy but I think we decided to deliberately not to generate a heap dump or >>> run the data collection actions for this case because it's not really >>> resource related. The JVM TI event came later. I agree it is bit >>> inconsistent but the exception message for this case ("Requested array size >>> exceeds VM limit") does help to identity the problem. The exception message >>> and stack trace is lot more useful than a heap dump for this case. >>> >>> -Alan. >>> >> From Alan.Bateman at Sun.COM Wed Jun 17 03:13:24 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 17 Jun 2009 11:13:24 +0100 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> References: <4A2C1594.9020602@sun.com> <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> Message-ID: <4A38C1C4.3070703@sun.com> Martin Buchholz wrote: > The resolution of this is still uncertain. > We have one approval I think, > but all of the maintainers have expressed reluctance at making this > change. > I continue to agree with Jeremy and be in favor of making this change, > but it's no big deal either way. > Perhaps Alan's opinion is authoritative, since he was the author. > Alan, perhaps you should give us an actual VETO, and we will shut up. > > Martin The JVM TI ResourceExhausted event is intended to be sent to agents when a resource is exhausted. I would suggest we don't change this because this isn't really a resource exhaustion case. The OnOutOfMemoryError option was intended to help with troubleshooting so we're really just talking about extending it to help diagnose attempts to allocate arrays larger than the VM limit. I don't see a problem with that, esp. as the option name hints that the actions are invoked when OOME is about to be thrown. Just on that, I don't think OOME thrown by JNI/library code is handled. Also, looking at it now, it might be useful to provide the data collection commands with the reason message (as %e or %r for example, like the pid is made available as %p). I don't wish to extend the scope of the patch but just mentioning it as something that might help avoid a wild goose chase. I think we mostly agree that the heap dump isn't useful for this case but it would be inconsistent when both XX options are used. Furthermore, when used together the heap dump is generated before the data collection commands are run. For example, you might run a script that automatically compressed the heap dump. So these options are somewhat connected and need to work consistently. Hopefully this helps. I can review the patch but as I'm not working in this area on a daily basis, so it would be best to have a reviewer from the hotspot team (and I assume you'll need someone to push this through JPRT). -Alan. From john.coomes at sun.com Fri Jun 19 01:36:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 08:36:54 +0000 Subject: hg: jdk7/hotspot-rt: Added tag jdk7-b61 for changeset 472c21584cfd Message-ID: <20090619083655.15C4AEABC@hg.openjdk.java.net> Changeset: 68836ec8bcc7 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/68836ec8bcc7 Added tag jdk7-b61 for changeset 472c21584cfd ! .hgtags From john.coomes at sun.com Fri Jun 19 01:42:55 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 08:42:55 +0000 Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b61 for changeset e906b16a12a9 Message-ID: <20090619084256.F0BCBEAC1@hg.openjdk.java.net> Changeset: c73934e09f00 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/c73934e09f00 Added tag jdk7-b61 for changeset e906b16a12a9 ! .hgtags From john.coomes at sun.com Fri Jun 19 01:53:07 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 08:53:07 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b61 for changeset f1ac756616ea Message-ID: <20090619085309.38BBAEAC6@hg.openjdk.java.net> Changeset: db1d07f881a1 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/db1d07f881a1 Added tag jdk7-b61 for changeset f1ac756616ea ! .hgtags From john.coomes at sun.com Fri Jun 19 01:59:11 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 08:59:11 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: Added tag jdk7-b61 for changeset aeabf802f2a1 Message-ID: <20090619085913.87F7AEACB@hg.openjdk.java.net> Changeset: 55681156ec1a Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/55681156ec1a Added tag jdk7-b61 for changeset aeabf802f2a1 ! .hgtags From john.coomes at sun.com Fri Jun 19 02:05:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 09:05:28 +0000 Subject: hg: jdk7/hotspot-rt/jdk: Added tag jdk7-b61 for changeset f72c0dc047b9 Message-ID: <20090619090543.4FA53EAD6@hg.openjdk.java.net> Changeset: 03f2ac812821 Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/03f2ac812821 Added tag jdk7-b61 for changeset f72c0dc047b9 ! .hgtags From john.coomes at sun.com Fri Jun 19 02:20:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Jun 2009 09:20:42 +0000 Subject: hg: jdk7/hotspot-rt/langtools: Added tag jdk7-b61 for changeset 522520757dd3 Message-ID: <20090619092044.B98B6EADB@hg.openjdk.java.net> Changeset: 950d50e13a9e Author: xdono Date: 2009-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/950d50e13a9e Added tag jdk7-b61 for changeset 522520757dd3 ! .hgtags From lev.serebryakov at sun.com Tue Jun 23 06:34:13 2009 From: lev.serebryakov at sun.com (lev.serebryakov at sun.com) Date: Tue, 23 Jun 2009 13:34:13 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 12 new changesets Message-ID: <20090623133440.82615EF0F@hg.openjdk.java.net> Changeset: aa0c48844632 Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/aa0c48844632 Added tag jdk7-b59 for changeset c55be0c7bd32 ! .hgtags Changeset: f5ee65f94d9a Author: ohair Date: 2009-05-15 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f5ee65f94d9a Merge - make/jprt.config ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: a77eddcd510c Author: ohair Date: 2009-05-19 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a77eddcd510c 6843041: Remove duplicate README files in repositories (make/README) Reviewed-by: robilad - make/README Changeset: cf4f487696ba Author: trims Date: 2009-06-11 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/cf4f487696ba Merge Changeset: 08f86fa55a31 Author: trims Date: 2009-06-11 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/08f86fa55a31 6850551: Bump the HS16 build number to 04 Summary: Update the HS16 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 86092459c54d Author: xdono Date: 2009-06-11 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/86092459c54d Added tag jdk7-b60 for changeset a77eddcd510c ! .hgtags Changeset: 27b728fd1281 Author: trims Date: 2009-06-11 21:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/27b728fd1281 Merge Changeset: 821269eca479 Author: ysr Date: 2009-06-11 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/821269eca479 6820167: GCALotAtAllSafepoints + FullGCALot(ScavengeALot) options crash JVM Summary: Short-circuit gc-a-lot attempts by non-JavaThreads; SkipGCALot c'tor to elide re-entrant gc-a-lot attempts. Reviewed-by: apetrusenko, jcoomes, jmasa, kamg ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: d44bdab1c03d Author: johnc Date: 2009-06-11 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d44bdab1c03d 6843694: G1: assert(index < _vs.committed_size(),"bad index"), g1BlockOffsetTable.inline.hpp:55 Summary: For heaps larger than 32Gb, the number of heap regions overflows the data type used to hold the region index in the SparsePRT structure. Changed the region indexes, card indexes, and RSet hash table buckets to ints and added some size overflow guarantees. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 353ba4575581 Author: jcoomes Date: 2009-06-07 22:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/353ba4575581 6814552: par compact - some compilers fail to optimize bitmap code Reviewed-by: tonyp, iveresov, jmasa, ysr ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp Changeset: 6e2afda171db Author: jcoomes Date: 2009-06-11 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6e2afda171db 6849716: BitMap - performance regression introduced with G1 Summary: make verification code visible only in debug builds Reviewed-by: iveresov, ysr, johnc, apetrusenko, tonyp ! src/share/vm/includeDB_compiler1 ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/macros.hpp Changeset: 3104f76478ee Author: jmasa Date: 2009-06-18 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3104f76478ee Merge From jeremymanson at google.com Tue Jun 23 11:36:21 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 23 Jun 2009 11:36:21 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A38C1C4.3070703@sun.com> References: <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> Message-ID: On Wed, Jun 17, 2009 at 3:13 AM, Alan Bateman wrote: > Hopefully this helps. I can review the patch but as I'm not working in this > area on a daily basis, so it would be best to have a reviewer from the > hotspot team (and I assume you'll need someone to push this through JPRT). So, does anyone want to step up and review it? I know several of you have already looked at it. Jeremy From Alan.Bateman at Sun.COM Tue Jun 23 12:45:10 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 23 Jun 2009 20:45:10 +0100 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <1ccfd1c10906081141g3f830ddesdeece4758836a55e@mail.gmail.com> <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> Message-ID: <4A4130C6.5040202@sun.com> Jeremy Manson wrote: > On Wed, Jun 17, 2009 at 3:13 AM, Alan Bateman wrote: > > >> Hopefully this helps. I can review the patch but as I'm not working in this >> area on a daily basis, so it would be best to have a reviewer from the >> hotspot team (and I assume you'll need someone to push this through JPRT). >> > > So, does anyone want to step up and review it? I know several of you > have already looked at it. > > Jeremy > Is there is an updated webrev? In my last year I had hoped we wouldn't send the JVM TI ResourceExhausted event because this isn't really a resource exhaustion case. -Alan. From jeremymanson at google.com Tue Jun 23 14:32:21 2009 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 23 Jun 2009 14:32:21 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A4130C6.5040202@sun.com> References: <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> Message-ID: So, it should have the JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR but not the JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP? I can change that. Jeremy On Tue, Jun 23, 2009 at 12:45 PM, Alan Bateman wrote: > Jeremy Manson wrote: >> >> On Wed, Jun 17, 2009 at 3:13 AM, Alan Bateman wrote: >> >> >>> >>> Hopefully this helps. I can review the patch but as I'm not working in >>> this >>> area on a daily basis, so it would be best to have a reviewer from the >>> hotspot team (and I assume you'll need someone to push this through >>> JPRT). >>> >> >> So, does anyone want to step up and review it? ?I know several of you >> have already looked at it. >> >> Jeremy >> > > Is there is an updated webrev? In my last year I had hoped we wouldn't send > the JVM TI ResourceExhausted event because this isn't really a resource > exhaustion case. > > -Alan. > From David.Holmes at Sun.COM Tue Jun 23 16:47:28 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 24 Jun 2009 09:47:28 +1000 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: References: <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> Message-ID: <4A416990.2050908@sun.com> Jeremy, As I see it there was no consensus reached on whether this change should be made. I have some reservations as previously outlined, but Alan seemed to be of the view that the current situation was deliberately chosen - which implied to me (Alan correct me if I'm wrong) that he opposed the change. It may be that including this case in the OOM onError handling is okay, but that the JVMTI event posting is not. But Alan will need to clarify his position on that. David Jeremy Manson said the following on 06/24/09 07:32: > So, it should have the JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR but not the > JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP? I can change that. > > Jeremy > > > On Tue, Jun 23, 2009 at 12:45 PM, Alan Bateman wrote: >> Jeremy Manson wrote: >>> On Wed, Jun 17, 2009 at 3:13 AM, Alan Bateman wrote: >>> >>> >>>> Hopefully this helps. I can review the patch but as I'm not working in >>>> this >>>> area on a daily basis, so it would be best to have a reviewer from the >>>> hotspot team (and I assume you'll need someone to push this through >>>> JPRT). >>>> >>> So, does anyone want to step up and review it? I know several of you >>> have already looked at it. >>> >>> Jeremy >>> >> Is there is an updated webrev? In my last year I had hoped we wouldn't send >> the JVM TI ResourceExhausted event because this isn't really a resource >> exhaustion case. >> >> -Alan. >> From Alan.Bateman at Sun.COM Wed Jun 24 01:15:46 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 24 Jun 2009 09:15:46 +0100 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A416990.2050908@sun.com> References: <1ccfd1c10906121951x63def19dk81801d23c7f44665@mail.gmail.com> <4A33DF69.3030200@sun.com> <1ccfd1c10906141237t32a9a83er268d586664f773a7@mail.gmail.com> <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> Message-ID: <4A41E0B2.5050401@sun.com> David Holmes - Sun Microsystems wrote: > Jeremy, > > As I see it there was no consensus reached on whether this change > should be made. I have some reservations as previously outlined, but > Alan seemed to be of the view that the current situation was > deliberately chosen - which implied to me (Alan correct me if I'm > wrong) that he opposed the change. > > It may be that including this case in the OOM onError handling is > okay, but that the JVMTI event posting is not. But Alan will need to > clarify his position on that. You got it. My view is that we should not post a JVM TI ResourceExhausted event for this case. I think Jeremy's original motive was to have the OnOutOfMemoryError actions run. I don't see a problem changing the code to do that. Yes, the current behavior is deliberate but this option is for troubleshooting and maybe it can help with the (probably rare) cases where this happens. The other point I attempted to make is that if both OnOutOfMemoryError and HeapDumpOnOutOfMemoryError are enabled then we should always generate the heap dump before the OnOutOfMemoryError run. I think we are in agreement that the heap dump is not interesting here but we should still generate it anyway. -Alan. From john.coomes at sun.com Fri Jun 26 02:37:05 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 09:37:05 +0000 Subject: hg: jdk7/hotspot-rt: 6 new changesets Message-ID: <20090626093705.CF3EBE2AB@hg.openjdk.java.net> Changeset: 54d14906940b Author: jjg Date: 2009-05-20 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/54d14906940b 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Defs-internal.gmk Changeset: 2734c0deab69 Author: tbell Date: 2009-06-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/2734c0deab69 Merge Changeset: e84b527d8be8 Author: tbell Date: 2009-06-21 23:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/e84b527d8be8 Merge Changeset: 60b818e5e4f9 Author: andrew Date: 2009-06-17 20:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/60b818e5e4f9 6851515: awt_p.h incorporates a chunk of the XRender header Summary: Use XRender header directly rather than copying chunks locally Reviewed-by: anthony, ohair ! README-builds.html Changeset: c7ed15ab92ce Author: yan Date: 2009-06-23 23:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/c7ed15ab92ce Merge Changeset: 57f7e028c7ad Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/57f7e028c7ad Added tag jdk7-b62 for changeset c7ed15ab92ce ! .hgtags From john.coomes at sun.com Fri Jun 26 02:41:46 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 09:41:46 +0000 Subject: hg: jdk7/hotspot-rt/corba: 4 new changesets Message-ID: <20090626094150.D9ED1E2D4@hg.openjdk.java.net> Changeset: 2752d8bd4142 Author: jjg Date: 2009-05-20 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/2752d8bd4142 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile Changeset: 23f2c435056b Author: tbell Date: 2009-06-11 21:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/23f2c435056b Merge Changeset: 65b66117dbd7 Author: tbell Date: 2009-06-21 23:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/65b66117dbd7 Merge Changeset: d20e45cd539f Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/d20e45cd539f Added tag jdk7-b62 for changeset 65b66117dbd7 ! .hgtags From john.coomes at sun.com Fri Jun 26 02:50:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 09:50:54 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 4 new changesets Message-ID: <20090626095100.D17DCE2D9@hg.openjdk.java.net> Changeset: bdaf6acaf6e3 Author: jjg Date: 2009-05-20 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/bdaf6acaf6e3 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 97344798aaf7 Author: tbell Date: 2009-06-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/97344798aaf7 Merge ! make/Makefile ! make/build.properties ! make/build.xml Changeset: a97dd57a6260 Author: tbell Date: 2009-06-21 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/a97dd57a6260 Merge Changeset: ae449e9c04c1 Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/ae449e9c04c1 Added tag jdk7-b62 for changeset a97dd57a6260 ! .hgtags From john.coomes at sun.com Fri Jun 26 02:55:56 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 09:55:56 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 4 new changesets Message-ID: <20090626095602.3B1DFE2EE@hg.openjdk.java.net> Changeset: 605e1cdeba48 Author: jjg Date: 2009-05-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/605e1cdeba48 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 2ec98e99e4ea Author: tbell Date: 2009-06-11 21:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/2ec98e99e4ea Merge ! make/Makefile ! make/build.properties ! make/build.xml Changeset: 75c801c13ea1 Author: tbell Date: 2009-06-21 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/75c801c13ea1 Merge Changeset: b8a6e883c0a6 Author: xdono Date: 2009-06-25 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/b8a6e883c0a6 Added tag jdk7-b62 for changeset 75c801c13ea1 ! .hgtags From john.coomes at sun.com Fri Jun 26 03:01:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 10:01:42 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 47 new changesets Message-ID: <20090626101120.86BFAE2FB@hg.openjdk.java.net> Changeset: 842fb12a21d7 Author: sherman Date: 2009-05-19 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/842fb12a21d7 6831794: charset EUC_TW is 12.6% of the total size of charsets.jar 6229811: Several codepoints in EUC_TW failed in roundtrip conversion Summary: Re-write EUC_TW charset to address the size and roundtrip issue. Reviewed-by: alanb ! make/java/nio/Makefile ! make/sun/Makefile ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile ! make/tools/CharsetMapping/Makefile ! make/tools/src/build/tools/charsetmapping/CharsetMapping.java ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java ! make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/sun/io/ByteToCharEUC_TW.java ! src/share/classes/sun/io/CharToByteEUC_TW.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN.java ! src/solaris/classes/sun/awt/motif/X11CNS11643.java ! test/sun/nio/cs/TestISO2022CNDecoder.java Changeset: 72e4312ea1e0 Author: sherman Date: 2009-05-19 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/72e4312ea1e0 6843079: Putback for the new EUC_TW is not complete Summary: Putback the files missed in last putback Reviewed-by: alanb + make/tools/CharsetMapping/euc_tw.map + make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java + make/tools/src/build/tools/charsetmapping/Main.java + test/sun/nio/cs/EUC_TW_OLD.java + test/sun/nio/cs/TestEUC_TW.java + test/sun/nio/cs/TestX11CNS.java + test/sun/nio/cs/X11CNS11643.java + test/sun/nio/cs/X11CNS11643P1.java + test/sun/nio/cs/X11CNS11643P2.java + test/sun/nio/cs/X11CNS11643P3.java Changeset: 49478a651a28 Author: sherman Date: 2009-05-19 16:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/49478a651a28 6728376: Wrong error handling in Java_java_util_zip_Deflater_deflateBytes leads to size 0 if compress fails 6735255: ZipFile.close() does not close ZipFileInputStreams, contrary to the API document Summary: Throws OOM when malloc failed. Closes all outstanding streams when closing Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: 057cc7d16812 Author: sherman Date: 2009-05-19 16:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/057cc7d16812 Merge Changeset: 02b02a886b9b Author: weijun Date: 2009-05-20 10:11 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/02b02a886b9b 6832016: {DigestMD5Base,Des3DkCrypto}.setParityBit should use Integer.bitCount Reviewed-by: weijun Contributed-by: Christian Thalinger ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/sun/security/krb5/internal/crypto/dk/Des3DkCrypto.java Changeset: 4d607dc5cb22 Author: weijun Date: 2009-05-20 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4d607dc5cb22 6682516: SPNEGO_HTTP_AUTH/WWW_KRB and SPNEGO_HTTP_AUTH/WWW_SPNEGO failed on all non-windows platforms Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/PrincipalName.java + test/sun/security/krb5/canonicalize/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/security/krb5/canonicalize/Test.java Changeset: eb46247f6c53 Author: weijun Date: 2009-05-20 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/eb46247f6c53 6832353: Krb5LoginModule: use the KRB5CCNAME when searching for Kerberos ticket cache Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java Changeset: 1bc5be8665cc Author: jjg Date: 2009-05-20 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1bc5be8665cc 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: 914c33c7de3e Author: sherman Date: 2009-05-21 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/914c33c7de3e 6843578: Re-implement IBM doublebyte charsets 6639450: IBM949C encoder modifies state of IBM949 encoder 6569191: Cp943 io converter returns U+0000 and U+FFFD for unconvertable character 6577466: Character encoder IBM970 throws a BufferOverflowException 5065777: CharsetEncoder canEncode() methods often incorrectly return false Summary: Re-write 11 IBM doublebyte charsets. Thanks Ulf.Zibis for the codereview! Reviewed-by: martin ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/DoubleByte-X.java + make/tools/CharsetMapping/IBM1381.c2b + make/tools/CharsetMapping/IBM1381.map + make/tools/CharsetMapping/IBM1383.c2b + make/tools/CharsetMapping/IBM1383.map + make/tools/CharsetMapping/IBM1383.nr + make/tools/CharsetMapping/IBM930.c2b + make/tools/CharsetMapping/IBM930.map + make/tools/CharsetMapping/IBM930.nr + make/tools/CharsetMapping/IBM933.c2b + make/tools/CharsetMapping/IBM933.map + make/tools/CharsetMapping/IBM935.c2b + make/tools/CharsetMapping/IBM935.map + make/tools/CharsetMapping/IBM935.nr + make/tools/CharsetMapping/IBM937.c2b + make/tools/CharsetMapping/IBM937.map + make/tools/CharsetMapping/IBM937.nr + make/tools/CharsetMapping/IBM939.c2b + make/tools/CharsetMapping/IBM939.map + make/tools/CharsetMapping/IBM939.nr + make/tools/CharsetMapping/IBM942.c2b + make/tools/CharsetMapping/IBM942.map + make/tools/CharsetMapping/IBM943.map + make/tools/CharsetMapping/IBM943.nr + make/tools/CharsetMapping/IBM948.c2b + make/tools/CharsetMapping/IBM948.map + make/tools/CharsetMapping/IBM949.map + make/tools/CharsetMapping/IBM950.c2b + make/tools/CharsetMapping/IBM950.map + make/tools/CharsetMapping/IBM970.c2b + make/tools/CharsetMapping/IBM970.map + make/tools/CharsetMapping/dbcs + make/tools/src/build/tools/charsetmapping/GenerateDBCS.java ! make/tools/src/build/tools/charsetmapping/Main.java ! src/share/classes/sun/io/ByteToCharCp1381.java ! src/share/classes/sun/io/ByteToCharCp1383.java ! src/share/classes/sun/io/ByteToCharCp834.java ! src/share/classes/sun/io/ByteToCharCp930.java ! src/share/classes/sun/io/ByteToCharCp933.java ! src/share/classes/sun/io/ByteToCharCp935.java ! src/share/classes/sun/io/ByteToCharCp937.java ! src/share/classes/sun/io/ByteToCharCp939.java ! src/share/classes/sun/io/ByteToCharCp942.java ! src/share/classes/sun/io/ByteToCharCp942C.java ! src/share/classes/sun/io/ByteToCharCp943.java ! src/share/classes/sun/io/ByteToCharCp943C.java ! src/share/classes/sun/io/ByteToCharCp948.java ! src/share/classes/sun/io/ByteToCharCp949.java ! src/share/classes/sun/io/ByteToCharCp949C.java ! src/share/classes/sun/io/ByteToCharCp950.java ! src/share/classes/sun/io/ByteToCharCp970.java ! src/share/classes/sun/io/ByteToCharDBCS_ASCII.java ! src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java + src/share/classes/sun/io/ByteToCharEUC2.java ! src/share/classes/sun/io/CharToByteCp1381.java ! src/share/classes/sun/io/CharToByteCp1383.java ! src/share/classes/sun/io/CharToByteCp834.java ! src/share/classes/sun/io/CharToByteCp930.java ! src/share/classes/sun/io/CharToByteCp933.java ! src/share/classes/sun/io/CharToByteCp935.java ! src/share/classes/sun/io/CharToByteCp937.java ! src/share/classes/sun/io/CharToByteCp939.java ! src/share/classes/sun/io/CharToByteCp942.java ! src/share/classes/sun/io/CharToByteCp942C.java ! src/share/classes/sun/io/CharToByteCp943.java ! src/share/classes/sun/io/CharToByteCp943C.java ! src/share/classes/sun/io/CharToByteCp948.java ! src/share/classes/sun/io/CharToByteCp949.java ! src/share/classes/sun/io/CharToByteCp949C.java ! src/share/classes/sun/io/CharToByteCp950.java ! src/share/classes/sun/io/CharToByteCp970.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java + src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java ! src/share/classes/sun/nio/cs/ext/IBM834.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java ! src/share/classes/sun/nio/cs/ext/IBM942C.java - src/share/classes/sun/nio/cs/ext/IBM943.java ! src/share/classes/sun/nio/cs/ext/IBM943C.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java ! src/share/classes/sun/nio/cs/ext/IBM949C.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! test/sun/nio/cs/FindCanEncodeBugs.java ! test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/OLD/DBCSDecoderMapping.java + test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Decoder.java + test/sun/nio/cs/OLD/DBCS_IBM_ASCII_Encoder.java + test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Decoder.java + test/sun/nio/cs/OLD/DBCS_IBM_EBCDIC_Encoder.java + test/sun/nio/cs/OLD/DBCS_ONLY_IBM_EBCDIC_Decoder.java + test/sun/nio/cs/OLD/IBM1381_OLD.java + test/sun/nio/cs/OLD/IBM1383_OLD.java + test/sun/nio/cs/OLD/IBM930_OLD.java + test/sun/nio/cs/OLD/IBM933_OLD.java + test/sun/nio/cs/OLD/IBM935_OLD.java + test/sun/nio/cs/OLD/IBM937_OLD.java + test/sun/nio/cs/OLD/IBM939_OLD.java + test/sun/nio/cs/OLD/IBM942C_OLD.java + test/sun/nio/cs/OLD/IBM942_OLD.java + test/sun/nio/cs/OLD/IBM943C_OLD.java + test/sun/nio/cs/OLD/IBM943_OLD.java + test/sun/nio/cs/OLD/IBM948_OLD.java + test/sun/nio/cs/OLD/IBM949C_OLD.java + test/sun/nio/cs/OLD/IBM949_OLD.java + test/sun/nio/cs/OLD/IBM950_OLD.java + test/sun/nio/cs/OLD/IBM970_OLD.java + test/sun/nio/cs/OLD/SimpleEUCDecoder.java + test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestEUC_TW.java ! test/sun/nio/cs/TestIBMBugs.java Changeset: 8d2efec31d78 Author: xlu Date: 2009-05-24 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8d2efec31d78 6622432: RFE: Performance improvements to java.math.BigDecimal Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/BitSieve.java ! src/share/classes/java/math/MathContext.java ! src/share/classes/java/math/MutableBigInteger.java ! src/share/classes/java/math/SignedMutableBigInteger.java ! test/java/math/BigDecimal/AddTests.java ! test/java/math/BigDecimal/DivideTests.java Changeset: 3994c5c669cb Author: xlu Date: 2009-05-24 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/3994c5c669cb 6806261: BigDecimal.longValueExact() method throws NullPointerException Summary: add various tests to test the change to 6622432 Reviewed-by: darcy + test/java/math/BigDecimal/EqualsTests.java + test/java/math/BigDecimal/LongValueExactTests.java + test/java/math/BigDecimal/MultiplyTests.java + test/java/math/BigDecimal/PrecisionTests.java + test/java/math/BigInteger/CompareToTests.java Changeset: 206d73d299d4 Author: jccollet Date: 2009-05-25 22:27 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/206d73d299d4 6349566: java.net.CookieManager doesn't set default domain Summary: Enforce default domain in CookieManager Reviewed-by: michaelm ! src/share/classes/java/net/CookieManager.java ! test/java/net/CookieHandler/CookieManagerTest.java Changeset: dc3865883a5a Author: weijun Date: 2009-05-26 10:12 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dc3865883a5a 6844887: NPE in TextCallbackHandler Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java + test/com/sun/security/auth/callback/TextCallbackHandler/NPE.java Changeset: d93b7df1e260 Author: xuelei Date: 2009-05-26 16:19 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d93b7df1e260 6822460: support self-issued certificate Summary: checking self-issued certificate during certification path building Reviewed-by: mullan, weijun ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java Changeset: c3c5cc0f2a3e Author: xuelei Date: 2009-05-26 16:43 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/c3c5cc0f2a3e 6720721: CRL check with circular depency support needed Summary: checking AKID of certificates and CRLs Reviewed-by: mullan, weijun ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevel.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLOneLevelRevoked.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java + test/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java + test/java/security/cert/CertPathValidator/indirectCRL/README + test/java/security/cert/CertPathValidator/indirectCRL/generate.sh + test/java/security/cert/CertPathValidator/indirectCRL/openssl.cnf Changeset: 045aeb76b0ff Author: jccollet Date: 2009-05-26 16:03 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/045aeb76b0ff 6726695: HttpURLConnection shoul support 'Expect: 100-contimue' headers for PUT Summary: Added code triggered when 'Expect: 100-continue' header has been added Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/http/HttpClient/B6726695.java Changeset: 25db260cb810 Author: xuelei Date: 2009-05-27 17:48 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/25db260cb810 6845286: Add regression test for name constraints Summary: create regression test cases on name constraints Reviewed-by: weijun + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithRID.java + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithUnexpectedRID.java + test/java/security/cert/CertPathValidator/nameConstraints/NameConstraintsWithoutRID.java + test/java/security/cert/CertPathValidator/nameConstraints/generate.sh + test/java/security/cert/CertPathValidator/nameConstraints/openssl.cnf Changeset: 7772d77bd7c2 Author: mchung Date: 2009-05-26 17:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7772d77bd7c2 6829636: test/java/util/logging/LoggingDeadlock2.java is flaky Summary: remove @ignore Reviewed-by: swamyv ! src/share/classes/java/net/URLConnection.java ! test/Makefile ! test/java/util/logging/LoggingDeadlock2.java Changeset: 2aeaffb6c897 Author: mchung Date: 2009-05-26 17:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2aeaffb6c897 6798842: TEST_BUG: ThreadStackTrace.java fails intermittently with unexpected thread status. Summary: remove @ignore Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/ThreadStackTrace.java + test/java/lang/management/ThreadMXBean/Utils.java Changeset: fba2425da9b1 Author: mchung Date: 2009-05-26 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fba2425da9b1 5080203: TEST_BUG: ThreadStateTest fails intermittently. Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/ThreadStateTest.java Changeset: a7a38e606a7a Author: mchung Date: 2009-05-26 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a7a38e606a7a 6512493: TEST_BUG: unexpected LockInfo failure in LockedSynchronizers.java Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/LockingThread.java ! test/java/lang/management/ThreadMXBean/MonitorDeadlock.java Changeset: fb97068670e6 Author: mchung Date: 2009-05-26 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/fb97068670e6 6535104: TEST_BUG: FindDeadlocks.java fails intermittently. Summary: Retry a few times to check thread status before reporting failure Reviewed-by: swamyv ! test/java/lang/management/ThreadMXBean/SynchronizerDeadlock.java ! test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java Changeset: 742b55c45a70 Author: mchung Date: 2009-05-27 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/742b55c45a70 Merge Changeset: 59bbb9f3f430 Author: kamg Date: 2009-05-27 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/59bbb9f3f430 6838211: jdk docs creation broken for tracing docs Summary: Fix javadoc makefile macro Reviewed-by: ohair, jjg ! make/docs/Makefile Changeset: 8e77f61508cc Author: kamg Date: 2009-05-27 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8e77f61508cc Merge Changeset: 928e0f1043e6 Author: chegar Date: 2009-05-29 15:51 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/928e0f1043e6 6807602: Increase MAX_BUFFER_LEN and MAX_HEAP_BUFFER_LEN on 64-bit Solaris and Linux Reviewed-by: alanb ! src/solaris/native/java/net/net_util_md.h Changeset: aece9096d5cd Author: jjg Date: 2009-05-29 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/aece9096d5cd 6838199: remove support for old javap Reviewed-by: ohair, mcimadamore ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk ! make/launchers/Makefile Changeset: d26c268597ed Author: sherman Date: 2009-05-29 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d26c268597ed 6808625: Incomplete code sample in Deflater javadoc Summary: added compresser.end() into example Reviewed-by: martin ! src/share/classes/java/util/zip/Deflater.java Changeset: 045743e0eb2d Author: xuelei Date: 2009-06-04 11:28 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/045743e0eb2d 6847459: Allow trust anchor self-issued intermediate version 1 and version 2 certificate Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java Changeset: 8f405b65ddac Author: weijun Date: 2009-06-09 14:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8f405b65ddac 6578647: Undefined requesting URL in java.net.Authenticator.getPasswordAuthentication() Reviewed-by: chegar, valeriep ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java + src/share/classes/sun/net/www/protocol/http/HttpCallerInfo.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateCallbackHandler.java ! src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java + src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/GSSUtil.java + src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/ProviderList.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java ! src/share/classes/sun/security/jgss/wrapper/NativeGSSFactory.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/jgss/DefaultGssConfig.java ! test/sun/security/jgss/GssNPE.java + test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor Changeset: 4da7b972b391 Author: mullan Date: 2009-06-10 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/4da7b972b391 6845161: Bottleneck in Configuration.getConfiguration synchronized call Summary: Reduce scope of synchronized block Reviewed-by: weijun ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: ffbcf1d1103c Author: xuelei Date: 2009-06-12 09:00 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/ffbcf1d1103c 6570344: Invalid RSA OID in sun.security.x509.AlgorithmId Summary: change RSA OID to "2.5.8.1.1" Reviewed-by: mullan ! src/share/classes/sun/security/x509/AlgorithmId.java Changeset: 328148f45b31 Author: tbell Date: 2009-06-11 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/328148f45b31 Merge ! make/docs/Makefile - src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java - src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java - src/share/classes/sun/nio/cs/ext/IBM1381.java - src/share/classes/sun/nio/cs/ext/IBM1383.java - src/share/classes/sun/nio/cs/ext/IBM930.java - src/share/classes/sun/nio/cs/ext/IBM933.java - src/share/classes/sun/nio/cs/ext/IBM935.java - src/share/classes/sun/nio/cs/ext/IBM937.java - src/share/classes/sun/nio/cs/ext/IBM939.java - src/share/classes/sun/nio/cs/ext/IBM942.java - src/share/classes/sun/nio/cs/ext/IBM943.java - src/share/classes/sun/nio/cs/ext/IBM948.java - src/share/classes/sun/nio/cs/ext/IBM949.java - src/share/classes/sun/nio/cs/ext/IBM950.java - src/share/classes/sun/nio/cs/ext/IBM970.java - src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java ! test/Makefile Changeset: 74aefd0ab26d Author: martin Date: 2009-06-14 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/74aefd0ab26d 6850720: (process) Use clone(CLONE_VM), not fork, on Linux to avoid swap exhaustion Summary: Use clone(CLONE_VM) on Linux; Reluctantly implement execvpe. Reviewed-by: michaelm ! src/solaris/native/java/lang/UNIXProcess_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/BigFork.java Changeset: d0de3e41426b Author: martin Date: 2009-06-14 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/d0de3e41426b 6511515: poor performance of LogRecord.inferCaller depending on java.lang.Throwable.getStackTraceElement Summary: Allow random access to stack trace elements; retrieve only needed ones Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 5a5b56904855 Author: tbell Date: 2009-06-21 12:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/5a5b56904855 6853336: (process) disable or remove clone-exec feature (6850720) Summary: clone-exec feature (6850720) needs more work on 32-bit Linux Reviewed-by: alanb, michaelm Contributed-by: Martin Buchholz ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 55a584478eac Author: tbell Date: 2009-06-21 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/55a584478eac Merge Changeset: 6f1f159aed75 Author: yan Date: 2009-06-03 17:41 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6f1f159aed75 6839645: Swing application prints message in Control Panel if language is changed Summary: just remove debug printout from production builds; ignore multicharacter-generating keys Reviewed-by: uta ! src/windows/native/sun/windows/awt_Component.cpp Changeset: a3f970a8600b Author: anthony Date: 2009-06-04 15:18 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a3f970a8600b 6832386: Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Summary: Removed unneeded System.exit(0) call. Reviewed-by: art, ohair, anthony Contributed-by: Omair Majid ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java Changeset: 7289003cd1c9 Author: dcherepanov Date: 2009-06-05 17:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7289003cd1c9 6829180: Removing focused component from a window causes a JVM crash for JDK7b50+ on WinXP/Vista Summary: access pData on the toolkit thread Reviewed-by: art, anthony, naoto ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awtmsg.h Changeset: 70654407b626 Author: dcherepanov Date: 2009-06-15 11:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/70654407b626 6847584: closed/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html fails Reviewed-by: anthony + test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java Changeset: 0e441c781cdc Author: yan Date: 2009-06-16 00:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/0e441c781cdc Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 2a526ccd12e8 Author: andrew Date: 2009-06-17 21:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/2a526ccd12e8 6851515: awt_p.h incorporates a chunk of the XRender header Summary: Use XRender header directly rather than copying chunks locally Reviewed-by: anthony, ohair ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: 1bbbd0ef5d04 Author: peytoia Date: 2009-06-13 06:43 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1bbbd0ef5d04 6850113: Bidi class needs to be updated to support Unicode 5.1 Reviewed-by: okutsu ! make/java/text/FILES_java.gmk ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! src/share/classes/java/text/Bidi.java + src/share/classes/sun/text/bidi/BidiBase.java + src/share/classes/sun/text/bidi/BidiLine.java + src/share/classes/sun/text/bidi/BidiRun.java ! src/share/classes/sun/text/normalizer/UCharacter.java - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h ! src/share/native/sun/font/layout/LETypes.h ! test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiConformance.java ! test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/Bug6850113.java Changeset: 45316d7cc9dc Author: yan Date: 2009-06-17 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/45316d7cc9dc Merge - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 12e11fab9a83 Author: yan Date: 2009-06-23 23:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/12e11fab9a83 Merge - src/share/native/sun/font/bidi/cmemory.h - src/share/native/sun/font/bidi/jbidi.c - src/share/native/sun/font/bidi/jbidi.h - src/share/native/sun/font/bidi/ubidi.c - src/share/native/sun/font/bidi/ubidi.h - src/share/native/sun/font/bidi/ubidiimp.h - src/share/native/sun/font/bidi/ubidiln.c - src/share/native/sun/font/bidi/uchardir.c - src/share/native/sun/font/bidi/uchardir.h - src/share/native/sun/font/bidi/utypes.h Changeset: 8905d218cd0d Author: xdono Date: 2009-06-25 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/8905d218cd0d Added tag jdk7-b62 for changeset 12e11fab9a83 ! .hgtags From john.coomes at sun.com Fri Jun 26 03:27:41 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Jun 2009 10:27:41 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 15 new changesets Message-ID: <20090626102807.10DC9E30A@hg.openjdk.java.net> Changeset: b5872f0790e7 Author: jjg Date: 2009-05-19 11:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/b5872f0790e7 6841422: classfile: add Type visitor Reviewed-by: mcimadamore Contributed-by: kevin.t.looney at sun.com ! src/share/classes/com/sun/tools/classfile/Type.java Changeset: f838537fb1ac Author: jjg Date: 2009-05-19 11:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/f838537fb1ac 6841420: classfile: add new methods to ConstantClassInfo Reviewed-by: mcimadamore Contributed-by: kevin.t.looney at sun.com ! src/share/classes/com/sun/tools/classfile/ConstantPool.java Changeset: fc634a593812 Author: jjg Date: 2009-05-19 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/fc634a593812 6841419: classfile: add constant pool iterator Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java Changeset: cd0630109de5 Author: jjg Date: 2009-05-19 11:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/cd0630109de5 6824493: experimental support for additional info for instructions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/javap/BasicWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java + src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java + src/share/classes/com/sun/tools/javap/Messages.java ! src/share/classes/com/sun/tools/javap/Options.java + src/share/classes/com/sun/tools/javap/SourceWriter.java + src/share/classes/com/sun/tools/javap/StackMapWriter.java + src/share/classes/com/sun/tools/javap/TryBlockWriter.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/T6824493.java Changeset: 0c6cd88f72b9 Author: jjg Date: 2009-05-19 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/0c6cd88f72b9 6843013: missing files in fix for 6824493 Reviewed-by: darcy + src/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java + src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java Changeset: 4ce1c1400334 Author: jjg Date: 2009-05-19 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/4ce1c1400334 6832154: refactor Paths to be just a utility class for JavacFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 79eb8795a1de Author: jjg Date: 2009-05-20 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/79eb8795a1de 6827026: Change javac source and target default to 7 Reviewed-by: darcy, ohair ! make/Makefile ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java Changeset: 44eaac2b4501 Author: jjg Date: 2009-05-20 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/44eaac2b4501 6843648: tools/javac/versions/check.sh is broken Reviewed-by: darcy ! test/tools/javac/6341866/Anno.java ! test/tools/javac/6464451/BigFinally.java ! test/tools/javac/6464451/DeepNestedFinally.java ! test/tools/javac/6464451/ManyExitsInTry.java ! test/tools/javac/ClassLit.java ! test/tools/javac/T6557865.java ! test/tools/javac/foreach/T6682380.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/versions/check.sh Changeset: d402db1005ad Author: mcimadamore Date: 2009-05-21 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d402db1005ad 6722234: javac diagnostics need better integration with the type-system Summary: Added RichDiagnosticFormatter which provides better formatting capabilities for javac types/symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6491592/T6491592.out + test/tools/javac/Diagnostics/6722234/T6722234a.java + test/tools/javac/Diagnostics/6722234/T6722234a_1.out + test/tools/javac/Diagnostics/6722234/T6722234a_2.out + test/tools/javac/Diagnostics/6722234/T6722234b.java + test/tools/javac/Diagnostics/6722234/T6722234b_1.out + test/tools/javac/Diagnostics/6722234/T6722234b_2.out + test/tools/javac/Diagnostics/6722234/T6722234c.java + test/tools/javac/Diagnostics/6722234/T6722234c.out + test/tools/javac/Diagnostics/6722234/T6722234d.java + test/tools/javac/Diagnostics/6722234/T6722234d_1.out + test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendArray.out ! test/tools/javac/OverridePosition.java ! test/tools/javac/OverridePosition.out ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4093617/T4093617.out ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5003235/T5003235c.out ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/miranda/T4666866.out ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java Changeset: 84061bd68019 Author: darcy Date: 2009-05-27 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/84061bd68019 6843761: Update langtools tests to remove unncessary -source and -target options Reviewed-by: jjg ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/tools/javac/5005368.java ! test/tools/javac/Ambig3.java ! test/tools/javac/ArrayCast.java ! test/tools/javac/BadCovar.java ! test/tools/javac/ClassLiterals/InitializeOuter.java ! test/tools/javac/ClassLiterals/InitializeTarget.java ! test/tools/javac/ClassToTypeParm.java ! test/tools/javac/Closure1.java ! test/tools/javac/Closure2.java ! test/tools/javac/Closure3.java ! test/tools/javac/Closure4.java ! test/tools/javac/Closure5.java ! test/tools/javac/CompoundBox.java ! test/tools/javac/ConditionalArgTypes_1.java ! test/tools/javac/ConditionalArgTypes_2.java ! test/tools/javac/DefiniteAssignment/DUAssert.java ! test/tools/javac/EarlyAssert.java ! test/tools/javac/Enum1.java ! test/tools/javac/GoodCovar.java ! test/tools/javac/HexFloatLiterals.java ! test/tools/javac/HexThree.java ! test/tools/javac/InterfaceAssert.java ! test/tools/javac/InvalidIntfCast.java ! test/tools/javac/NewGeneric.java ! test/tools/javac/ObjectMethodRefFromInterface.java ! test/tools/javac/PrivateLocalConstructor.java ! test/tools/javac/RawCrash.java ! test/tools/javac/SynthName2.java ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/T5092545.java ! test/tools/javac/T5105890.java ! test/tools/javac/annotations/default/A.java ! test/tools/javac/annotations/neg/AnnComma.java ! test/tools/javac/annotations/neg/ArrayLit.java ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/annotations/neg/Cycle1.java ! test/tools/javac/annotations/neg/Cycle2.java ! test/tools/javac/annotations/neg/Cycle3.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/annotations/neg/Dup.java ! test/tools/javac/annotations/neg/DupTarget.java ! test/tools/javac/annotations/neg/MemberOver.java ! test/tools/javac/annotations/neg/ObjectMembers.java ! test/tools/javac/annotations/neg/OverrideNo.java ! test/tools/javac/annotations/neg/Package.java ! test/tools/javac/annotations/neg/Recovery.java ! test/tools/javac/annotations/neg/Recovery1.java ! test/tools/javac/annotations/neg/Scope.java ! test/tools/javac/annotations/neg/Syntax1.java ! test/tools/javac/annotations/neg/WrongTarget.java ! test/tools/javac/annotations/neg/WrongTarget2.java ! test/tools/javac/annotations/neg/WrongValue.java ! test/tools/javac/annotations/neg/Z1.java ! test/tools/javac/annotations/neg/Z10.java ! test/tools/javac/annotations/neg/Z11.java ! test/tools/javac/annotations/neg/Z12.java ! test/tools/javac/annotations/neg/Z13.java ! test/tools/javac/annotations/neg/Z14.java ! test/tools/javac/annotations/neg/Z15.java ! test/tools/javac/annotations/neg/Z16.java ! test/tools/javac/annotations/neg/Z2.java ! test/tools/javac/annotations/neg/Z3.java ! test/tools/javac/annotations/neg/Z4.java ! test/tools/javac/annotations/neg/Z5.java ! test/tools/javac/annotations/neg/Z8.java ! test/tools/javac/annotations/neg/Z9.java ! test/tools/javac/annotations/pos/AnnoteElideBraces.java ! test/tools/javac/annotations/pos/ClassA.java ! test/tools/javac/annotations/pos/Dep.java ! test/tools/javac/annotations/pos/Enum1.java ! test/tools/javac/annotations/pos/Local.java ! test/tools/javac/annotations/pos/Members.java ! test/tools/javac/annotations/pos/NType.java ! test/tools/javac/annotations/pos/OverrideCheck.java ! test/tools/javac/annotations/pos/OverrideOK.java ! test/tools/javac/annotations/pos/Parameter.java ! test/tools/javac/annotations/pos/Primitives.java ! test/tools/javac/annotations/pos/RightTarget.java ! test/tools/javac/annotations/pos/Z1.java ! test/tools/javac/annotations/pos/Z2.java ! test/tools/javac/annotations/pos/Z3.java ! test/tools/javac/annotations/pos/Z4.java ! test/tools/javac/annotations/pos/package-info.java ! test/tools/javac/assert/Attach.java ! test/tools/javac/assert/DU1.java ! test/tools/javac/assert/DU2.java ! test/tools/javac/assert/Position.java ! test/tools/javac/boxing/BoxedForeach.java ! test/tools/javac/boxing/Boxing1.java ! test/tools/javac/boxing/Boxing2.java ! test/tools/javac/boxing/Boxing4.java ! test/tools/javac/boxing/BoxingCaching.java ! test/tools/javac/capture/Capture1.java ! test/tools/javac/capture/Capture2.java ! test/tools/javac/capture/Capture3.java ! test/tools/javac/capture/Capture5.java ! test/tools/javac/cast/BoxedArray.java ! test/tools/javac/enum/AbstractEmptyEnum.java ! test/tools/javac/enum/AbstractEnum1.java ! test/tools/javac/enum/DA1.java ! test/tools/javac/enum/DA2.java ! test/tools/javac/enum/DA3.java ! test/tools/javac/enum/Def.java ! test/tools/javac/enum/Enum1.java ! test/tools/javac/enum/Enum2.java ! test/tools/javac/enum/Enum3.java ! test/tools/javac/enum/EnumImplicitPrivateConstructor.java ! test/tools/javac/enum/EnumInit.java ! test/tools/javac/enum/EnumPrivateConstructor.java ! test/tools/javac/enum/EnumProtectedConstructor.java ! test/tools/javac/enum/EnumPublicConstructor.java ! test/tools/javac/enum/EnumSwitch1.java ! test/tools/javac/enum/EnumSwitch2.java ! test/tools/javac/enum/EnumSwitch3.java ! test/tools/javac/enum/EnumSwitch4.java ! test/tools/javac/enum/ExplicitlyAbstractEnum1.java ! test/tools/javac/enum/ExplicitlyAbstractEnum2.java ! test/tools/javac/enum/ExplicitlyFinalEnum1.java ! test/tools/javac/enum/ExplicitlyFinalEnum2.java ! test/tools/javac/enum/FauxEnum1.java ! test/tools/javac/enum/FauxEnum3.java ! test/tools/javac/enum/FauxSpecialEnum1.java ! test/tools/javac/enum/FauxSpecialEnum2.java ! test/tools/javac/enum/LocalEnum.java ! test/tools/javac/enum/NoFinal.java ! test/tools/javac/enum/NoFinal2.java ! test/tools/javac/enum/NoFinal3.java ! test/tools/javac/enum/NoFinal4.java ! test/tools/javac/enum/NoFinal5.java ! test/tools/javac/enum/OkFinal.java ! test/tools/javac/enum/SynthValues.java ! test/tools/javac/enum/T5075242.java ! test/tools/javac/enum/T5081785.java ! test/tools/javac/enum/TrailingComma.java ! test/tools/javac/enum/UserValue.java ! test/tools/javac/enum/ValueOf.java ! test/tools/javac/enum/enumSwitch/EnumSwitch.java ! test/tools/javac/foreach/Foreach.java ! test/tools/javac/foreach/GenericIterator.java ! test/tools/javac/foreach/IntersectIterator.java ! test/tools/javac/foreach/ListOfListTest.java ! test/tools/javac/foreach/SpecIterable.java ! test/tools/javac/foreach/StaticBlock.java ! test/tools/javac/foreach/SuperfluousAbstract.java ! test/tools/javac/generics/ArrayClone.java ! test/tools/javac/generics/ArrayTypearg.java ! test/tools/javac/generics/BridgeClash.java ! test/tools/javac/generics/BridgeOrder.java ! test/tools/javac/generics/CastCrash.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting2.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/Conditional.java ! test/tools/javac/generics/Covar2.java ! test/tools/javac/generics/Covar3.java ! test/tools/javac/generics/Covar4.java ! test/tools/javac/generics/Crash01.java ! test/tools/javac/generics/Crash02.java ! test/tools/javac/generics/CyclicInheritance3.java ! test/tools/javac/generics/CyclicInheritance5.java ! test/tools/javac/generics/ErasureClashCrash.java ! test/tools/javac/generics/ExtendedRaw1.java ! test/tools/javac/generics/ExtendedRaw2.java ! test/tools/javac/generics/ExtendedRaw3.java ! test/tools/javac/generics/ExtendedRaw4.java ! test/tools/javac/generics/FinalBridge.java ! test/tools/javac/generics/GenLit1.java ! test/tools/javac/generics/GenLit2.java ! test/tools/javac/generics/GenericAnonCtor.java ! test/tools/javac/generics/GenericMerge.java ! test/tools/javac/generics/GenericOverride.java ! test/tools/javac/generics/GenericThrowable.java ! test/tools/javac/generics/GetClass.java ! test/tools/javac/generics/GetClass2.java ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java ! test/tools/javac/generics/InheritanceConflict3.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/InstanceOf1.java ! test/tools/javac/generics/InstanceOf2.java ! test/tools/javac/generics/InstanceOf3.java ! test/tools/javac/generics/InterfaceCast1.java ! test/tools/javac/generics/LoadOrder.java ! test/tools/javac/generics/MissingBridge.java ! test/tools/javac/generics/MissingCast.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/Nonlinear.java ! test/tools/javac/generics/ParametricException.java ! test/tools/javac/generics/ParenVerify.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveClass.java ! test/tools/javac/generics/PrimitiveVariant.java ! test/tools/javac/generics/RawClient.java ! test/tools/javac/generics/RefEqual.java ! test/tools/javac/generics/RelaxedArrays.java ! test/tools/javac/generics/ReverseOrder.java ! test/tools/javac/generics/SelfImplement.java ! test/tools/javac/generics/SilentUnchecked.java ! test/tools/javac/generics/SuperTypeargs.java ! test/tools/javac/generics/T4661029.java ! test/tools/javac/generics/T4683314.java ! test/tools/javac/generics/T4684378.java ! test/tools/javac/generics/T4695348.java ! test/tools/javac/generics/T4695415.java ! test/tools/javac/generics/T4695847.java ! test/tools/javac/generics/T4711570.java ! test/tools/javac/generics/T4711572.java ! test/tools/javac/generics/T4711694.java ! test/tools/javac/generics/T4738171.java ! test/tools/javac/generics/T4739399.java ! test/tools/javac/generics/T4757416.java ! test/tools/javac/generics/T4784207a.java ! test/tools/javac/generics/T4784219.java ! test/tools/javac/generics/T5011073.java ! test/tools/javac/generics/T5094318.java ! test/tools/javac/generics/TyparamLit.java ! test/tools/javac/generics/TyparamStaticScope.java ! test/tools/javac/generics/TyparamStaticScope2.java ! test/tools/javac/generics/UncheckedArray.java ! test/tools/javac/generics/UncheckedConstructor.java ! test/tools/javac/generics/UncheckedCovariance.java ! test/tools/javac/generics/UnsoundInference.java ! test/tools/javac/generics/Varargs.java ! test/tools/javac/generics/Varargs2.java ! test/tools/javac/generics/WrongNew.java ! test/tools/javac/generics/abstract/T4717181c.java ! test/tools/javac/generics/bridge1/D.java ! test/tools/javac/generics/classreader/HArrayMethod.java ! test/tools/javac/generics/compat/CovariantCompat1.java ! test/tools/javac/generics/compat/OverrideBridge1.java ! test/tools/javac/generics/forwardSeparateBound/ForwardSeparateBound2.java ! test/tools/javac/generics/genericAbstract/A.java ! test/tools/javac/generics/odersky/BadTest.java ! test/tools/javac/generics/odersky/BadTest2.java ! test/tools/javac/generics/odersky/BadTest3.java ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/generics/odersky/Test.java ! test/tools/javac/generics/odersky/Test2.java ! test/tools/javac/generics/odersky/Test3.java ! test/tools/javac/generics/odersky/Test4.java ! test/tools/javac/generics/parametricException/J.java ! test/tools/javac/generics/rare/Rare1.java ! test/tools/javac/generics/rare/Rare10.java ! test/tools/javac/generics/rare/Rare11.java ! test/tools/javac/generics/rare/Rare2.java ! test/tools/javac/generics/rare/Rare3.java ! test/tools/javac/generics/rare/Rare4.java ! test/tools/javac/generics/rare/Rare5.java ! test/tools/javac/generics/rare/Rare6.java ! test/tools/javac/generics/rare/Rare7.java ! test/tools/javac/generics/rare/Rare8.java ! test/tools/javac/generics/rare/Rare9.java ! test/tools/javac/generics/rawSeparate/RetroLexer.java ! test/tools/javac/generics/typeargs/Basic.java ! test/tools/javac/generics/typeargs/Metharg1.java ! test/tools/javac/generics/typeargs/Metharg2.java ! test/tools/javac/generics/typeargs/Newarg1.java ! test/tools/javac/generics/typeargs/Newarg2.java ! test/tools/javac/generics/typeargs/Superarg1.java ! test/tools/javac/generics/typeargs/Superarg2.java ! test/tools/javac/generics/typeargs/ThisArg.java ! test/tools/javac/generics/typevars/4856983/T4856983.java ! test/tools/javac/generics/typevars/4856983/T4856983a.java ! test/tools/javac/generics/typevars/4856983/T4856983b.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes1.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes2.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes3.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes4.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes5.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes6.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes7.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes8.java ! test/tools/javac/generics/wildcards/AssignmentDifferentTypes9.java ! test/tools/javac/generics/wildcards/AssignmentSameType1.java ! test/tools/javac/generics/wildcards/AssignmentSameType2.java ! test/tools/javac/generics/wildcards/AssignmentSameType3.java ! test/tools/javac/generics/wildcards/AssignmentSameType4.java ! test/tools/javac/generics/wildcards/AssignmentSameType5.java ! test/tools/javac/generics/wildcards/AssignmentSameType6.java ! test/tools/javac/generics/wildcards/AssignmentSameType7.java ! test/tools/javac/generics/wildcards/AssignmentSameType8.java ! test/tools/javac/generics/wildcards/BoundBug.java ! test/tools/javac/generics/wildcards/ContraArg.java ! test/tools/javac/generics/wildcards/T5097548.java ! test/tools/javac/generics/wildcards/T5097548b.java ! test/tools/javac/generics/wildcards/UnboundArray.java ! test/tools/javac/generics/wildcards/neg/AmbiguousCast.java ! test/tools/javac/generics/wildcards/neg/Capture.java ! test/tools/javac/generics/wildcards/neg/CastFail1.java ! test/tools/javac/generics/wildcards/neg/CastFail10.java ! test/tools/javac/generics/wildcards/neg/CastFail11.java ! test/tools/javac/generics/wildcards/neg/CastFail12.java ! test/tools/javac/generics/wildcards/neg/CastFail13.java ! test/tools/javac/generics/wildcards/neg/CastFail14.java ! test/tools/javac/generics/wildcards/neg/CastFail15.java ! test/tools/javac/generics/wildcards/neg/CastFail16.java ! test/tools/javac/generics/wildcards/neg/CastFail17.java ! test/tools/javac/generics/wildcards/neg/CastFail18.java ! test/tools/javac/generics/wildcards/neg/CastFail19.java ! test/tools/javac/generics/wildcards/neg/CastFail2.java ! test/tools/javac/generics/wildcards/neg/CastFail20.java ! test/tools/javac/generics/wildcards/neg/CastFail21.java ! test/tools/javac/generics/wildcards/neg/CastFail3.java ! test/tools/javac/generics/wildcards/neg/CastFail4.java ! test/tools/javac/generics/wildcards/neg/CastFail5.java ! test/tools/javac/generics/wildcards/neg/CastFail6.java ! test/tools/javac/generics/wildcards/neg/CastFail7.java ! test/tools/javac/generics/wildcards/neg/CastFail8.java ! test/tools/javac/generics/wildcards/neg/CastFail9.java ! test/tools/javac/generics/wildcards/neg/CastWarn10.java ! test/tools/javac/generics/wildcards/neg/CastWarn11.java ! test/tools/javac/generics/wildcards/neg/CastWarn12.java ! test/tools/javac/generics/wildcards/neg/CastWarn13.java ! test/tools/javac/generics/wildcards/neg/CastWarn14.java ! test/tools/javac/generics/wildcards/neg/CastWarn2.java ! test/tools/javac/generics/wildcards/neg/CastWarn3.java ! test/tools/javac/generics/wildcards/neg/CastWarn4.java ! test/tools/javac/generics/wildcards/neg/CastWarn5.java ! test/tools/javac/generics/wildcards/neg/CastWarn6.java ! test/tools/javac/generics/wildcards/neg/CastWarn7.java ! test/tools/javac/generics/wildcards/neg/CastWarn8.java ! test/tools/javac/generics/wildcards/neg/CastWarn9.java ! test/tools/javac/generics/wildcards/neg/ParamCast.java ! test/tools/javac/generics/wildcards/neg/Readonly.java ! test/tools/javac/generics/wildcards/neg/Unbounded.java ! test/tools/javac/generics/wildcards/pos/AmbiguousCast2.java ! test/tools/javac/generics/wildcards/pos/BoundsCollision.java ! test/tools/javac/generics/wildcards/pos/Capture.java ! test/tools/javac/generics/wildcards/pos/CastTest.java ! test/tools/javac/generics/wildcards/pos/InstanceOf.java ! test/tools/javac/generics/wildcards/pos/ParamCast.java ! test/tools/javac/generics/wildcards/pos/RvalConversion.java ! test/tools/javac/generics/wildcards/pos/UncheckedCast1.java ! test/tools/javac/importscope/A.java ! test/tools/javac/limits/FinallyNesting.java ! test/tools/javac/lint/Unchecked.java ! test/tools/javac/miranda/T4711325.java ! test/tools/javac/mixedTarget/CompatibleAbstracts1.java ! test/tools/javac/mixedTarget/ExtendCovariant2.java ! test/tools/javac/overload/T5090220.java ! test/tools/javac/processing/environment/TestSourceVersion.java ! test/tools/javac/stackmap/UninitThis.java ! test/tools/javac/staticImport/Ambig1.java ! test/tools/javac/staticImport/ImportInherit.java ! test/tools/javac/staticImport/ImportPrivate.java ! test/tools/javac/staticImport/PrivateStaticImport.java ! test/tools/javac/staticImport/Shadow.java ! test/tools/javac/staticImport/StaticImport.java ! test/tools/javac/staticImport/StaticImport2.java ! test/tools/javac/unicode/Unmappable.java ! test/tools/javac/varargs/Anon.java ! test/tools/javac/varargs/BadSyntax2.java ! test/tools/javac/varargs/Varargs1.java ! test/tools/javac/varargs/VarargsOverride.java ! test/tools/javac/varargs/Warn1.java ! test/tools/javac/varargs/Warn2.java ! test/tools/javac/varargs/warning/Warn2.java ! test/tools/javac/varargs/warning/Warn3.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/annotations/annotateMethodsFields/Main.java ! test/tools/javadoc/annotations/annotatePackage/Main.java ! test/tools/javadoc/annotations/annotateParams/Main.java ! test/tools/javadoc/annotations/defaults/Main.java ! test/tools/javadoc/annotations/elementTypes/Main.java ! test/tools/javadoc/annotations/shortcuts/Main.java ! test/tools/javadoc/enum/docComments/Main.java ! test/tools/javadoc/enum/enumType/Main.java ! test/tools/javadoc/generics/genericClass/Main.java ! test/tools/javadoc/generics/genericInnerAndOuter/Main.java ! test/tools/javadoc/generics/genericInterface/Main.java ! test/tools/javadoc/generics/genericMethod/Main.java ! test/tools/javadoc/generics/genericSuper/Main.java ! test/tools/javadoc/generics/supertypes/Main.java ! test/tools/javadoc/generics/throwsGeneric/Main.java ! test/tools/javadoc/generics/tparamCycle/Main.java ! test/tools/javadoc/generics/tparamTagOnMethod/Main.java ! test/tools/javadoc/generics/tparamTagOnType/Main.java ! test/tools/javadoc/generics/wildcards/Main.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/varArgs/Main.java Changeset: d4828eba4939 Author: jjg Date: 2009-05-28 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/d4828eba4939 6802102: unignore @ignored tests where possible Reviewed-by: mcimadamore ! test/tools/javac/T6405099.java ! test/tools/javac/api/6431257/T6431257.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/code/ArrayClone.java - test/tools/javac/code/ArrayClone.sh ! test/tools/javac/generics/inference/6365166/NewTest.java Changeset: 47cf04bb80c9 Author: jjg Date: 2009-05-29 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/47cf04bb80c9 6838199: remove support for old javap Reviewed-by: ohair, mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Main.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java ! test/tools/javap/ExtPath.java - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 163f5d75f77a Author: tbell Date: 2009-06-11 21:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/163f5d75f77a Merge ! make/Makefile ! make/build.xml - src/share/classes/sun/tools/javap/AttrData.java - src/share/classes/sun/tools/javap/CPX.java - src/share/classes/sun/tools/javap/CPX2.java - src/share/classes/sun/tools/javap/ClassData.java - src/share/classes/sun/tools/javap/Constants.java - src/share/classes/sun/tools/javap/FieldData.java - src/share/classes/sun/tools/javap/InnerClassData.java - src/share/classes/sun/tools/javap/JavapEnvironment.java - src/share/classes/sun/tools/javap/JavapPrinter.java - src/share/classes/sun/tools/javap/LineNumData.java - src/share/classes/sun/tools/javap/LocVarData.java - src/share/classes/sun/tools/javap/Main.java - src/share/classes/sun/tools/javap/MethodData.java - src/share/classes/sun/tools/javap/RuntimeConstants.java - src/share/classes/sun/tools/javap/StackMapData.java - src/share/classes/sun/tools/javap/StackMapTableData.java - src/share/classes/sun/tools/javap/Tables.java - src/share/classes/sun/tools/javap/TrapData.java - src/share/classes/sun/tools/javap/TypeSignature.java - test/tools/javac/code/ArrayClone.sh - test/tools/javap/ListTest.java - test/tools/javap/OptionTest.java Changeset: 6855e5aa3348 Author: tbell Date: 2009-06-21 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/6855e5aa3348 Merge Changeset: 5c2c81120555 Author: xdono Date: 2009-06-25 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/5c2c81120555 Added tag jdk7-b62 for changeset 6855e5aa3348 ! .hgtags From lev.serebryakov at sun.com Fri Jun 26 13:36:51 2009 From: lev.serebryakov at sun.com (lev.serebryakov at sun.com) Date: Fri, 26 Jun 2009 20:36:51 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20090626203705.238C1E3AC@hg.openjdk.java.net> Changeset: 830ca2573896 Author: tonyp Date: 2009-06-12 16:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/830ca2573896 6850846: G1: extend G1 marking verification Summary: extend G1 marking verification to use either the "prev" or "next" marking information, as appropriate. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 85d0690f7d12 Author: jmasa Date: 2009-06-19 07:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/85d0690f7d12 Merge From martinrb at google.com Sat Jun 27 16:58:24 2009 From: martinrb at google.com (Martin Buchholz) Date: Sat, 27 Jun 2009 16:58:24 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A41E0B2.5050401@sun.com> References: <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> <4A41E0B2.5050401@sun.com> Message-ID: <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> Alright, I have a new simple version of the hotspot part of the jvmti-oom fix that should make Alan happy. ...Except for the usual problem that the code is screaming for a bit of refactoring, and it's not quite clear what file and function name it should be refactored to. I'll do the easy refactoring if you give me the names to use. Or simply give me thumbs up and I will commit. http://cr.openjdk.java.net/~martin/jvmti-oom/ http://cr.openjdk.java.net/~martin/jvmti-oom-test/ Thanks, Martin On Wed, Jun 24, 2009 at 01:15, Alan Bateman wrote: > David Holmes - Sun Microsystems wrote: > >> Jeremy, >> >> As I see it there was no consensus reached on whether this change should >> be made. I have some reservations as previously outlined, but Alan seemed to >> be of the view that the current situation was deliberately chosen - which >> implied to me (Alan correct me if I'm wrong) that he opposed the change. >> >> It may be that including this case in the OOM onError handling is okay, >> but that the JVMTI event posting is not. But Alan will need to clarify his >> position on that. >> > You got it. My view is that we should not post a JVM TI ResourceExhausted > event for this case. > > I think Jeremy's original motive was to have the OnOutOfMemoryError actions > run. I don't see a problem changing the code to do that. Yes, the current > behavior is deliberate but this option is for troubleshooting and maybe it > can help with the (probably rare) cases where this happens. > > The other point I attempted to make is that if both OnOutOfMemoryError and > HeapDumpOnOutOfMemoryError are enabled then we should always generate the > heap dump before the OnOutOfMemoryError run. I think we are in agreement > that the heap dump is not interesting here but we should still generate it > anyway. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090627/19fbcfd2/attachment.html From Alan.Bateman at Sun.COM Sun Jun 28 09:18:31 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 28 Jun 2009 17:18:31 +0100 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> References: <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> <4A41E0B2.5050401@sun.com> <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> Message-ID: <4A4797D7.90406@sun.com> Martin Buchholz wrote: > Alright, I have a new simple version of the hotspot part of the > jvmti-oom fix that should make Alan happy. > > ...Except for the usual problem that the code is screaming > for a bit of refactoring, and it's not quite clear what file > and function name it should be refactored to. I'll do the > easy refactoring if you give me the names to use. > Or simply give me thumbs up and I will commit. > > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > http://cr.openjdk.java.net/~martin/jvmti-oom-test/ > > > Thanks, > > Martin The changes you have are simple and address the need. As I said previously, I'm not working in this area regularly now so it would be good to have someone from runtime to review too, as I'm sure they will have better ideas for refactoring this. Clearly the hooks in collectedHeap.inline.hpp could be improved (these functions have grown, and I wonder if they are still inlined now). I meant to ask, but did you consider adding a test in the hotspot repository rather than updating the ProcessBuilder test in the jdk repository? I realize its a bit of extra work to do this. -Alan. From martinrb at google.com Sun Jun 28 09:46:42 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 28 Jun 2009 09:46:42 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A4797D7.90406@sun.com> References: <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> <4A41E0B2.5050401@sun.com> <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> <4A4797D7.90406@sun.com> Message-ID: <1ccfd1c10906280946u3fe79462t6eab571df7750697@mail.gmail.com> On Sun, Jun 28, 2009 at 09:18, Alan Bateman wrote: > > I meant to ask, but did you consider adding a test in the hotspot > repository rather than updating the ProcessBuilder test in the jdk > repository? I realize its a bit of extra work to do this. > Obviously the test "belongs" in the hotspot repo, but I'm unfamiliar with the hotspot tests and it was much easier for me to implement using my friendly ProcessBuilder/Basic.java. (It's true that I'll have to deal with integration skew.) Martin > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090628/cafc99dd/attachment.html From David.Holmes at Sun.COM Sun Jun 28 14:42:44 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 29 Jun 2009 07:42:44 +1000 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> References: <4A3578F1.6070401@sun.com> <4A361643.8040701@sun.com> <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> <4A41E0B2.5050401@sun.com> <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> Message-ID: <4A47E3D4.6000508@sun.com> I'm not sure what potential refactoring was being referred to given that this new fix simply adds a few calls to report_java_out_of_memory() prior to throwing the OOME. On that front the actual fix looks fine to me - it adds the "OnOOME" handling without messing with JVMTI at all (which means the JVMTI mention in the bug synopsis is somewhat misleading.) As far as the test goes, yes it should be in hotspot as a jtreg test but given you have to check the output of a exec'ed error program I don't know how to configure that either. :( One issue with the test however: there were four changes made to the VM code, but there are only three test cases! Which one is missing? And as Alan suggested, as I'm not an official runtime member these days, someone from runtime should also "rubber stamp" this. Thanks, David Martin Buchholz said the following on 06/28/09 09:58: > Alright, I have a new simple version of the hotspot part of the > jvmti-oom fix that should make Alan happy. > > ...Except for the usual problem that the code is screaming > for a bit of refactoring, and it's not quite clear what file > and function name it should be refactored to. I'll do the > easy refactoring if you give me the names to use. > Or simply give me thumbs up and I will commit. > > http://cr.openjdk.java.net/~martin/jvmti-oom/ > http://cr.openjdk.java.net/~martin/jvmti-oom-test/ > > Thanks, > > Martin > > On Wed, Jun 24, 2009 at 01:15, Alan Bateman > wrote: > > David Holmes - Sun Microsystems wrote: > > Jeremy, > > As I see it there was no consensus reached on whether this > change should be made. I have some reservations as previously > outlined, but Alan seemed to be of the view that the current > situation was deliberately chosen - which implied to me (Alan > correct me if I'm wrong) that he opposed the change. > > It may be that including this case in the OOM onError handling > is okay, but that the JVMTI event posting is not. But Alan will > need to clarify his position on that. > > You got it. My view is that we should not post a JVM TI > ResourceExhausted event for this case. > > I think Jeremy's original motive was to have the OnOutOfMemoryError > actions run. I don't see a problem changing the code to do that. > Yes, the current behavior is deliberate but this option is for > troubleshooting and maybe it can help with the (probably rare) cases > where this happens. > > The other point I attempted to make is that if both > OnOutOfMemoryError and HeapDumpOnOutOfMemoryError are enabled then > we should always generate the heap dump before the > OnOutOfMemoryError run. I think we are in agreement that the heap > dump is not interesting here but we should still generate it anyway. > > -Alan. > > From martinrb at google.com Mon Jun 29 14:58:26 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 29 Jun 2009 14:58:26 -0700 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <4A47E3D4.6000508@sun.com> References: <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> <4A41E0B2.5050401@sun.com> <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> <4A47E3D4.6000508@sun.com> Message-ID: <1ccfd1c10906291458s224e1a96wfa89ab264959b9fa@mail.gmail.com> Sun integrators: Please let me know what mechanics are required to actually integrate this. Ideally, I'd like to commit both hotspot and jdk repo changes to the hotspot-runtime forest. If that is not (yet) supported, I'd like to commit hotspot changes to hotspot-runtime, and I'll commit the jdk test changes to tl when hotspot changes trickle down into tl, so that the test doesn't fail when committed. On Sun, Jun 28, 2009 at 14:42, David Holmes - Sun Microsystems < David.Holmes at sun.com> wrote: > I'm not sure what potential refactoring was being referred to given that > this new fix simply adds a few calls to report_java_out_of_memory() prior to > throwing the OOME. On that front the actual fix looks fine to me - it adds > the "OnOOME" handling without messing with JVMTI at all (which means the > JVMTI mention in the bug synopsis is somewhat misleading.) > Good point. Could someone change the synopses of bugs as follows: 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit 6850957: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit I've changed URLS to be as follows http://cr.openjdk.java.net/~martin/OnOutOfMemoryError/ http://cr.openjdk.java.net/~martin/OnOutOfMemoryError-test/ > As far as the test goes, yes it should be in hotspot as a jtreg test but > given you have to check the output of a exec'ed error program I don't know > how to configure that either. :( > > One issue with the test however: there were four changes made to the VM > code, but there are only three test cases! Which one is missing? > Hmmmm.... instanceKlass may not be exposed to Java code - only for arrays of VM-internal objects. Can a real hotspot engineer confirm? Thanks, Martin > > > And as Alan suggested, as I'm not an official runtime member these days, > someone from runtime should also "rubber stamp" this. > > Thanks, > David > > Martin Buchholz said the following on 06/28/09 09:58: > >> Alright, I have a new simple version of the hotspot part of the >> jvmti-oom fix that should make Alan happy. >> >> ...Except for the usual problem that the code is screaming >> for a bit of refactoring, and it's not quite clear what file >> and function name it should be refactored to. I'll do the >> easy refactoring if you give me the names to use. >> Or simply give me thumbs up and I will commit. >> >> http://cr.openjdk.java.net/~martin/jvmti-oom/ >> http://cr.openjdk.java.net/~martin/jvmti-oom-test/ >> >> Thanks, >> >> Martin >> >> On Wed, Jun 24, 2009 at 01:15, Alan Bateman > Alan.Bateman at sun.com>> wrote: >> >> David Holmes - Sun Microsystems wrote: >> >> Jeremy, >> >> As I see it there was no consensus reached on whether this >> change should be made. I have some reservations as previously >> outlined, but Alan seemed to be of the view that the current >> situation was deliberately chosen - which implied to me (Alan >> correct me if I'm wrong) that he opposed the change. >> >> It may be that including this case in the OOM onError handling >> is okay, but that the JVMTI event posting is not. But Alan will >> need to clarify his position on that. >> >> You got it. My view is that we should not post a JVM TI >> ResourceExhausted event for this case. >> >> I think Jeremy's original motive was to have the OnOutOfMemoryError >> actions run. I don't see a problem changing the code to do that. >> Yes, the current behavior is deliberate but this option is for >> troubleshooting and maybe it can help with the (probably rare) cases >> where this happens. >> >> The other point I attempted to make is that if both >> OnOutOfMemoryError and HeapDumpOnOutOfMemoryError are enabled then >> we should always generate the heap dump before the >> OnOutOfMemoryError run. I think we are in agreement that the heap >> dump is not interesting here but we should still generate it anyway. >> >> -Alan. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20090629/54542610/attachment.html From David.Holmes at Sun.COM Mon Jun 29 16:55:10 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Tue, 30 Jun 2009 09:55:10 +1000 Subject: JVMTI OOM handling when arrays / objects are too large In-Reply-To: <1ccfd1c10906291458s224e1a96wfa89ab264959b9fa@mail.gmail.com> References: <1ccfd1c10906161357q685207efv582999f81360cee3@mail.gmail.com> <4A38C1C4.3070703@sun.com> <4A4130C6.5040202@sun.com> <4A416990.2050908@sun.com> <4A41E0B2.5050401@sun.com> <1ccfd1c10906271658k6db702b1vb4c58e0229183717@mail.gmail.com> <4A47E3D4.6000508@sun.com> <1ccfd1c10906291458s224e1a96wfa89ab264959b9fa@mail.gmail.com> Message-ID: <4A49545E.1030606@sun.com> Hi Martin, Martin Buchholz said the following on 06/30/09 07:58: > Could someone change the synopses of bugs as follows: > > 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit > 6850957: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit > > I've changed URLS to be as follows > http://cr.openjdk.java.net/~martin/OnOutOfMemoryError/ > http://cr.openjdk.java.net/~martin/OnOutOfMemoryError-test/ The CRs have been updated and the Hotspot CR moved to runtime from JVMTI. I've referenced this email thread, linked to webrevs and cross-linked CRs. > One issue with the test however: there were four changes made to the > VM code, but there are only three test cases! Which one is missing? > > Hmmmm.... instanceKlass may not be exposed to Java code - > only for arrays of VM-internal objects. > Can a real hotspot engineer confirm? Hmmm instanceKlass seems to be the main one used AFAICS: JRT_ENTRY(void, Runtime1::new_object_array(JavaThread* thread, klassOopDesc* array_klass, jint length)) calls oopFactory::new_objArray(elem_klass, length, CHECK); calls ((instanceKlass*)klass->klass_part())->allocate_objArray(1, length, THREAD); which appears to tbe instanceKlass allocate_objArray. But I'd rely more on a printf inside the methods that a visual code walk :) David > Thanks, > > Martin > > > > > > > > And as Alan suggested, as I'm not an official runtime member these > days, someone from runtime should also "rubber stamp" this. > > Thanks, > David > > Martin Buchholz said the following on 06/28/09 09:58: > > Alright, I have a new simple version of the hotspot part of the > jvmti-oom fix that should make Alan happy. > > ...Except for the usual problem that the code is screaming > for a bit of refactoring, and it's not quite clear what file > and function name it should be refactored to. I'll do the > easy refactoring if you give me the names to use. > Or simply give me thumbs up and I will commit. > > http://cr.openjdk.java.net/~martin/jvmti-oom/ > > http://cr.openjdk.java.net/~martin/jvmti-oom-test/ > > > Thanks, > > Martin > > On Wed, Jun 24, 2009 at 01:15, Alan Bateman > > >> wrote: > > David Holmes - Sun Microsystems wrote: > > Jeremy, > > As I see it there was no consensus reached on whether this > change should be made. I have some reservations as previously > outlined, but Alan seemed to be of the view that the current > situation was deliberately chosen - which implied to me (Alan > correct me if I'm wrong) that he opposed the change. > > It may be that including this case in the OOM onError > handling > is okay, but that the JVMTI event posting is not. But > Alan will > need to clarify his position on that. > > You got it. My view is that we should not post a JVM TI > ResourceExhausted event for this case. > > I think Jeremy's original motive was to have the > OnOutOfMemoryError > actions run. I don't see a problem changing the code to do that. > Yes, the current behavior is deliberate but this option is for > troubleshooting and maybe it can help with the (probably > rare) cases > where this happens. > > The other point I attempted to make is that if both > OnOutOfMemoryError and HeapDumpOnOutOfMemoryError are enabled > then > we should always generate the heap dump before the > OnOutOfMemoryError run. I think we are in agreement that the heap > dump is not interesting here but we should still generate it > anyway. > > -Alan. > > >