From ik3g09 at ecs.soton.ac.uk Mon Aug 2 13:17:25 2010 From: ik3g09 at ecs.soton.ac.uk (kammerath i. (ik3g09)) Date: Mon, 2 Aug 2010 21:17:25 +0100 Subject: Research into modifications on the primordial class loader Message-ID: Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members, After initial contact with core-libs-owner, I have been able to get a lot further. The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. Where am I: Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not). Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play? I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"? I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. Many thanks in advance Ivo ________________________________________ From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu] Sent: 01 August 2010 03:35 To: kammerath i. (ik3g09) Subject: RE: Research on the primordial class loader Hi, Ivo. I didn't receive your original message. I don't know what happened as it isn't in the set of pending moderator requests and your message didn't seem to make it into our archive (see the "archive link") near the top of this page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev One way to avoid the need for moderation is to become a subscriber. There is a digest mode if you get inundated with mail. Alternatively, you could just unsubscribe as soon as you get the information you need. I think that core-libs-dev is a fine place to ask your question. Alternatively hotspot-dev or hotspot-runtime-dev may also be good candidates as that is where a great deal of heavy lifting occurs for class loading. Here are some pointers for you to begin your investigation. I've selected subversion files from the JDK7 tl repository, but these files will reside in similar locations in other JDK repositories. http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j ava/lang/ClassLoader.java java.lang.ClassLoader provides the specification for the delegation model and is the primary implementation. Note that specification comments such as this: "If the parent is "null", the class loader built-in to the virtual machine..." and the corresponding null checks are references to class loader implemented by the VM. http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja va/lang/ClassLoader.c The supporting libraries C code for j.l.ClassLoader. This is where libraries makes the calls into the VM. http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl assfile/ I am by no means a VM expert, but I believe that this is where the VM implements most of class loading. A VM engineer will be able to provide more details. http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html I'm sure you've' already found it, but just in case... The VM specification, Chapter 5 contains the complete spec for loading, linking, and initializing: Hope this gets you started. My apologies for not seeing your earlier message. Thanks, iris ________________________________________ From: Ivo Sent: 29 July 2010 17:15 To: core-libs-dev at openjdk.java.net Subject: Research on the primordial class loader Hello core-libs-dev members, In my research on dynamic continuous integration at run-time and dynamic self-modification. I reached a point where I would like to have a look at the implementation of the 'Primordial ClassLoader'. Which, according to what I read so far, is responsible for loading all classes, excluding those loaded by any custom ClassLaoder. When I downloaded the OpenJDK source I felt a little lost, I could not quite work out where to look. As far as I understood, the Primordial ClassLoader is more than just a bunch of Java classes. Correct me if I am wrong, but I assume it involves a few C/C++ classes/procedures? So my question is: Which classes are involved in the primordial classloading and which files of the HotSpot are involved in the process? many thanks in advance Ivo From tom.rodriguez at oracle.com Mon Aug 2 13:45:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 2 Aug 2010 13:45:21 -0700 Subject: 6953477: review request for portability improvements to Hotspot In-Reply-To: <4C523AC0.4080701@oracle.com> References: <519B53B7-43A3-4F78-8CF5-E8FBA50F1C0C@oracle.com> <7FFD27E9-2BFF-4EF2-ACE1-57486E1D98A4@oracle.com> <4C523AC0.4080701@oracle.com> Message-ID: <1F9557F6-EF38-4EC5-A1EE-15A85255A394@oracle.com> On Jul 29, 2010, at 7:36 PM, David Holmes wrote: > Hi Tom, > > Thanks for the close scrutiny. > > Tom Rodriguez said the following on 07/30/10 03:18: >> The print_location changes in os::print_context are interesting, if a >> little verbose. Do you have an example of what the output will look >> like? > > Internally there are some examples in the CR for 6889724. I also posted something below. > >> You should make equivalent changes in os_windows_x86.cpp too. > > Ideally yes, but at the time, as now, I had no access to Windows boxes for building or testing this. jprt always builds windows and I'm not sure how much testing this needs. The print_location code itself is platform dependent and as long as the code compiles it seems like it should work. > Registers: > r0 = 0x000b0c00 > r1 = 0x00006b70 > r2 = 0x00000000 > r3 = 0x00000064 > r4 = 0x00000000 > r5 = 0x000b0c00 > r6 = 0x000b0c00 > r7 = 0x00021400 > r8 = 0x00020638 > r9 = 0x4a650c58 > r10 = 0x00000000 > fp = 0x406fcad4 > r12 = 0x00000001 > sp = 0x406fca58 > lr = 0x403e1768 > pc = 0x40480278 > > > Register to memory mapping: > r0 = 0x000b0c00 > "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] > java.lang.Thread.State: RUNNABLE This is pretty verbose since we print the register values twice. Why not just print them once by losing the first section? The lack of indenting makes it less readable too though that's harder to fix without modifing every print_on routines which I'm not sure we want to do. Maybe the printing should just start on the same line instead of having a cr in between. Printing nothing for unknown values might make sense too. tom > r1 = 0x00006b70 > 0x00006b70 is pointing to unknown location > r2 = 0x00000000 > 0x00000000 is pointing to unknown location > r3 = 0x00000064 > 0x00000064 is pointing to unknown location > r4 = 0x00000000 > 0x00000000 is pointing to unknown location > r5 = 0x000b0c00 > "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] > java.lang.Thread.State: RUNNABLE > r6 = 0x000b0c00 > "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] > java.lang.Thread.State: RUNNABLE > r7 = 0x00021400 > "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] > java.lang.Thread.State: RUNNABLE > r8 = 0x00020638 > 0x00020638 is pointing to unknown location > r9 = 0x4a650c58 > {method} > - klass: {other class} > r10 = 0x00000000 > 0x00000000 is pointing to unknown location > fp = 0x406fcad4 > 0x406fcad4 is pointing into the stack for thread: 0x00021400 > "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] > java.lang.Thread.State: RUNNABLE > r12 = 0x00000001 > 0x00000001 is pointing to unknown location > sp = 0x406fca58 > 0x406fca58 is pointing into the stack for thread: 0x00021400 > "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] > java.lang.Thread.State: RUNNABLE > lr = 0x403e1768 > 0x403e1768: JVM_StartThread+0xe8 in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000 > pc = 0x40480278 > 0x40480278: in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000 From daniel.daugherty at oracle.com Mon Aug 2 15:58:14 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 02 Aug 2010 22:58:14 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20100802225824.92E7147E78@hg.openjdk.java.net> Changeset: a81afd9c293c Author: alanb Date: 2010-07-16 13:14 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a81afd9c293c 6649594: Intermittent IOExceptions during dynamic attach on linux and solaris Reviewed-by: dcubed, dholmes ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 920aa833fd16 Author: apangin Date: 2010-07-17 21:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/920aa833fd16 Merge Changeset: a5c9d63a187d Author: apangin Date: 2010-07-20 08:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a5c9d63a187d 6964170: Verifier crashes Summary: Check if klassOop != NULL rather than klass_part != NULL Reviewed-by: kamg, never ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verifier.cpp Changeset: 7f0fdccac34f Author: apangin Date: 2010-07-25 07:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7f0fdccac34f Merge ! src/share/vm/classfile/verifier.cpp Changeset: 3d90023429ec Author: aph Date: 2010-07-28 17:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3d90023429ec 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows Reviewed-by: dcubed, dholmes ! src/os/linux/vm/globals_linux.hpp ! src/share/vm/runtime/arguments.cpp Changeset: a64438a2b7e8 Author: coleenp Date: 2010-07-28 17:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a64438a2b7e8 6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue Summary: Fix compilation errors. Made non-const references const so can be assigned with lvalue. Reviewed-by: phh, xlu ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp From David.Holmes at oracle.com Mon Aug 2 16:44:35 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 03 Aug 2010 09:44:35 +1000 Subject: Research into modifications on the primordial class loader In-Reply-To: References: Message-ID: <4C575863.1050602@oracle.com> Just a clarification on terminology. The native loader in the VM is the bootstrap loader. A class was loaded by the bootstrap loader if its ClassLoader is reported as "null". There is then a hierarchy of classloaders created: - the extensions loader is used to add the ability to load standard extensions (from lib/ext if I recall correctly) these are classes that are treated the same as "core" classes for security purposes - the application-class loader, aka the system classloader (bad name), is created to load the application class that you want to run The application can then define its own classloaders. For a ClassLoader to actually load a class it must use defineClass, which is implemented in the VM as part of the native loader. Hence any subterfuge has to be done inside the VM: you need to look at the systemDictionary and the loader_constraints, which enforce the language rules. I really don't know how you would go about doing what you suggest because the details are the critical points here. You could define a ClassLoader that returned an arbitrary Class object for a given name, but that Class object would report it's real identity. If this was part of an implicit classloading process, then you'd likely get a ClassCastException, or some other exception if you actually tried to return a different Class than required. Good luck. David Holmes kammerath i. (ik3g09) said the following on 08/03/10 06:17: > Hello hotspot-runtime-dev, Hotspot-dev and core-libs-dev members, > > After initial contact with core-libs-owner, I have been able to get a lot further. > The idea is to make certain modifications to the primordial/system-ClassLoader that lower security measures to gain a certain insight into higher reload-ability. As far as I currently understand, The Primordial ClassLoader is a mixture of system specific C files and standard Java classes. I am working with the version proposed below by Iris. > > When reloading an existing class I am so far forced to create a new classloader, as one classloader always has to return the same class object reference for the same class name. Meaning if I want to reload a class I always need an interface implemented by both the old and the new class-version to have a common type between both the custom and the system classloader, which allows me to access both versions of the class the same way (over a proxy pattern, to make references replaceable). > > Now I want to do something that one might consider as highly insecure. I want to allow a classloader to return different class object reference for the same class name. Thus I could bypass the whole interface fiddle and simply access the new object by the same type. I am aware of the fact that this means breaking the type-system/type-safe idea. As this means that two different types are considered as one without any shared inheritance. But logically they are the same type, but simply evolved. > > Where am I: > > Whilst reading through ClassLoader.java I came along void addClass(Class c) [line 258] which apperently is used by the JVM to record loaded classes, would this be where I could interfere by simply not record classes annotated with reloadable or something like that. Such that when checking whether a class is already registered it simply wouldn't be, thus I could reload it (probably not). > > Further along I came across getSystemClassLoader() in which I found initSystemClassLoader which lead me to Launcher.java [sun.misc.Launcher] in which I found the top-level nested class AppClassLoader, which I assume is the actual Primordial/System-ClassLoader. At least it is what ClassLoader.getSystemClassLoader() returns. In it I found a call "BootClassLoaderHook.preLoadClass(name);" is this where the C comes into play? > I couldn't find anything else in the Java sources relating to "BootClassLoaderHook". What is this doing? Is this where I can make my insecure changes? Iris also pointed out ClassLoader.c, might this be what's hooked in with this specific call? if it is, how is it "hooked in"? > > I am open for any other suggestions in terms of: "where I could make changes" and "what changes I could make", to achieve the higher/different (even though less secure) reload ability. > > Many thanks in advance > Ivo > ________________________________________ > From: Iris Clark [iris at agathis.com] On Behalf Of irisg at alum.mit.edu [irisg at alum.mit.edu] > Sent: 01 August 2010 03:35 > To: kammerath i. (ik3g09) > Subject: RE: Research on the primordial class loader > > Hi, Ivo. > > I didn't receive your original message. I don't know what happened as it > isn't in the set of pending moderator requests and your message didn't seem > to make it into our archive (see the "archive link") near the top of this > page: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > > One way to avoid the need for moderation is to become a subscriber. There > is a digest mode if you get inundated with mail. Alternatively, you could > just unsubscribe as soon as you get the information you need. > > I think that core-libs-dev is a fine place to ask your question. > Alternatively hotspot-dev or hotspot-runtime-dev may also be good > candidates as that is where a great deal of heavy lifting occurs for class > loading. Here are some pointers for you to begin your investigation. I've > selected subversion files from the JDK7 tl repository, but these files will > reside in similar locations in other JDK repositories. > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/classes/j > ava/lang/ClassLoader.java > java.lang.ClassLoader provides the specification for the delegation model > and is the primary implementation. Note that specification comments such > as this: "If the parent is "null", the class loader built-in to the > virtual machine..." and the corresponding null checks are references to > class loader implemented by the VM. > > http://hg.openjdk.java.net/jdk7/tl/jdk/file/4d72d0ec83f5/src/share/native/ja > va/lang/ClassLoader.c > The supporting libraries C code for j.l.ClassLoader. This is where > libraries makes the calls into the VM. > > http://hg.openjdk.java.net/jdk7/tl/hotspot/file/cb4250ef73b2/src/share/vm/cl > assfile/ > I am by no means a VM expert, but I believe that this is where the VM > implements most of class loading. A VM engineer will be able to provide > more details. > > http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html > I'm sure you've' already found it, but just in case... The VM > specification, > Chapter 5 contains the complete spec for loading, linking, and > initializing: > > Hope this gets you started. My apologies for not seeing your earlier > message. > > Thanks, > iris > ________________________________________ > From: Ivo > Sent: 29 July 2010 17:15 > To: core-libs-dev at openjdk.java.net > Subject: Research on the primordial class loader > > Hello core-libs-dev members, > > In my research on dynamic continuous integration at run-time and dynamic > self-modification. > I reached a point where I would like to have a look at the implementation of > the 'Primordial ClassLoader'. > Which, according to what I read so far, is responsible for loading all > classes, excluding those loaded by any > custom ClassLaoder. > > When I downloaded the OpenJDK source I felt a little lost, I could not quite > work out where to look. > As far as I understood, the Primordial ClassLoader is more than just a > bunch of Java classes. > Correct me if I am wrong, but I assume it involves a few C/C++ > classes/procedures? > > So my question is: > Which classes are involved in the primordial classloading and which files of > the HotSpot are involved in the process? > > many thanks in advance > Ivo From David.Holmes at oracle.com Mon Aug 2 16:57:01 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 03 Aug 2010 09:57:01 +1000 Subject: 6953477: review request for portability improvements to Hotspot In-Reply-To: <1F9557F6-EF38-4EC5-A1EE-15A85255A394@oracle.com> References: <519B53B7-43A3-4F78-8CF5-E8FBA50F1C0C@oracle.com> <7FFD27E9-2BFF-4EF2-ACE1-57486E1D98A4@oracle.com> <4C523AC0.4080701@oracle.com> <1F9557F6-EF38-4EC5-A1EE-15A85255A394@oracle.com> Message-ID: <4C575B4D.2070104@oracle.com> Tom Rodriguez said the following on 08/03/10 06:45: > On Jul 29, 2010, at 7:36 PM, David Holmes wrote: >> Tom Rodriguez said the following on 07/30/10 03:18: >>> You should make equivalent changes in os_windows_x86.cpp too. >> Ideally yes, but at the time, as now, I had no access to Windows boxes for building or testing this. > > jprt always builds windows and I'm not sure how much testing this needs. The print_location code itself is platform dependent and as long as the code compiles it seems like it should work. Building via jprt is hardly an effective development process. >> Registers: >> r0 = 0x000b0c00 >> r1 = 0x00006b70 >> r2 = 0x00000000 >> r3 = 0x00000064 >> r4 = 0x00000000 >> r5 = 0x000b0c00 >> r6 = 0x000b0c00 >> r7 = 0x00021400 >> r8 = 0x00020638 >> r9 = 0x4a650c58 >> r10 = 0x00000000 >> fp = 0x406fcad4 >> r12 = 0x00000001 >> sp = 0x406fca58 >> lr = 0x403e1768 >> pc = 0x40480278 >> >> >> Register to memory mapping: >> r0 = 0x000b0c00 >> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] >> java.lang.Thread.State: RUNNABLE > > This is pretty verbose since we print the register values twice. > Why not just print them once by losing the first section? Because it is entirely possible that attempting to print some information about a register value will induce a secondary crash. This way you at least get the original set of crash registers reported. I use a newline to start the printing because I don't know how the individual print routines will format things. The current approach should at least make it clear where the boundaries are. David ----- The lack of indenting makes it less readable too though that's harder to fix without modifing every print_on routines which I'm not sure we want to do. Maybe the printing should just start on the same line instead of having a cr in between. Printing nothing for unknown values might make sense too. > > tom > >> r1 = 0x00006b70 >> 0x00006b70 is pointing to unknown location >> r2 = 0x00000000 >> 0x00000000 is pointing to unknown location >> r3 = 0x00000064 >> 0x00000064 is pointing to unknown location >> r4 = 0x00000000 >> 0x00000000 is pointing to unknown location >> r5 = 0x000b0c00 >> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] >> java.lang.Thread.State: RUNNABLE >> r6 = 0x000b0c00 >> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] >> java.lang.Thread.State: RUNNABLE >> r7 = 0x00021400 >> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] >> java.lang.Thread.State: RUNNABLE >> r8 = 0x00020638 >> 0x00020638 is pointing to unknown location >> r9 = 0x4a650c58 >> {method} >> - klass: {other class} >> r10 = 0x00000000 >> 0x00000000 is pointing to unknown location >> fp = 0x406fcad4 >> 0x406fcad4 is pointing into the stack for thread: 0x00021400 >> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] >> java.lang.Thread.State: RUNNABLE >> r12 = 0x00000001 >> 0x00000001 is pointing to unknown location >> sp = 0x406fca58 >> 0x406fca58 is pointing into the stack for thread: 0x00021400 >> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] >> java.lang.Thread.State: RUNNABLE >> lr = 0x403e1768 >> 0x403e1768: JVM_StartThread+0xe8 in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000 >> pc = 0x40480278 >> 0x40480278: in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000 > From tom.rodriguez at oracle.com Mon Aug 2 16:59:36 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 2 Aug 2010 16:59:36 -0700 Subject: 6953477: review request for portability improvements to Hotspot In-Reply-To: <4C575B4D.2070104@oracle.com> References: <519B53B7-43A3-4F78-8CF5-E8FBA50F1C0C@oracle.com> <7FFD27E9-2BFF-4EF2-ACE1-57486E1D98A4@oracle.com> <4C523AC0.4080701@oracle.com> <1F9557F6-EF38-4EC5-A1EE-15A85255A394@oracle.com> <4C575B4D.2070104@oracle.com> Message-ID: <5337031D-0DA1-4343-A344-FC5AFE341F33@oracle.com> On Aug 2, 2010, at 4:57 PM, David Holmes wrote: > Tom Rodriguez said the following on 08/03/10 06:45: >> On Jul 29, 2010, at 7:36 PM, David Holmes wrote: >>> Tom Rodriguez said the following on 07/30/10 03:18: >>>> You should make equivalent changes in os_windows_x86.cpp too. >>> Ideally yes, but at the time, as now, I had no access to Windows boxes for building or testing this. >> jprt always builds windows and I'm not sure how much testing this needs. The print_location code itself is platform dependent and as long as the code compiles it seems like it should work. > > Building via jprt is hardly an effective development process. In general sure but it would be good enough for this I think. > >>> Registers: >>> r0 = 0x000b0c00 >>> r1 = 0x00006b70 >>> r2 = 0x00000000 >>> r3 = 0x00000064 >>> r4 = 0x00000000 >>> r5 = 0x000b0c00 >>> r6 = 0x000b0c00 >>> r7 = 0x00021400 >>> r8 = 0x00020638 >>> r9 = 0x4a650c58 >>> r10 = 0x00000000 >>> fp = 0x406fcad4 >>> r12 = 0x00000001 >>> sp = 0x406fca58 >>> lr = 0x403e1768 >>> pc = 0x40480278 >>> >>> >>> Register to memory mapping: >>> r0 = 0x000b0c00 >>> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] >>> java.lang.Thread.State: RUNNABLE >> This is pretty verbose since we print the register values twice. > > Why not just print them once by losing the first section? > > Because it is entirely possible that attempting to print some information about a register value will induce a secondary crash. This way you at least get the original set of crash registers reported. Oh right, good point. > > I use a newline to start the printing because I don't know how the individual print routines will format things. The current approach should at least make it clear where the boundaries are. Fair enough. tom > > David > ----- > > The lack of indenting makes it less readable too though that's harder to fix without modifing every print_on routines which I'm not sure we want to do. Maybe the printing should just start on the same line instead of having a cr in between. Printing nothing for unknown values might make sense too. >> tom >>> r1 = 0x00006b70 >>> 0x00006b70 is pointing to unknown location >>> r2 = 0x00000000 >>> 0x00000000 is pointing to unknown location >>> r3 = 0x00000064 >>> 0x00000064 is pointing to unknown location >>> r4 = 0x00000000 >>> 0x00000000 is pointing to unknown location >>> r5 = 0x000b0c00 >>> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] >>> java.lang.Thread.State: RUNNABLE >>> r6 = 0x000b0c00 >>> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000] >>> java.lang.Thread.State: RUNNABLE >>> r7 = 0x00021400 >>> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] >>> java.lang.Thread.State: RUNNABLE >>> r8 = 0x00020638 >>> 0x00020638 is pointing to unknown location >>> r9 = 0x4a650c58 >>> {method} >>> - klass: {other class} >>> r10 = 0x00000000 >>> 0x00000000 is pointing to unknown location >>> fp = 0x406fcad4 >>> 0x406fcad4 is pointing into the stack for thread: 0x00021400 >>> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] >>> java.lang.Thread.State: RUNNABLE >>> r12 = 0x00000001 >>> 0x00000001 is pointing to unknown location >>> sp = 0x406fca58 >>> 0x406fca58 is pointing into the stack for thread: 0x00021400 >>> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000] >>> java.lang.Thread.State: RUNNABLE >>> lr = 0x403e1768 >>> 0x403e1768: JVM_StartThread+0xe8 in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000 >>> pc = 0x40480278 >>> 0x40480278: in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000 From tmarble at info9.net Thu Aug 5 18:57:46 2010 From: tmarble at info9.net (Tom Marble) Date: Thu, 05 Aug 2010 20:57:46 -0500 Subject: OpenJDK on hppa (reprise) Message-ID: <4C5B6C1A.9040602@info9.net> All: Back in January there were some threads on this and specifically about the direction of stack growth [0] (cross posted [1] [2]). The Debian Java team has decided that as we need to support this architecture and thus I wanted to see if any others have attacked this or have any other tips about how difficult it may be to convince Zero to cooperate? To avoid the cross-posting problem I have set Reply-To: (and would kindly request followups to) hotspot-dev. Thanks! --Tom [0] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-January/thread.html#7886 [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-January/thread.html#2529 [2] http://lists.debian.org/debian-java/2010/01/threads.html#00002 From gbenson at redhat.com Fri Aug 6 02:58:53 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 6 Aug 2010 10:58:53 +0100 Subject: OpenJDK on hppa (reprise) In-Reply-To: <4C5B6C1A.9040602@info9.net> References: <4C5B6C1A.9040602@info9.net> Message-ID: <20100806095853.GA3685@redhat.com> Tom Marble wrote: > Back in January there were some threads on this and specifically > about the direction of stack growth [0] (cross posted [1] [2]). > > The Debian Java team has decided that as we need to support this > architecture and thus I wanted to see if any others have attacked > this or have any other tips about how difficult it may be to > convince Zero to cooperate? What happened in January was some people talked about difficulties that *might* arise *if* they tried to make Zero work on HPPA. To actually make Zero work on HPPA what needs to happen is that somebody with a machine needs to grab a copy of OpenJDK and try to build and run it. I'm available by email and on #openjdk to help people with any issues they have with Zero and Shark on any platform. Cheers, Gary -- http://gbenson.net/ From ptisnovs at redhat.com Fri Aug 6 07:05:52 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 06 Aug 2010 16:05:52 +0200 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> Message-ID: <4C5C16C0.4070301@redhat.com> Tom Rodriguez wrote: > I think you could put this check into arguments.cpp since I all platforms would require a positive number for the StackShadowPages. The same should be true of StackRedPages and StackYellowPages. Actually they all should be required to greater than 0 I think. Other than that I don't see other obvious constraints on the values. That bug report doesn't really show other problematic values, though I'm not sure I follow the point of the guarantee that's failing either. What does the min stack size have to do with the number of guard pages? I would expect it to be checking against ThreadStackSize and returning an error if it was too small like the other places that check against TheadStackSize. > > tom Hi Tom, I've added check for all Stack*Pages parameters to arguments.cpp. Can you please review the changes? http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ Is there any reason why Stack*Pages parameters are of type int and not unsigned int? I'm able to change its types (these variables are generated by macro which accepts type as one of its parameter) but I'm not sure if it would be correct in all cases. Cheers Pavel > > On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: > >> Hi all, >> >> can anybody please review two quite simple changes in JVM initialization code? Webrev is available at: >> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >> >> When -XX:StackShadowPages is set to negative integer or zero value, JVM segfaulted on Linux and, according to http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on Solaris (although I only check this issue on Linux) >> >> I also would like to add more check for -XX:StackRedPages, -XX:StackShadowPages and -XX:StackYellowPages options to avoid issue described in the bug report mentioned above (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to find relevant information about proper conditions (it may depends on page sizes, VM stack size etc.). Any ideas? >> >> Cheers >> Pavel Tisnovsky >> > From vladimir.kozlov at oracle.com Fri Aug 6 09:48:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 06 Aug 2010 09:48:29 -0700 Subject: Request for reviews (XS): 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 Message-ID: <4C5C3CDD.9000409@oracle.com> http://cr.openjdk.java.net/~kvn/6975049/webrev Fixed 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 The problem started when we switched to SS12 compilers. SS12 C++ inlines too much into StubGenerator_generate() - it inlines all methods defined in StubGenerator class. Just for StubGenerator_generate() it needs 80K stack: StubGenerator_generate+0x0006: subl $0x0001464c,%esp <<< 0x0001464c == 83532 StubGenerator_generate+0x000c: call StubGenerator_generate+0x11 <<< SEGV The main consumer of stack space is Address object (36 bytes in 32bit VM). For example, in xmm_copy_forward() method we generate and initialize separate Address object for each instruction. And Sun C++ doesn't free these objects space at the end of local scope. Solution: Tell C++ to not inline so much by using flag -xspace. It is not performance critical code since it is executed only during startup. Tested with failed case. From tom.rodriguez at oracle.com Fri Aug 6 12:05:12 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 6 Aug 2010 12:05:12 -0700 Subject: Request for reviews (XS): 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 In-Reply-To: <4C5C3CDD.9000409@oracle.com> References: <4C5C3CDD.9000409@oracle.com> Message-ID: <1FC96879-7A2D-4837-87EB-61060C11A578@oracle.com> Looks good. tom On Aug 6, 2010, at 9:48 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6975049/webrev > > Fixed 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 > > The problem started when we switched to SS12 compilers. > SS12 C++ inlines too much into StubGenerator_generate() - it inlines > all methods defined in StubGenerator class. Just for StubGenerator_generate() > it needs 80K stack: > > StubGenerator_generate+0x0006: subl $0x0001464c,%esp <<< 0x0001464c == 83532 > StubGenerator_generate+0x000c: call StubGenerator_generate+0x11 <<< SEGV > > The main consumer of stack space is Address object (36 bytes in 32bit VM). > For example, in xmm_copy_forward() method we generate and initialize > separate Address object for each instruction. > And Sun C++ doesn't free these objects space at the end of local scope. > > Solution: > Tell C++ to not inline so much by using flag -xspace. > It is not performance critical code since it is executed only during startup. > > Tested with failed case. From vladimir.kozlov at oracle.com Fri Aug 6 12:06:37 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 06 Aug 2010 12:06:37 -0700 Subject: Request for reviews (XS): 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 In-Reply-To: <1FC96879-7A2D-4837-87EB-61060C11A578@oracle.com> References: <4C5C3CDD.9000409@oracle.com> <1FC96879-7A2D-4837-87EB-61060C11A578@oracle.com> Message-ID: <4C5C5D3D.9040002@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Aug 6, 2010, at 9:48 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6975049/webrev >> >> Fixed 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 >> >> The problem started when we switched to SS12 compilers. >> SS12 C++ inlines too much into StubGenerator_generate() - it inlines >> all methods defined in StubGenerator class. Just for StubGenerator_generate() >> it needs 80K stack: >> >> StubGenerator_generate+0x0006: subl $0x0001464c,%esp <<< 0x0001464c == 83532 >> StubGenerator_generate+0x000c: call StubGenerator_generate+0x11 <<< SEGV >> >> The main consumer of stack space is Address object (36 bytes in 32bit VM). >> For example, in xmm_copy_forward() method we generate and initialize >> separate Address object for each instruction. >> And Sun C++ doesn't free these objects space at the end of local scope. >> >> Solution: >> Tell C++ to not inline so much by using flag -xspace. >> It is not performance critical code since it is executed only during startup. >> >> Tested with failed case. > From rathore.ajay at gmail.com Sat Aug 7 11:39:12 2010 From: rathore.ajay at gmail.com (Ajay Rathore) Date: Sun, 8 Aug 2010 00:09:12 +0530 Subject: Openjdk source Message-ID: Hi Everyone, I have just started hacking into openjdk source. I need some help in setting up Netbeans IDE with the source, specially the C code of hotspot. Also i wanted to ask more experienced people here about the learning curve for openjdk, shall i start with hotspot or langtools or some other module. Also i believe that a lot of the documentation available online is very abstract, is there any documentation which can give the relevant information in proper depth. Thanks, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100808/287f5ec6/attachment.html From doko at ubuntu.com Sat Aug 7 12:10:13 2010 From: doko at ubuntu.com (Matthias Klose) Date: Sat, 07 Aug 2010 21:10:13 +0200 Subject: OpenJDK on hppa (reprise) In-Reply-To: <20100806095853.GA3685@redhat.com> References: <4C5B6C1A.9040602@info9.net> <20100806095853.GA3685@redhat.com> Message-ID: <4C5DAF95.1030206@ubuntu.com> On 06.08.2010 11:58, Gary Benson wrote: > Tom Marble wrote: >> Back in January there were some threads on this and specifically >> about the direction of stack growth [0] (cross posted [1] [2]). >> >> The Debian Java team has decided that as we need to support this >> architecture and thus I wanted to see if any others have attacked >> this or have any other tips about how difficult it may be to >> convince Zero to cooperate? > > What happened in January was some people talked about difficulties > that *might* arise *if* they tried to make Zero work on HPPA. > > To actually make Zero work on HPPA what needs to happen is that > somebody with a machine needs to grab a copy of OpenJDK and try > to build and run it. > > I'm available by email and on #openjdk to help people with any > issues they have with Zero and Shark on any platform. Debian developers do have access to such machines. Please email me if somebody outside of Debian wants access to such a machine. Matthias From rathore.ajay at gmail.com Sun Aug 8 09:32:15 2010 From: rathore.ajay at gmail.com (Ajay Rathore) Date: Sun, 8 Aug 2010 22:02:15 +0530 Subject: Openjdk source In-Reply-To: References: Message-ID: Hi, As i am new to this forum, it would be great be someone could respond to my queries. Thanks, Ajay On Sun, Aug 8, 2010 at 12:09 AM, Ajay Rathore wrote: > Hi Everyone, > > I have just started hacking into openjdk source. I need some help in > setting up Netbeans IDE with the source, specially the C code of hotspot. > Also i wanted to ask more experienced people here about the learning curve > for openjdk, shall i start with hotspot or langtools or some other module. > Also i believe that a lot of the documentation available online is very > abstract, is there any documentation which can give the relevant information > in proper depth. > > Thanks, > Ajay > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100808/e2bd464e/attachment.html From kelly.ohair at oracle.com Sun Aug 8 15:48:05 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Sun, 8 Aug 2010 15:48:05 -0700 Subject: Openjdk source In-Reply-To: References: Message-ID: In general, NetBeans is not used to build the entire JDK, it just takes too long. NetBeans usage is usually specific to a developer working on some specific part of the jdk, usually the Java code portions. Some of the repositories of the openjdk forest of repositories, like langtools, jaxp, and jaxws. are independent and can be opened up and built with netbeans. I know the langtools team uses netbeans quite a bit. Depending on the area of the jdk you are interested in, you would need to check with that team and ask them how they use netbeans, or what they use. Some teams do not use netbeans, but other tools, some teams use a variety of tools. The netbeans projects in the jdk repository (jdk/make/netbeans) were originally populated as a way to demonstrate how it might work, I'm not sure all are operational, and the way netbeans works, I suspect that the build-impl.xml files are out of date, so the first thing netbeans will do if you open up one of these projects is try and update the nbproject/build-impl.xml files. I'm not sure about hotspot and netbeans usage, someone on the hotspot team would need to comment. For langtools the compiler-dev alias should be used. And the hotspot code is C++, not C. You need to look in the hotspot repository for the various readme files for more info. -kto On Aug 8, 2010, at 9:32 AM, Ajay Rathore wrote: > Hi, > > As i am new to this forum, it would be great be someone could > respond to my queries. > > Thanks, > Ajay > > > On Sun, Aug 8, 2010 at 12:09 AM, Ajay Rathore > wrote: > Hi Everyone, > > I have just started hacking into openjdk source. I need some help in > setting up Netbeans IDE with the source, specially the C code of > hotspot. > Also i wanted to ask more experienced people here about the learning > curve for openjdk, shall i start with hotspot or langtools or some > other module. > Also i believe that a lot of the documentation available online is > very abstract, is there any documentation which can give the > relevant information in proper depth. > > Thanks, > Ajay > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100808/8e59a8fd/attachment.html From dalibor.topic at oracle.com Mon Aug 9 00:34:41 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 09 Aug 2010 09:34:41 +0200 Subject: Openjdk source In-Reply-To: References: Message-ID: <4C5FAF91.8030805@oracle.com> On 8/7/10 8:39 PM, Ajay Rathore wrote: > Hi Everyone, > > I have just started hacking into openjdk source. I need some help in setting up Netbeans IDE with the source, specially the C code of hotspot. See http://cnd.netbeans.org/docs/hotspot-projects/ or http://weblogs.java.net/blog/simonis/archive/2008/01/hotspot_develop_1.html for a start. > Also i believe that a lot of the documentation available online is very abstract, is there any documentation which can give the relevant information in proper depth. For HotSpot, see http://wikis.sun.com/display/HotSpotInternals/Home cheers, dalibor topic -- Dalibor Topic Phone: +49 40 23646738 Oracle ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment From christian.thalinger at oracle.com Mon Aug 9 01:11:07 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 09 Aug 2010 10:11:07 +0200 Subject: question about share/tools In-Reply-To: References: Message-ID: <1281341467.1119.41.camel@macbook> On Fri, 2010-07-30 at 16:30 +0800, Yongqiang Yang wrote: > hi, > > > Could someone explain functionalities of share/tools in hotspot? MakeDeps is required during build, all other tools have a README where you can read what they are. > And whether it is related to hotspot's startup? None of them. -- Christian From paul.hohensee at oracle.com Mon Aug 9 10:58:41 2010 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Mon, 09 Aug 2010 17:58:41 +0000 Subject: hg: jdk7/hotspot/hotspot: 6953477: Increase portability and flexibility of building Hotspot Message-ID: <20100809175844.C251847008@hg.openjdk.java.net> Changeset: 126ea7725993 Author: bobv Date: 2010-08-03 08:13 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/126ea7725993 6953477: Increase portability and flexibility of building Hotspot Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail. Reviewed-by: phh, never, coleenp, dholmes ! agent/src/os/linux/ps_proc.c ! make/Makefile ! make/defs.make ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/product.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/javaFrameAnchor_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/arrayKlassKlass.hpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassKlass.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp From tom.rodriguez at oracle.com Thu Aug 12 15:13:08 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 12 Aug 2010 22:13:08 +0000 Subject: hg: jdk7/hotspot/hotspot: 12 new changesets Message-ID: <20100812221328.A468A4710B@hg.openjdk.java.net> Changeset: e5dfb3ccb88b Author: kvn Date: 2010-07-23 10:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e5dfb3ccb88b 6969569: assert(is_static() && is_constant()) failed: illegal call to constant_value() Summary: Add missing is_static guard. Reviewed-by: twisti ! src/share/vm/ci/ciField.cpp ! src/share/vm/opto/macro.cpp Changeset: 99ceb0e99c9e Author: never Date: 2010-07-26 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/99ceb0e99c9e Merge Changeset: 66c5dadb4d61 Author: kvn Date: 2010-07-30 10:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/66c5dadb4d61 6973308: Missing zero length check before repne scas in check_klass_subtype_slow_path() Summary: set Z = 0 (not equal) before repne_scan() to indicate that class was not found when RCX == 0. Reviewed-by: never, phh ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 0e35fa8ebccd Author: kvn Date: 2010-08-03 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e35fa8ebccd 6973963: SEGV in ciBlock::start_bci() with EA Summary: Added more checks into ResourceObj and growableArray to verify correctness of allocation type. Reviewed-by: never, coleenp, dholmes ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/utilities/growableArray.hpp Changeset: 0e09207fc81b Author: kvn Date: 2010-08-04 17:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e09207fc81b 6974682: CTW: assert(target != NULL) failed: must not be null Summary: Add address table size to constant section size. Reviewed-by: never ! src/share/vm/opto/output.cpp Changeset: fb8abd207dbe Author: kvn Date: 2010-08-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fb8abd207dbe 6975049: nsk/regression/b4287029 crashes with -Xss64 on solaris-i586 Summary: Tell C++ to not inline so much by using flag -xspace. Reviewed-by: ysr ! make/solaris/makefiles/sparcWorks.make Changeset: 2dfd013a7465 Author: kvn Date: 2010-08-09 15:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2dfd013a7465 6975078: assert(allocated_on_res_area() || allocated_on_C_heap() || allocated_on_arena() Summary: Pass the check in ResourceObj() if _allocation value is already set and object is allocated on stack. Reviewed-by: dholmes, johnc ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: f4f596978298 Author: never Date: 2010-08-09 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f4f596978298 Merge ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 36519c19beeb Author: never Date: 2010-08-10 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36519c19beeb 6975027: use of movptr to set length of array Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 4a665be40fd3 Author: twisti Date: 2010-08-11 01:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4a665be40fd3 6975855: don't emit deopt MH handler in C1 if not required Summary: This CR implements the same for C1 as 6926782 for C2. Reviewed-by: never ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/code/nmethod.cpp Changeset: d2ede61b7a12 Author: twisti Date: 2010-08-11 05:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d2ede61b7a12 6976186: integrate Shark HotSpot changes Summary: Shark is a JIT compiler for Zero that uses the LLVM compiler infrastructure. Reviewed-by: kvn, twisti Contributed-by: Gary Benson ! make/Makefile ! make/linux/Makefile ! make/linux/makefiles/gcc.make + make/linux/makefiles/shark.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! src/cpu/zero/vm/disassembler_zero.hpp + src/cpu/zero/vm/shark_globals_zero.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.cpp + src/share/vm/includeDB_shark ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp + src/share/vm/shark/llvmHeaders.hpp + src/share/vm/shark/llvmValue.hpp + src/share/vm/shark/sharkBlock.cpp + src/share/vm/shark/sharkBlock.hpp + src/share/vm/shark/sharkBuilder.cpp + src/share/vm/shark/sharkBuilder.hpp + src/share/vm/shark/sharkCacheDecache.cpp + src/share/vm/shark/sharkCacheDecache.hpp + src/share/vm/shark/sharkCodeBuffer.hpp + src/share/vm/shark/sharkCompiler.cpp + src/share/vm/shark/sharkCompiler.hpp + src/share/vm/shark/sharkConstant.cpp + src/share/vm/shark/sharkConstant.hpp + src/share/vm/shark/sharkContext.cpp + src/share/vm/shark/sharkContext.hpp + src/share/vm/shark/sharkEntry.hpp + src/share/vm/shark/sharkFunction.cpp + src/share/vm/shark/sharkFunction.hpp + src/share/vm/shark/sharkInliner.cpp + src/share/vm/shark/sharkInliner.hpp + src/share/vm/shark/sharkIntrinsics.cpp + src/share/vm/shark/sharkIntrinsics.hpp + src/share/vm/shark/sharkInvariants.cpp + src/share/vm/shark/sharkInvariants.hpp + src/share/vm/shark/sharkMemoryManager.cpp + src/share/vm/shark/sharkMemoryManager.hpp + src/share/vm/shark/sharkNativeWrapper.cpp + src/share/vm/shark/sharkNativeWrapper.hpp + src/share/vm/shark/sharkRuntime.cpp + src/share/vm/shark/sharkRuntime.hpp + src/share/vm/shark/sharkStack.cpp + src/share/vm/shark/sharkStack.hpp + src/share/vm/shark/sharkState.cpp + src/share/vm/shark/sharkState.hpp + src/share/vm/shark/sharkStateScanner.cpp + src/share/vm/shark/sharkStateScanner.hpp + src/share/vm/shark/sharkTopLevelBlock.cpp + src/share/vm/shark/sharkTopLevelBlock.hpp + src/share/vm/shark/sharkType.hpp + src/share/vm/shark/sharkValue.cpp + src/share/vm/shark/sharkValue.hpp + src/share/vm/shark/shark_globals.cpp + src/share/vm/shark/shark_globals.hpp ! src/share/vm/utilities/macros.hpp Changeset: 6c9cc03d8726 Author: kvn Date: 2010-08-11 10:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c9cc03d8726 6973329: C2 with Zero based COOP produces code with broken anti-dependency on x86 Summary: Recompile without subsuming loads if RA try to clone a node with anti_dependence. Reviewed-by: never ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/reg_split.cpp + test/compiler/6973329/Test.java From daniel.daugherty at oracle.com Fri Aug 13 09:42:53 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 13 Aug 2010 16:42:53 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20100813164257.A298047157@hg.openjdk.java.net> Changeset: ab3fd720516c Author: rasbold Date: 2010-08-10 19:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ab3fd720516c 6378314: Bad warning message when agent library not found. local directory is not searched. Summary: Print a more detailed error message for agent library load failure. Reviewed-by: jcoomes, never, ohair, coleenp Contributed-by: jeremymanson at google.com ! src/share/vm/runtime/thread.cpp Changeset: 21e519b91576 Author: dcubed Date: 2010-08-13 07:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/21e519b91576 Merge ! src/share/vm/runtime/thread.cpp From john.cuthbertson at sun.com Sat Aug 14 03:11:17 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Sat, 14 Aug 2010 10:11:17 +0000 Subject: hg: jdk7/hotspot/hotspot: 11 new changesets Message-ID: <20100814101143.10D9547194@hg.openjdk.java.net> Changeset: f6f3eef8a521 Author: kevinw Date: 2010-07-30 22:43 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f6f3eef8a521 6581734: CMS Old Gen's collection usage is zero after GC which is incorrect Summary: Management code enabled for use by a concurrent collector. Reviewed-by: mchung, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/6581734/Test6581734.java Changeset: 63f4675ac87d Author: kevinw Date: 2010-07-31 15:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/63f4675ac87d Merge - src/os/linux/vm/vtune_linux.cpp - src/os/solaris/vm/vtune_solaris.cpp - src/os/windows/vm/vtune_windows.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp - src/share/vm/runtime/vtune.hpp Changeset: 2d160770d2e5 Author: johnc Date: 2010-08-02 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2d160770d2e5 6814437: G1: remove the _new_refs array Summary: The per-worker _new_refs array is used to hold references that point into the collection set. It is populated during RSet updating and subsequently processed. In the event of an evacuation failure it processed again to recreate the RSets of regions in the collection set. Remove the per-worker _new_refs array by processing the references directly. Use a DirtyCardQueue to hold the cards containing the references so that the RSets of regions in the collection set can be recreated when handling an evacuation failure. Reviewed-by: iveresov, jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: 9d7a8ab3736b Author: tonyp Date: 2010-07-22 10:27 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9d7a8ab3736b 6962589: remove breadth first scanning code from parallel gc Summary: Remove the breadth-first copying order from ParallelScavenge and use depth-first by default. Reviewed-by: jcoomes, ysr, johnc ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/symbolKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 0ce1569c90e5 Author: tonyp Date: 2010-08-04 13:03 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0ce1569c90e5 6963209: G1: remove the concept of abandoned pauses Summary: As part of 6944166 we disabled the concept of abandoned pauses (i.e., if the collection set is empty, we would still try to do a pause even if it is to update the RSets and scan the roots). This changeset removes the code and structures associated with abandoned pauses. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: a03ae377b2e8 Author: johnc Date: 2010-08-06 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a03ae377b2e8 6930581: G1: assert(ParallelGCThreads > 1 || n_yielded() == _hrrs->occupied(),"Should have yielded all the .. Summary: During RSet updating, when ParallelGCThreads is zero, references that point into the collection set are added directly the referenced region's RSet. This can cause the sparse table in the RSet to expand. RSet scanning and the "occupied" routine will then operate on different instances of the sparse table causing the assert to trip. This may also cause some cards added post expansion to be missed during RSet scanning. When ParallelGCThreads is non-zero such references are recorded on the "references to be scanned" queue and the card containing the reference is recorded in a dirty card queue for use in the event of an evacuation failure. Employ the parallel code in the serial case to avoid expanding the RSets of regions in the collection set. Reviewed-by: iveresov, ysr, tonyp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp Changeset: 5f429ee79634 Author: jcoomes Date: 2010-08-09 05:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5f429ee79634 6966222: G1: simplify TaskQueue overflow handling Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 94251661de76 Author: jcoomes Date: 2010-08-09 18:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/94251661de76 6970376: ParNew: shared TaskQueue statistics Reviewed-by: ysr ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp Changeset: a6bff45449bc Author: ysr Date: 2010-08-10 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a6bff45449bc 6973570: OrderAccess::storestore() scales poorly on multi-socket x64 and sparc: cache-line ping-ponging Summary: volatile store to static variable removed in favour of a volatile store to stack to avoid excessive cache coherency traffic; verified that the volatile store is not elided by any of our current compilers. Reviewed-by: dholmes, dice, jcoomes, kvn ! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp Changeset: 2d6b74c9a797 Author: jcoomes Date: 2010-08-11 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2d6b74c9a797 6976378: ParNew: stats are printed unconditionally in debug builds Reviewed-by: tonyp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp Changeset: 7fcd5f39bd7a Author: johnc Date: 2010-08-14 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7fcd5f39bd7a Merge - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From David.Holmes at oracle.com Sun Aug 15 18:43:19 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2010 11:43:19 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9A0CE6.7010504@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> Message-ID: <4C6897B7.7090807@oracle.com> Andrew, Coleen, Andrew Haley said the following on 03/12/10 19:44: > On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >> I've added the test to the changeset and a script to run in our harness. >> >> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >> os::Linux::gettid() because on at least one linux, syscall() returns a >> long int which gets a compilation warning with %d. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >> >> Andrew, please have a look since you're the contributor. > > That's OK, but you don't need SYS_gettid. > Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch > I changed to "/proc/self/maps", as you requested. I think this is better. It looks like the use of /proc/self/maps can be a thread termination bottleneck. Is there a way to determine whether this functionality is needed for the current thread without actually reading the map file? Thanks, David Holmes From David.Holmes at oracle.com Sun Aug 15 19:46:00 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 16 Aug 2010 12:46:00 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6897B7.7090807@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> Message-ID: <4C68A668.2000000@oracle.com> Looking further into this, isn't the only thread that can be affected by this the main thread? So we could perform this only if os::is_initial_thread() returns true? David David Holmes said the following on 08/16/10 11:43: > Andrew, Coleen, > > Andrew Haley said the following on 03/12/10 19:44: >> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>> I've added the test to the changeset and a script to run in our harness. >>> >>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>> os::Linux::gettid() because on at least one linux, syscall() returns a >>> long int which gets a compilation warning with %d. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>> >>> Andrew, please have a look since you're the contributor. >> >> That's OK, but you don't need SYS_gettid. >> Please look at >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >> I changed to "/proc/self/maps", as you requested. I think this is >> better. > > It looks like the use of /proc/self/maps can be a thread termination > bottleneck. Is there a way to determine whether this functionality is > needed for the current thread without actually reading the map file? > > Thanks, > David Holmes > From aph at redhat.com Mon Aug 16 01:42:39 2010 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Aug 2010 09:42:39 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C68A668.2000000@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> Message-ID: <4C68F9FF.9080700@redhat.com> On 08/16/2010 03:46 AM, David Holmes wrote: > Looking further into this, isn't the only thread that can be affected by > this the main thread? So we could perform this only if > os::is_initial_thread() returns true? I suppose we could, yes. I wonder if it'd be a latent bug to assume that Java threads could never use growable mappings, though. Doing this makes the system a bit less robust. Do you really think that the cost of get_stack_bounds() is significant in the context of terminating a thread? Andrew. > David Holmes said the following on 08/16/10 11:43: >> Andrew, Coleen, >> >> Andrew Haley said the following on 03/12/10 19:44: >>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>>> I've added the test to the changeset and a script to run in our >>>> harness. >>>> >>>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>>> os::Linux::gettid() because on at least one linux, syscall() returns a >>>> long int which gets a compilation warning with %d. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>> >>>> Andrew, please have a look since you're the contributor. >>> >>> That's OK, but you don't need SYS_gettid. >>> Please look at >>> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>> I changed to "/proc/self/maps", as you requested. I think this is >>> better. >> >> It looks like the use of /proc/self/maps can be a thread termination >> bottleneck. Is there a way to determine whether this functionality is >> needed for the current thread without actually reading the map file? >> >> Thanks, >> David Holmes >> From omajid at redhat.com Mon Aug 16 08:50:31 2010 From: omajid at redhat.com (Omair Majid) Date: Mon, 16 Aug 2010 11:50:31 -0400 Subject: trying to fix 6843484 (os::commit_memory() failures are not handled properly on linux) Message-ID: <4C695E47.3040909@redhat.com> Hi, I have been trying to fix 6843484. The bug relies on exact behaviour of mmap(2) on linux. I have asked for help from kernel developers and they have suggested that this is not a bug. Just so that I am clear, here is what I understood from the bug report: The bug happens if hotspot does (1) mmap(ADDR,..., MAP_NORESERVE,...) = succeeds followed by (2) mmap(ADDR, .....) = fails in which case the map from (1) is lost. The linux kernel developers have suggested (and this is what I also observed in my testing) that the map is, in fact, preserved. What should be the next step? Is there a test case that demonstrates the behaviour indicated in the bug report? Thanks, Omair From fw at deneb.enyo.de Mon Aug 16 10:37:38 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 16 Aug 2010 19:37:38 +0200 Subject: trying to fix 6843484 (os::commit_memory() failures are not handled properly on linux) In-Reply-To: <4C695E47.3040909@redhat.com> (Omair Majid's message of "Mon, 16 Aug 2010 11:50:31 -0400") References: <4C695E47.3040909@redhat.com> Message-ID: <87k4nq4fx9.fsf@mid.deneb.enyo.de> * Omair Majid: > Hi, > > I have been trying to fix 6843484. The bug relies on exact behaviour > of mmap(2) on linux. I have asked for help from kernel developers and > they have suggested that this is not a bug. Just so that I am clear, > here is what I understood from the bug report: > > The bug happens if hotspot does > (1) mmap(ADDR,..., MAP_NORESERVE,...) = succeeds > followed by > (2) mmap(ADDR, .....) = fails > in which case the map from (1) is lost. You should change that to mmap(PROT_NONE) followed by memprotect(). It has got the added benefit of better working with vm.overcommit_memory=2, too. 8-) From David.Holmes at oracle.com Mon Aug 16 15:57:44 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 17 Aug 2010 08:57:44 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C68F9FF.9080700@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> Message-ID: <4C69C268.8030803@oracle.com> Andrew Haley said the following on 08/16/10 18:42: > On 08/16/2010 03:46 AM, David Holmes wrote: >> Looking further into this, isn't the only thread that can be affected by >> this the main thread? So we could perform this only if >> os::is_initial_thread() returns true? > > I suppose we could, yes. I wonder if it'd be a latent bug to assume > that Java threads could never use growable mappings, though. Doing > this makes the system a bit less robust. As I understand it neither LinuxThreads nor NPTL have used growable mappings for a very long time. Even if there were a reason to go back to this it would have to be done in a compatible way and so there would be time to "enhance" the VM to accommodate it. > Do you really think that the cost of get_stack_bounds() is significant in > the context of terminating a thread? It can be. This has introduced a new bottleneck on the thread termination path and we're seeing that affect on certain systems (the details of which I can't go in to). Cheers, David Holmes > Andrew. > > >> David Holmes said the following on 08/16/10 11:43: >>> Andrew, Coleen, >>> >>> Andrew Haley said the following on 03/12/10 19:44: >>>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>>>> I've added the test to the changeset and a script to run in our >>>>> harness. >>>>> >>>>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>>>> os::Linux::gettid() because on at least one linux, syscall() returns a >>>>> long int which gets a compilation warning with %d. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>>> >>>>> Andrew, please have a look since you're the contributor. >>>> That's OK, but you don't need SYS_gettid. >>>> Please look at >>>> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>>> I changed to "/proc/self/maps", as you requested. I think this is >>>> better. >>> It looks like the use of /proc/self/maps can be a thread termination >>> bottleneck. Is there a way to determine whether this functionality is >>> needed for the current thread without actually reading the map file? >>> >>> Thanks, >>> David Holmes >>> > From aph at redhat.com Tue Aug 17 01:14:20 2010 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Aug 2010 09:14:20 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C69C268.8030803@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> Message-ID: <4C6A44DC.1090703@redhat.com> On 08/16/2010 11:57 PM, David Holmes wrote: > Andrew Haley said the following on 08/16/10 18:42: >> On 08/16/2010 03:46 AM, David Holmes wrote: >>> Looking further into this, isn't the only thread that can be affected by >>> this the main thread? So we could perform this only if >>> os::is_initial_thread() returns true? >> >> I suppose we could, yes. I wonder if it'd be a latent bug to assume >> that Java threads could never use growable mappings, though. Doing >> this makes the system a bit less robust. > > As I understand it neither LinuxThreads nor NPTL have used growable > mappings for a very long time. Even if there were a reason to go back to > this it would have to be done in a compatible way and so there would be > time to "enhance" the VM to accommodate it. Oh, I'm sure there would. The problem is that this bug is very subtle, and if it came back again it would be just as hard to diagnose. If the change to use growable mappings were made upstream on some platform, would we notice? >> Do you really think that the cost of get_stack_bounds() is significant in >> the context of terminating a thread? > > It can be. This has introduced a new bottleneck on the thread > termination path and we're seeing that affect on certain systems (the > details of which I can't go in to). Aha, so this is not just a theoretical concern. Fair enough. It seems like I may have falsely assumed the work in the kernel to terminate a thread would be greater than this. Andrew. From tom.rodriguez at oracle.com Tue Aug 17 12:50:38 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 17 Aug 2010 12:50:38 -0700 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C5C16C0.4070301@redhat.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> Message-ID: <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: > Tom Rodriguez wrote: >> I think you could put this check into arguments.cpp since I all platforms would require a positive number for the StackShadowPages. The same should be true of StackRedPages and StackYellowPages. Actually they all should be required to greater than 0 I think. Other than that I don't see other obvious constraints on the values. That bug report doesn't really show other problematic values, though I'm not sure I follow the point of the guarantee that's failing either. What does the min stack size have to do with the number of guard pages? I would expect it to be checking against ThreadStackSize and returning an error if it was too small like the other places that check against TheadStackSize. >> >> tom > > Hi Tom, > > I've added check for all Stack*Pages parameters to arguments.cpp. Can > you please review the changes? > > http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ > > Is there any reason why Stack*Pages parameters are of type int and not > unsigned int? I'm able to change its types (these variables are > generated by macro which accepts type as one of its parameter) but I'm > not sure if it would be correct in all cases. Would someone from runtime want to comment on this? It seems ok to me. Changing to uintx would also be ok but it might require other uses to be converted to unsigned as well. I'd probably just leave it alone myself. tom > > Cheers > Pavel > >> >> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >> >>> Hi all, >>> >>> can anybody please review two quite simple changes in JVM initialization code? Webrev is available at: >>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>> >>> When -XX:StackShadowPages is set to negative integer or zero value, JVM segfaulted on Linux and, according to http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on Solaris (although I only check this issue on Linux) >>> >>> I also would like to add more check for -XX:StackRedPages, -XX:StackShadowPages and -XX:StackYellowPages options to avoid issue described in the bug report mentioned above (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to find relevant information about proper conditions (it may depends on page sizes, VM stack size etc.). Any ideas? >>> >>> Cheers >>> Pavel Tisnovsky >>> >> > From paul.hohensee at oracle.com Tue Aug 17 13:02:24 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 17 Aug 2010 16:02:24 -0400 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> Message-ID: <4C6AEAD0.8030206@oracle.com> Leave them as intx, imo. Their high bound value isn't anywhere near maxint, and if you change them to uintx you'll have to cast them to intx for the calls to verify_min_value. Plus there's some places where their values are assigned to ints that would have to be changed. Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. Paul On 8/17/10 3:50 PM, Tom Rodriguez wrote: > On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: > >> Tom Rodriguez wrote: >>> I think you could put this check into arguments.cpp since I all platforms would require a positive number for the StackShadowPages. The same should be true of StackRedPages and StackYellowPages. Actually they all should be required to greater than 0 I think. Other than that I don't see other obvious constraints on the values. That bug report doesn't really show other problematic values, though I'm not sure I follow the point of the guarantee that's failing either. What does the min stack size have to do with the number of guard pages? I would expect it to be checking against ThreadStackSize and returning an error if it was too small like the other places that check against TheadStackSize. >>> >>> tom >> Hi Tom, >> >> I've added check for all Stack*Pages parameters to arguments.cpp. Can >> you please review the changes? >> >> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >> >> Is there any reason why Stack*Pages parameters are of type int and not >> unsigned int? I'm able to change its types (these variables are >> generated by macro which accepts type as one of its parameter) but I'm >> not sure if it would be correct in all cases. > Would someone from runtime want to comment on this? It seems ok to me. Changing to uintx would also be ok but it might require other uses to be converted to unsigned as well. I'd probably just leave it alone myself. > > tom > > >> Cheers >> Pavel >> >>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>> >>>> Hi all, >>>> >>>> can anybody please review two quite simple changes in JVM initialization code? Webrev is available at: >>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>> >>>> When -XX:StackShadowPages is set to negative integer or zero value, JVM segfaulted on Linux and, according to http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on Solaris (although I only check this issue on Linux) >>>> >>>> I also would like to add more check for -XX:StackRedPages, -XX:StackShadowPages and -XX:StackYellowPages options to avoid issue described in the bug report mentioned above (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to find relevant information about proper conditions (it may depends on page sizes, VM stack size etc.). Any ideas? >>>> >>>> Cheers >>>> Pavel Tisnovsky >>>> From coleen.phillimore at oracle.com Tue Aug 17 13:17:40 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 17 Aug 2010 16:17:40 -0400 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C6AEAD0.8030206@oracle.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> <4C6AEAD0.8030206@oracle.com> Message-ID: <4C6AEE64.7050207@oracle.com> Yes, I agree they should stay intx. Thank you for the change. It looks fine to me. If you update the patch, I will push it through JPRT. Let me know when it is ready. thanks, Coleen Paul Hohensee wrote: > Leave them as intx, imo. Their high bound value isn't anywhere near > maxint, > and if you change them to uintx you'll have to cast them to intx for the > calls to verify_min_value. Plus there's some places where their > values are > assigned to ints that would have to be changed. > > Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. > > Paul > > On 8/17/10 3:50 PM, Tom Rodriguez wrote: >> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: >> >>> Tom Rodriguez wrote: >>>> I think you could put this check into arguments.cpp since I all >>>> platforms would require a positive number for the >>>> StackShadowPages. The same should be true of StackRedPages and >>>> StackYellowPages. Actually they all should be required to greater >>>> than 0 I think. Other than that I don't see other obvious >>>> constraints on the values. That bug report doesn't really show >>>> other problematic values, though I'm not sure I follow the point of >>>> the guarantee that's failing either. What does the min stack size >>>> have to do with the number of guard pages? I would expect it to be >>>> checking against ThreadStackSize and returning an error if it was >>>> too small like the other places that check against TheadStackSize. >>>> >>>> tom >>> Hi Tom, >>> >>> I've added check for all Stack*Pages parameters to arguments.cpp. Can >>> you please review the changes? >>> >>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >>> >>> Is there any reason why Stack*Pages parameters are of type int and not >>> unsigned int? I'm able to change its types (these variables are >>> generated by macro which accepts type as one of its parameter) but I'm >>> not sure if it would be correct in all cases. >> Would someone from runtime want to comment on this? It seems ok to >> me. Changing to uintx would also be ok but it might require other >> uses to be converted to unsigned as well. I'd probably just leave it >> alone myself. >> >> tom >> >> >>> Cheers >>> Pavel >>> >>>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>>> >>>>> Hi all, >>>>> >>>>> can anybody please review two quite simple changes in JVM >>>>> initialization code? Webrev is available at: >>>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>>> >>>>> When -XX:StackShadowPages is set to negative integer or zero >>>>> value, JVM segfaulted on Linux and, according to >>>>> http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on >>>>> Solaris (although I only check this issue on Linux) >>>>> >>>>> I also would like to add more check for -XX:StackRedPages, >>>>> -XX:StackShadowPages and -XX:StackYellowPages options to avoid >>>>> issue described in the bug report mentioned above >>>>> (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to >>>>> find relevant information about proper conditions (it may depends >>>>> on page sizes, VM stack size etc.). Any ideas? >>>>> >>>>> Cheers >>>>> Pavel Tisnovsky >>>>> From coleen.phillimore at oracle.com Wed Aug 18 12:01:44 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Aug 2010 15:01:44 -0400 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6A44DC.1090703@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> Message-ID: <4C6C2E18.6020700@oracle.com> I don't know that much about this, but can you have the growable mapping check we have for the primordial thread only and an assert for the other threads, in case they get this growable mapping someday? David, are you going to make these changes? Thanks, Coleen On 08/17/10 04:14, Andrew Haley wrote: > On 08/16/2010 11:57 PM, David Holmes wrote: > >> Andrew Haley said the following on 08/16/10 18:42: >> >>> On 08/16/2010 03:46 AM, David Holmes wrote: >>> >>>> Looking further into this, isn't the only thread that can be affected by >>>> this the main thread? So we could perform this only if >>>> os::is_initial_thread() returns true? >>>> >>> I suppose we could, yes. I wonder if it'd be a latent bug to assume >>> that Java threads could never use growable mappings, though. Doing >>> this makes the system a bit less robust. >>> >> As I understand it neither LinuxThreads nor NPTL have used growable >> mappings for a very long time. Even if there were a reason to go back to >> this it would have to be done in a compatible way and so there would be >> time to "enhance" the VM to accommodate it. >> > > Oh, I'm sure there would. The problem is that this bug is very > subtle, and if it came back again it would be just as hard to > diagnose. If the change to use growable mappings were made upstream > on some platform, would we notice? > > >>> Do you really think that the cost of get_stack_bounds() is significant in >>> the context of terminating a thread? >>> >> It can be. This has introduced a new bottleneck on the thread >> termination path and we're seeing that affect on certain systems (the >> details of which I can't go in to). >> > > Aha, so this is not just a theoretical concern. Fair enough. It > seems like I may have falsely assumed the work in the kernel to > terminate a thread would be greater than this. > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100818/c5d10b1b/attachment.html From David.Holmes at oracle.com Wed Aug 18 16:26:54 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 19 Aug 2010 09:26:54 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6C2E18.6020700@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C2E18.6020700@oracle.com> Message-ID: <4C6C6C3E.3070406@oracle.com> Hi Coleen, Coleen Phillimore said the following on 08/19/10 05:01: > I don't know that much about this, but can you have the growable mapping > check we have for the primordial thread only and an assert for the other > threads, in case they get this growable mapping someday? Sure. > David, are you going to make these changes? Once we've validated the fix I'll see about getting it into OpenJDK David > Thanks, > Coleen > > On 08/17/10 04:14, Andrew Haley wrote: >> On 08/16/2010 11:57 PM, David Holmes wrote: >> >>> Andrew Haley said the following on 08/16/10 18:42: >>> >>>> On 08/16/2010 03:46 AM, David Holmes wrote: >>>> >>>>> Looking further into this, isn't the only thread that can be affected by >>>>> this the main thread? So we could perform this only if >>>>> os::is_initial_thread() returns true? >>>>> >>>> I suppose we could, yes. I wonder if it'd be a latent bug to assume >>>> that Java threads could never use growable mappings, though. Doing >>>> this makes the system a bit less robust. >>>> >>> As I understand it neither LinuxThreads nor NPTL have used growable >>> mappings for a very long time. Even if there were a reason to go back to >>> this it would have to be done in a compatible way and so there would be >>> time to "enhance" the VM to accommodate it. >>> >> >> Oh, I'm sure there would. The problem is that this bug is very >> subtle, and if it came back again it would be just as hard to >> diagnose. If the change to use growable mappings were made upstream >> on some platform, would we notice? >> >> >>>> Do you really think that the cost of get_stack_bounds() is significant in >>>> the context of terminating a thread? >>>> >>> It can be. This has introduced a new bottleneck on the thread >>> termination path and we're seeing that affect on certain systems (the >>> details of which I can't go in to). >>> >> >> Aha, so this is not just a theoretical concern. Fair enough. It >> seems like I may have falsely assumed the work in the kernel to >> terminate a thread would be greater than this. >> >> Andrew. >> > From David.Holmes at oracle.com Wed Aug 18 16:32:09 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 19 Aug 2010 09:32:09 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6C6C3E.3070406@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C2E18.6020700@oracle.com> <4C6C6C3E.3070406@oracle.com> Message-ID: <4C6C6D79.4050208@oracle.com> David Holmes said the following on 08/19/10 09:26: > Coleen Phillimore said the following on 08/19/10 05:01: > >> I don't know that much about this, but can you have the growable >> mapping check we have for the primordial thread only and an assert for >> the other threads, in case they get this growable mapping someday? > > Sure. Ooops! No. We're going to execute this logic only if in the initial thread, but it's still on the path for all threads. Do be able to assert we would need to be able to detect that the thread is using a growable stack but is not the main thread. If we had such a check then we would use it directly rather than querying if it is the initial thread. Hope that makes sense. David > >> David, are you going to make these changes? > > Once we've validated the fix I'll see about getting it into OpenJDK > > David > >> Thanks, >> Coleen >> >> On 08/17/10 04:14, Andrew Haley wrote: >>> On 08/16/2010 11:57 PM, David Holmes wrote: >>> >>>> Andrew Haley said the following on 08/16/10 18:42: >>>> >>>>> On 08/16/2010 03:46 AM, David Holmes wrote: >>>>> >>>>>> Looking further into this, isn't the only thread that can be >>>>>> affected by >>>>>> this the main thread? So we could perform this only if >>>>>> os::is_initial_thread() returns true? >>>>>> >>>>> I suppose we could, yes. I wonder if it'd be a latent bug to assume >>>>> that Java threads could never use growable mappings, though. Doing >>>>> this makes the system a bit less robust. >>>>> >>>> As I understand it neither LinuxThreads nor NPTL have used growable >>>> mappings for a very long time. Even if there were a reason to go >>>> back to >>>> this it would have to be done in a compatible way and so there would be >>>> time to "enhance" the VM to accommodate it. >>>> >>> >>> Oh, I'm sure there would. The problem is that this bug is very >>> subtle, and if it came back again it would be just as hard to >>> diagnose. If the change to use growable mappings were made upstream >>> on some platform, would we notice? >>> >>> >>>>> Do you really think that the cost of get_stack_bounds() is >>>>> significant in >>>>> the context of terminating a thread? >>>>> >>>> It can be. This has introduced a new bottleneck on the thread >>>> termination path and we're seeing that affect on certain systems (the >>>> details of which I can't go in to). >>>> >>> >>> Aha, so this is not just a theoretical concern. Fair enough. It >>> seems like I may have falsely assumed the work in the kernel to >>> terminate a thread would be greater than this. >>> >>> Andrew. >>> >> From David.Holmes at oracle.com Wed Aug 18 16:41:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 19 Aug 2010 09:41:51 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6A44DC.1090703@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> Message-ID: <4C6C6FBF.3080504@oracle.com> Andrew Haley said the following on 08/17/10 18:14: > On 08/16/2010 11:57 PM, David Holmes wrote: >> Andrew Haley said the following on 08/16/10 18:42: >>> On 08/16/2010 03:46 AM, David Holmes wrote: >>>> Looking further into this, isn't the only thread that can be affected by >>>> this the main thread? So we could perform this only if >>>> os::is_initial_thread() returns true? >>> I suppose we could, yes. I wonder if it'd be a latent bug to assume >>> that Java threads could never use growable mappings, though. Doing >>> this makes the system a bit less robust. >> As I understand it neither LinuxThreads nor NPTL have used growable >> mappings for a very long time. Even if there were a reason to go back to >> this it would have to be done in a compatible way and so there would be >> time to "enhance" the VM to accommodate it. > > Oh, I'm sure there would. The problem is that this bug is very > subtle, and if it came back again it would be just as hard to > diagnose. If the change to use growable mappings were made upstream > on some platform, would we notice? I would hope (and I know hopes can be dashed) that the upstream maintainers would not make such a change silently. Was there a regression test created for this bug? That would catch any change. David ----- >>> Do you really think that the cost of get_stack_bounds() is significant in >>> the context of terminating a thread? >> It can be. This has introduced a new bottleneck on the thread >> termination path and we're seeing that affect on certain systems (the >> details of which I can't go in to). > > Aha, so this is not just a theoretical concern. Fair enough. It > seems like I may have falsely assumed the work in the kernel to > terminate a thread would be greater than this. > > Andrew. From erik.trimble at oracle.com Wed Aug 18 18:30:32 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 19 Aug 2010 01:30:32 +0000 Subject: hg: jdk7/hotspot/hotspot: 13 new changesets Message-ID: <20100819013100.401154729D@hg.openjdk.java.net> Changeset: cb4250ef73b2 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cb4250ef73b2 Added tag jdk7-b102 for changeset c5cadf1a0771 ! .hgtags Changeset: efd4401fab1d Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/efd4401fab1d Added tag jdk7-b103 for changeset cb4250ef73b2 ! .hgtags Changeset: cc3fdfeb54b0 Author: trims Date: 2010-07-29 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cc3fdfeb54b0 Merge Changeset: fd2645290e89 Author: trims Date: 2010-07-30 06:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fd2645290e89 6973381: Bump the HS19 build number to 05 Summary: Update the HS19 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 28abe3f6a5f6 Author: trims Date: 2010-08-03 19:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/28abe3f6a5f6 Merge Changeset: b4acf10eb134 Author: trims Date: 2010-08-05 02:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b4acf10eb134 Added tag hs19-b04 for changeset e55900b5c1b8 ! .hgtags Changeset: 6709c14587c2 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6709c14587c2 Added tag jdk7-b104 for changeset b4acf10eb134 ! .hgtags Changeset: 3dc64719cf18 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3dc64719cf18 Added tag jdk7-b105 for changeset 6709c14587c2 ! .hgtags Changeset: 688a538aa654 Author: trims Date: 2010-08-13 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/688a538aa654 Merge Changeset: 5f3c8db59d83 Author: trims Date: 2010-08-13 10:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5f3c8db59d83 6977051: Bump the HS19 build number to 06 Summary: Update the HS19 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1b81ca701fa5 Author: trims Date: 2010-08-17 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1b81ca701fa5 Merge Changeset: f121b2772674 Author: trims Date: 2010-08-18 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f121b2772674 Merge - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp Changeset: 495caa35b1b5 Author: asaha Date: 2010-08-17 22:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/495caa35b1b5 6977952: Test: Sync missing tests from hs16.3 to hs17.x Reviewed-by: wrockett + test/compiler/6894807/IsInstanceTest.java + test/compiler/6894807/Test6894807.sh + test/runtime/6626217/IFace.java + test/runtime/6626217/Loader2.java + test/runtime/6626217/Test6626217.sh + test/runtime/6626217/You_Have_Been_P0wned.java + test/runtime/6626217/bug_21227.java + test/runtime/6626217/from_loader2.java + test/runtime/6626217/many_loader1.java.foo + test/runtime/6626217/many_loader2.java.foo From David.Holmes at oracle.com Wed Aug 18 20:49:36 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 19 Aug 2010 13:49:36 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6C6FBF.3080504@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> Message-ID: <4C6CA9D0.3010904@oracle.com> Here's the prototype including the safety-check Coleen wanted. diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp +++ b/src/os/linux/vm/os_linux.cpp @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint // where we're going to put our guard pages, truncate the mapping at // that point by munmap()ping it. This ensures that when we later // munmap() the guard pages we don't leave a hole in the stack -// mapping. +// mapping. This only affects the main/initial thread, but guard +// against future OS changes bool os::create_stack_guard_pages(char* addr, size_t size) { uintptr_t stack_extent, stack_base; - if (get_stack_bounds(&stack_extent, &stack_base)) { + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); if (stack_extent < (uintptr_t)addr) ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); } @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* } // If this is a growable mapping, remove the guard pages entirely by -// munmap()ping them. If not, just call uncommit_memory(). +// munmap()ping them. If not, just call uncommit_memory(). This only +// affects the main/initial thread, but guard against future OS changes bool os::remove_stack_guard_pages(char* addr, size_t size) { uintptr_t stack_extent, stack_base; - if (get_stack_bounds(&stack_extent, &stack_base)) { + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); + return ::munmap(addr, size) == 0; } We skip get_stack_bounds for all but the main thread in product mode; then in debug mode we always call get_stack_bounds but trigger an assert of we seem to find a growable stack that does not belong to the main thread. This fixes our performance issue, but otherwise has not been fully tested. David ----- David Holmes said the following on 08/19/10 09:41: > Andrew Haley said the following on 08/17/10 18:14: >> On 08/16/2010 11:57 PM, David Holmes wrote: >>> Andrew Haley said the following on 08/16/10 18:42: >>>> On 08/16/2010 03:46 AM, David Holmes wrote: >>>>> Looking further into this, isn't the only thread that can be >>>>> affected by >>>>> this the main thread? So we could perform this only if >>>>> os::is_initial_thread() returns true? >>>> I suppose we could, yes. I wonder if it'd be a latent bug to assume >>>> that Java threads could never use growable mappings, though. Doing >>>> this makes the system a bit less robust. >>> As I understand it neither LinuxThreads nor NPTL have used growable >>> mappings for a very long time. Even if there were a reason to go back to >>> this it would have to be done in a compatible way and so there would be >>> time to "enhance" the VM to accommodate it. >> >> Oh, I'm sure there would. The problem is that this bug is very >> subtle, and if it came back again it would be just as hard to >> diagnose. If the change to use growable mappings were made upstream >> on some platform, would we notice? > > I would hope (and I know hopes can be dashed) that the upstream > maintainers would not make such a change silently. > > Was there a regression test created for this bug? That would catch any > change. > > David > ----- > >>>> Do you really think that the cost of get_stack_bounds() is >>>> significant in >>>> the context of terminating a thread? >>> It can be. This has introduced a new bottleneck on the thread >>> termination path and we're seeing that affect on certain systems (the >>> details of which I can't go in to). >> >> Aha, so this is not just a theoretical concern. Fair enough. It >> seems like I may have falsely assumed the work in the kernel to >> terminate a thread would be greater than this. >> >> Andrew. From aph at redhat.com Thu Aug 19 01:33:14 2010 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Aug 2010 09:33:14 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6C6FBF.3080504@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> Message-ID: <4C6CEC4A.9090407@redhat.com> On 08/19/2010 12:41 AM, David Holmes wrote: > Andrew Haley said the following on 08/17/10 18:14: >> On 08/16/2010 11:57 PM, David Holmes wrote: >>> Andrew Haley said the following on 08/16/10 18:42: >>>> On 08/16/2010 03:46 AM, David Holmes wrote: >>>>> Looking further into this, isn't the only thread that can be >>>>> affected by >>>>> this the main thread? So we could perform this only if >>>>> os::is_initial_thread() returns true? >>>> I suppose we could, yes. I wonder if it'd be a latent bug to assume >>>> that Java threads could never use growable mappings, though. Doing >>>> this makes the system a bit less robust. >>> As I understand it neither LinuxThreads nor NPTL have used growable >>> mappings for a very long time. Even if there were a reason to go back to >>> this it would have to be done in a compatible way and so there would be >>> time to "enhance" the VM to accommodate it. >> >> Oh, I'm sure there would. The problem is that this bug is very >> subtle, and if it came back again it would be just as hard to >> diagnose. If the change to use growable mappings were made upstream >> on some platform, would we notice? > > I would hope (and I know hopes can be dashed) that the upstream > maintainers would not make such a change silently. > > Was there a regression test created for this bug? That would catch any > change. Yes there was, and it was attached to the very first message in this thread. It was never checked in to the source tree, though, and I'm not sure it's in a suitable form for the regression test suite. Andrew. From ptisnovs at redhat.com Thu Aug 19 05:43:10 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Thu, 19 Aug 2010 14:43:10 +0200 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C6AEE64.7050207@oracle.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> <4C6AEAD0.8030206@oracle.com> <4C6AEE64.7050207@oracle.com> Message-ID: <4C6D26DE.4060107@redhat.com> Hi Coleen and Paul, here are new versions of the patch: for OpenJDK6: http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK6/ and for OpenJDK7 too: http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK7/ (the change itself is the same for both OpenJDKs, but line numbers are different) > I will push it through JPRT does it mean that I need not do the push myself? Thank you for your help Pavel Coleen Phillimore wrote: > Yes, I agree they should stay intx. Thank you for the change. It looks > fine to me. If you update the patch, I will push it through JPRT. Let > me know when it is ready. > thanks, > Coleen > > Paul Hohensee wrote: >> Leave them as intx, imo. Their high bound value isn't anywhere near >> maxint, >> and if you change them to uintx you'll have to cast them to intx for the >> calls to verify_min_value. Plus there's some places where their >> values are >> assigned to ints that would have to be changed. >> >> Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. >> >> Paul >> >> On 8/17/10 3:50 PM, Tom Rodriguez wrote: >>> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: >>> >>>> Tom Rodriguez wrote: >>>>> I think you could put this check into arguments.cpp since I all >>>>> platforms would require a positive number for the >>>>> StackShadowPages. The same should be true of StackRedPages and >>>>> StackYellowPages. Actually they all should be required to greater >>>>> than 0 I think. Other than that I don't see other obvious >>>>> constraints on the values. That bug report doesn't really show >>>>> other problematic values, though I'm not sure I follow the point of >>>>> the guarantee that's failing either. What does the min stack size >>>>> have to do with the number of guard pages? I would expect it to be >>>>> checking against ThreadStackSize and returning an error if it was >>>>> too small like the other places that check against TheadStackSize. >>>>> >>>>> tom >>>> Hi Tom, >>>> >>>> I've added check for all Stack*Pages parameters to arguments.cpp. Can >>>> you please review the changes? >>>> >>>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >>>> >>>> Is there any reason why Stack*Pages parameters are of type int and not >>>> unsigned int? I'm able to change its types (these variables are >>>> generated by macro which accepts type as one of its parameter) but I'm >>>> not sure if it would be correct in all cases. >>> Would someone from runtime want to comment on this? It seems ok to >>> me. Changing to uintx would also be ok but it might require other >>> uses to be converted to unsigned as well. I'd probably just leave it >>> alone myself. >>> >>> tom >>> >>> >>>> Cheers >>>> Pavel >>>> >>>>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> can anybody please review two quite simple changes in JVM >>>>>> initialization code? Webrev is available at: >>>>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>>>> >>>>>> When -XX:StackShadowPages is set to negative integer or zero >>>>>> value, JVM segfaulted on Linux and, according to >>>>>> http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on >>>>>> Solaris (although I only check this issue on Linux) >>>>>> >>>>>> I also would like to add more check for -XX:StackRedPages, >>>>>> -XX:StackShadowPages and -XX:StackYellowPages options to avoid >>>>>> issue described in the bug report mentioned above >>>>>> (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to >>>>>> find relevant information about proper conditions (it may depends >>>>>> on page sizes, VM stack size etc.). Any ideas? >>>>>> >>>>>> Cheers >>>>>> Pavel Tisnovsky >>>>>> From David.Holmes at oracle.com Thu Aug 19 06:31:08 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 19 Aug 2010 23:31:08 +1000 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C6D26DE.4060107@redhat.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> <4C6AEAD0.8030206@oracle.com> <4C6AEE64.7050207@oracle.com> <4C6D26DE.4060107@redhat.com> Message-ID: <4C6D321C.9060103@oracle.com> Pavel Tisnovsky said the following on 08/19/10 22:43: >> I will push it through JPRT > does it mean that I need not do the push myself? Correct - you must not push directly - all hotspot pushes go via JPRT. Cheers, David Holmes > Thank you for your help > Pavel > > Coleen Phillimore wrote: >> Yes, I agree they should stay intx. Thank you for the change. It looks >> fine to me. If you update the patch, I will push it through JPRT. Let >> me know when it is ready. >> thanks, >> Coleen >> >> Paul Hohensee wrote: >>> Leave them as intx, imo. Their high bound value isn't anywhere near >>> maxint, >>> and if you change them to uintx you'll have to cast them to intx for the >>> calls to verify_min_value. Plus there's some places where their >>> values are >>> assigned to ints that would have to be changed. >>> >>> Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. >>> >>> Paul >>> >>> On 8/17/10 3:50 PM, Tom Rodriguez wrote: >>>> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: >>>> >>>>> Tom Rodriguez wrote: >>>>>> I think you could put this check into arguments.cpp since I all >>>>>> platforms would require a positive number for the >>>>>> StackShadowPages. The same should be true of StackRedPages and >>>>>> StackYellowPages. Actually they all should be required to greater >>>>>> than 0 I think. Other than that I don't see other obvious >>>>>> constraints on the values. That bug report doesn't really show >>>>>> other problematic values, though I'm not sure I follow the point of >>>>>> the guarantee that's failing either. What does the min stack size >>>>>> have to do with the number of guard pages? I would expect it to be >>>>>> checking against ThreadStackSize and returning an error if it was >>>>>> too small like the other places that check against TheadStackSize. >>>>>> >>>>>> tom >>>>> Hi Tom, >>>>> >>>>> I've added check for all Stack*Pages parameters to arguments.cpp. Can >>>>> you please review the changes? >>>>> >>>>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >>>>> >>>>> Is there any reason why Stack*Pages parameters are of type int and not >>>>> unsigned int? I'm able to change its types (these variables are >>>>> generated by macro which accepts type as one of its parameter) but I'm >>>>> not sure if it would be correct in all cases. >>>> Would someone from runtime want to comment on this? It seems ok to >>>> me. Changing to uintx would also be ok but it might require other >>>> uses to be converted to unsigned as well. I'd probably just leave it >>>> alone myself. >>>> >>>> tom >>>> >>>> >>>>> Cheers >>>>> Pavel >>>>> >>>>>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> can anybody please review two quite simple changes in JVM >>>>>>> initialization code? Webrev is available at: >>>>>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>>>>> >>>>>>> When -XX:StackShadowPages is set to negative integer or zero >>>>>>> value, JVM segfaulted on Linux and, according to >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on >>>>>>> Solaris (although I only check this issue on Linux) >>>>>>> >>>>>>> I also would like to add more check for -XX:StackRedPages, >>>>>>> -XX:StackShadowPages and -XX:StackYellowPages options to avoid >>>>>>> issue described in the bug report mentioned above >>>>>>> (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to >>>>>>> find relevant information about proper conditions (it may depends >>>>>>> on page sizes, VM stack size etc.). Any ideas? >>>>>>> >>>>>>> Cheers >>>>>>> Pavel Tisnovsky >>>>>>> > From paul.hohensee at oracle.com Thu Aug 19 08:24:47 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Aug 2010 11:24:47 -0400 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C6D26DE.4060107@redhat.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> <4C6AEAD0.8030206@oracle.com> <4C6AEE64.7050207@oracle.com> <4C6D26DE.4060107@redhat.com> Message-ID: <4C6D4CBF.2000905@oracle.com> You still should cast the first argument to verify_min_value in check_stack_pages to intx, vis // Check stack pages settings bool Arguments::check_stack_pages() { bool status = true; status = status&& verify_min_value((intx)StackYellowPages, 1, "StackYellowPages"); status = status&& verify_min_value((intx)StackRedPages, 1, "StackRedPages"); status = status&& verify_min_value((intx)StackShadowPages, 1, "StackShadowPages"); return status; } lest some versions of gcc reject the code because of the implicit unsigned -> signed conversion. Paul On 8/19/10 8:43 AM, Pavel Tisnovsky wrote: > Hi Coleen and Paul, > > here are new versions of the patch: > > for OpenJDK6: > http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK6/ > > and for OpenJDK7 too: > http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK7/ > > (the change itself is the same for both OpenJDKs, but line numbers are > different) > >> I will push it through JPRT > does it mean that I need not do the push myself? > > Thank you for your help > Pavel > > Coleen Phillimore wrote: >> Yes, I agree they should stay intx. Thank you for the change. It looks >> fine to me. If you update the patch, I will push it through JPRT. Let >> me know when it is ready. >> thanks, >> Coleen >> >> Paul Hohensee wrote: >>> Leave them as intx, imo. Their high bound value isn't anywhere near >>> maxint, >>> and if you change them to uintx you'll have to cast them to intx for the >>> calls to verify_min_value. Plus there's some places where their >>> values are >>> assigned to ints that would have to be changed. >>> >>> Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. >>> >>> Paul >>> >>> On 8/17/10 3:50 PM, Tom Rodriguez wrote: >>>> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: >>>> >>>>> Tom Rodriguez wrote: >>>>>> I think you could put this check into arguments.cpp since I all >>>>>> platforms would require a positive number for the >>>>>> StackShadowPages. The same should be true of StackRedPages and >>>>>> StackYellowPages. Actually they all should be required to greater >>>>>> than 0 I think. Other than that I don't see other obvious >>>>>> constraints on the values. That bug report doesn't really show >>>>>> other problematic values, though I'm not sure I follow the point of >>>>>> the guarantee that's failing either. What does the min stack size >>>>>> have to do with the number of guard pages? I would expect it to be >>>>>> checking against ThreadStackSize and returning an error if it was >>>>>> too small like the other places that check against TheadStackSize. >>>>>> >>>>>> tom >>>>> Hi Tom, >>>>> >>>>> I've added check for all Stack*Pages parameters to arguments.cpp. Can >>>>> you please review the changes? >>>>> >>>>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >>>>> >>>>> Is there any reason why Stack*Pages parameters are of type int and not >>>>> unsigned int? I'm able to change its types (these variables are >>>>> generated by macro which accepts type as one of its parameter) but I'm >>>>> not sure if it would be correct in all cases. >>>> Would someone from runtime want to comment on this? It seems ok to >>>> me. Changing to uintx would also be ok but it might require other >>>> uses to be converted to unsigned as well. I'd probably just leave it >>>> alone myself. >>>> >>>> tom >>>> >>>> >>>>> Cheers >>>>> Pavel >>>>> >>>>>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> can anybody please review two quite simple changes in JVM >>>>>>> initialization code? Webrev is available at: >>>>>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>>>>> >>>>>>> When -XX:StackShadowPages is set to negative integer or zero >>>>>>> value, JVM segfaulted on Linux and, according to >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on >>>>>>> Solaris (although I only check this issue on Linux) >>>>>>> >>>>>>> I also would like to add more check for -XX:StackRedPages, >>>>>>> -XX:StackShadowPages and -XX:StackYellowPages options to avoid >>>>>>> issue described in the bug report mentioned above >>>>>>> (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to >>>>>>> find relevant information about proper conditions (it may depends >>>>>>> on page sizes, VM stack size etc.). Any ideas? >>>>>>> >>>>>>> Cheers >>>>>>> Pavel Tisnovsky >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100819/0ab5cbbc/attachment.html From ptisnovs at redhat.com Thu Aug 19 09:01:33 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Thu, 19 Aug 2010 18:01:33 +0200 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C6D4CBF.2000905@oracle.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> <4C6AEAD0.8030206@oracle.com> <4C6AEE64.7050207@oracle.com> <4C6D26DE.4060107@redhat.com> <4C6D4CBF.2000905@oracle.com> Message-ID: <4C6D555D.2010703@redhat.com> Hi Paul and Coleen, there are another webrevs for both OpenJDKs: http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK6_v2/ http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK7_v2/ To tell the truth I don't understand why the cast is necessary because StackYellowPages etc. are declared as intx type in globals.hpp. Maybe I have missed something important. Paul Hohensee wrote: > You still should cast the first argument to verify_min_value in > check_stack_pages > to intx, vis > > // Check stack pages settings > bool Arguments::check_stack_pages() > { > bool status = true; > status = status && verify_min_value((intx)StackYellowPages, 1, "StackYellowPages"); > status = status && verify_min_value((intx)StackRedPages, 1, "StackRedPages"); > status = status && verify_min_value((intx)StackShadowPages, 1, "StackShadowPages"); > return status; > } > > lest some versions of gcc reject the code because of the implicit > unsigned -> signed > conversion. > > Paul > > On 8/19/10 8:43 AM, Pavel Tisnovsky wrote: >> Hi Coleen and Paul, >> >> here are new versions of the patch: >> >> for OpenJDK6: >> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK6/ >> >> and for OpenJDK7 too: >> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK7/ >> >> (the change itself is the same for both OpenJDKs, but line numbers are >> different) >> >>> I will push it through JPRT >> does it mean that I need not do the push myself? >> >> Thank you for your help >> Pavel >> >> Coleen Phillimore wrote: >>> Yes, I agree they should stay intx. Thank you for the change. It looks >>> fine to me. If you update the patch, I will push it through JPRT. Let >>> me know when it is ready. >>> thanks, >>> Coleen >>> >>> Paul Hohensee wrote: >>>> Leave them as intx, imo. Their high bound value isn't anywhere near >>>> maxint, >>>> and if you change them to uintx you'll have to cast them to intx for the >>>> calls to verify_min_value. Plus there's some places where their >>>> values are >>>> assigned to ints that would have to be changed. >>>> >>>> Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. >>>> >>>> Paul >>>> >>>> On 8/17/10 3:50 PM, Tom Rodriguez wrote: >>>>> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: >>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> I think you could put this check into arguments.cpp since I all >>>>>>> platforms would require a positive number for the >>>>>>> StackShadowPages. The same should be true of StackRedPages and >>>>>>> StackYellowPages. Actually they all should be required to greater >>>>>>> than 0 I think. Other than that I don't see other obvious >>>>>>> constraints on the values. That bug report doesn't really show >>>>>>> other problematic values, though I'm not sure I follow the point of >>>>>>> the guarantee that's failing either. What does the min stack size >>>>>>> have to do with the number of guard pages? I would expect it to be >>>>>>> checking against ThreadStackSize and returning an error if it was >>>>>>> too small like the other places that check against TheadStackSize. >>>>>>> >>>>>>> tom >>>>>> Hi Tom, >>>>>> >>>>>> I've added check for all Stack*Pages parameters to arguments.cpp. Can >>>>>> you please review the changes? >>>>>> >>>>>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >>>>>> >>>>>> Is there any reason why Stack*Pages parameters are of type int and not >>>>>> unsigned int? I'm able to change its types (these variables are >>>>>> generated by macro which accepts type as one of its parameter) but I'm >>>>>> not sure if it would be correct in all cases. >>>>> Would someone from runtime want to comment on this? It seems ok to >>>>> me. Changing to uintx would also be ok but it might require other >>>>> uses to be converted to unsigned as well. I'd probably just leave it >>>>> alone myself. >>>>> >>>>> tom >>>>> >>>>> >>>>>> Cheers >>>>>> Pavel >>>>>> >>>>>>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> can anybody please review two quite simple changes in JVM >>>>>>>> initialization code? Webrev is available at: >>>>>>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>>>>>> >>>>>>>> When -XX:StackShadowPages is set to negative integer or zero >>>>>>>> value, JVM segfaulted on Linux and, according to >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on >>>>>>>> Solaris (although I only check this issue on Linux) >>>>>>>> >>>>>>>> I also would like to add more check for -XX:StackRedPages, >>>>>>>> -XX:StackShadowPages and -XX:StackYellowPages options to avoid >>>>>>>> issue described in the bug report mentioned above >>>>>>>> (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to >>>>>>>> find relevant information about proper conditions (it may depends >>>>>>>> on page sizes, VM stack size etc.). Any ideas? >>>>>>>> >>>>>>>> Cheers >>>>>>>> Pavel Tisnovsky >>>>>>>> From paul.hohensee at ORACLE.COM Thu Aug 19 09:14:36 2010 From: paul.hohensee at ORACLE.COM (Paul Hohensee) Date: Thu, 19 Aug 2010 12:14:36 -0400 Subject: Need reviewers for changes in JVM initialization code (added check for -XX:StackShadowPages option) In-Reply-To: <4C6D555D.2010703@redhat.com> References: <4C4EF827.6060309@redhat.com> <46AF904F-F89F-43A9-B5CE-6DA6E9C95B2A@oracle.com> <4C5C16C0.4070301@redhat.com> <73651916-25F2-4BFC-96C8-8B1903A58A70@oracle.com> <4C6AEAD0.8030206@oracle.com> <4C6AEE64.7050207@oracle.com> <4C6D26DE.4060107@redhat.com> <4C6D4CBF.2000905@oracle.com> <4C6D555D.2010703@redhat.com> Message-ID: <4C6D586C.2000305@oracle.com> Whoops, my bad. I was thinking of the old version where StackXXXPagesCheck was declared uintx. Paul On 8/19/10 12:01 PM, Pavel Tisnovsky wrote: > Hi Paul and Coleen, > > there are another webrevs for both OpenJDKs: > http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK6_v2/ > http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK7_v2/ > > To tell the truth I don't understand why the cast is necessary because > StackYellowPages etc. are declared as intx type in globals.hpp. Maybe I > have missed something important. > > Paul Hohensee wrote: >> You still should cast the first argument to verify_min_value in >> check_stack_pages >> to intx, vis >> >> // Check stack pages settings >> bool Arguments::check_stack_pages() >> { >> bool status = true; >> status = status&& verify_min_value((intx)StackYellowPages, 1, "StackYellowPages"); >> status = status&& verify_min_value((intx)StackRedPages, 1, "StackRedPages"); >> status = status&& verify_min_value((intx)StackShadowPages, 1, "StackShadowPages"); >> return status; >> } >> >> lest some versions of gcc reject the code because of the implicit >> unsigned -> signed >> conversion. >> >> Paul >> >> On 8/19/10 8:43 AM, Pavel Tisnovsky wrote: >>> Hi Coleen and Paul, >>> >>> here are new versions of the patch: >>> >>> for OpenJDK6: >>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK6/ >>> >>> and for OpenJDK7 too: >>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck_OpenJDK7/ >>> >>> (the change itself is the same for both OpenJDKs, but line numbers are >>> different) >>> >>>> I will push it through JPRT >>> does it mean that I need not do the push myself? >>> >>> Thank you for your help >>> Pavel >>> >>> Coleen Phillimore wrote: >>>> Yes, I agree they should stay intx. Thank you for the change. It looks >>>> fine to me. If you update the patch, I will push it through JPRT. Let >>>> me know when it is ready. >>>> thanks, >>>> Coleen >>>> >>>> Paul Hohensee wrote: >>>>> Leave them as intx, imo. Their high bound value isn't anywhere near >>>>> maxint, >>>>> and if you change them to uintx you'll have to cast them to intx for the >>>>> calls to verify_min_value. Plus there's some places where their >>>>> values are >>>>> assigned to ints that would have to be changed. >>>>> >>>>> Also, pls use INTX_FORMAT instead of UINTX_FORMAT in verify_min_value. >>>>> >>>>> Paul >>>>> >>>>> On 8/17/10 3:50 PM, Tom Rodriguez wrote: >>>>>> On Aug 6, 2010, at 7:05 AM, Pavel Tisnovsky wrote: >>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> I think you could put this check into arguments.cpp since I all >>>>>>>> platforms would require a positive number for the >>>>>>>> StackShadowPages. The same should be true of StackRedPages and >>>>>>>> StackYellowPages. Actually they all should be required to greater >>>>>>>> than 0 I think. Other than that I don't see other obvious >>>>>>>> constraints on the values. That bug report doesn't really show >>>>>>>> other problematic values, though I'm not sure I follow the point of >>>>>>>> the guarantee that's failing either. What does the min stack size >>>>>>>> have to do with the number of guard pages? I would expect it to be >>>>>>>> checking against ThreadStackSize and returning an error if it was >>>>>>>> too small like the other places that check against TheadStackSize. >>>>>>>> >>>>>>>> tom >>>>>>> Hi Tom, >>>>>>> >>>>>>> I've added check for all Stack*Pages parameters to arguments.cpp. Can >>>>>>> you please review the changes? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ptisnovs/StackXXXPagesCheck/ >>>>>>> >>>>>>> Is there any reason why Stack*Pages parameters are of type int and not >>>>>>> unsigned int? I'm able to change its types (these variables are >>>>>>> generated by macro which accepts type as one of its parameter) but I'm >>>>>>> not sure if it would be correct in all cases. >>>>>> Would someone from runtime want to comment on this? It seems ok to >>>>>> me. Changing to uintx would also be ok but it might require other >>>>>> uses to be converted to unsigned as well. I'd probably just leave it >>>>>> alone myself. >>>>>> >>>>>> tom >>>>>> >>>>>> >>>>>>> Cheers >>>>>>> Pavel >>>>>>> >>>>>>>> On Jul 27, 2010, at 8:15 AM, Pavel Tisnovsky wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> can anybody please review two quite simple changes in JVM >>>>>>>>> initialization code? Webrev is available at: >>>>>>>>> http://cr.openjdk.java.net/~ptisnovs/StackShadowPagesCheck/ >>>>>>>>> >>>>>>>>> When -XX:StackShadowPages is set to negative integer or zero >>>>>>>>> value, JVM segfaulted on Linux and, according to >>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=6885308, hangs up on >>>>>>>>> Solaris (although I only check this issue on Linux) >>>>>>>>> >>>>>>>>> I also would like to add more check for -XX:StackRedPages, >>>>>>>>> -XX:StackShadowPages and -XX:StackYellowPages options to avoid >>>>>>>>> issue described in the bug report mentioned above >>>>>>>>> (http://bugs.sun.com/view_bug.do?bug_id=6885308) but I'm unable to >>>>>>>>> find relevant information about proper conditions (it may depends >>>>>>>>> on page sizes, VM stack size etc.). Any ideas? >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Pavel Tisnovsky >>>>>>>>> From idealistyy at gmail.com Thu Aug 19 09:43:22 2010 From: idealistyy at gmail.com (Yi Yang) Date: Thu, 19 Aug 2010 09:43:22 -0700 Subject: How to load applet bytecode to HotSpot VM Message-ID: Hello everyone, I have a question about HotSpot VM. Thanks for your attention in advance. My object is to load applet bytecode (applet.class) to HotSpot VM and then record the methods invoked by the applet. However, I have no idea how to load the applet bytecode. For example, I can use the command "gamma testClass" to load the file "testClass.class". But how about the applet bytecode without a main entry point? If I use "gamma applet", then here is the error message: Exception in thread "main" java.lang.NoSuchMethodError: main Could you please give me some hints?Hope to hearing from you soon. Thank you. Best, Yi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100819/e9545702/attachment.html From john.pampuch at oracle.com Thu Aug 19 09:54:11 2010 From: john.pampuch at oracle.com (John Pampuch) Date: Thu, 19 Aug 2010 09:54:11 -0700 Subject: How to load applet bytecode to HotSpot VM In-Reply-To: References: Message-ID: <4C6D61B3.5020406@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100819/db017056/attachment.html From idealistyy at gmail.com Thu Aug 19 10:53:16 2010 From: idealistyy at gmail.com (Yi Yang) Date: Thu, 19 Aug 2010 10:53:16 -0700 Subject: How to load applet bytecode to HotSpot VM In-Reply-To: <4C6D61B3.5020406@oracle.com> References: <4C6D61B3.5020406@oracle.com> Message-ID: Hello John, Thanks for your reply. Sure. I can use appletviewer to test the applet. However, my object is not this. I want to add a small code snippet to the HotSpot VM so that it can print out the methods invoked information when an applet is running. I think the appletviewer is linked with the HotSpot under jdk7 directory. How can I link the appletviewer to "my" HotSpot project? Does it mean I need to directly change the HotSpot code under jdk7 directory? Thank you very much. Best, Yi 2010/8/19 John Pampuch > You'll need to use "appletviewer", which is included in the JDK (in the > bin directory) in order to run an applet outside of the context of a web > browser. > > -John > > On 8/19/10 9:43 AM, Yi Yang wrote: > > Hello everyone, > > I have a question about HotSpot VM. Thanks for your attention in advance. > > My object is to load applet bytecode (applet.class) to HotSpot VM and then > record the methods invoked by the applet. However, I have no idea how to > load the applet bytecode. For example, I can use the command "gamma > testClass" to load the file "testClass.class". But how about the applet > bytecode without a main entry point? If I use "gamma applet", then here is > the error message: Exception in thread "main" java.lang.NoSuchMethodError: > main > > Could you please give me some hints?Hope to hearing from you soon. Thank > you. > > Best, > Yi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100819/e68a81b3/attachment.html From David.Holmes at oracle.com Thu Aug 19 15:45:23 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 20 Aug 2010 08:45:23 +1000 Subject: How to load applet bytecode to HotSpot VM In-Reply-To: References: <4C6D61B3.5020406@oracle.com> Message-ID: <4C6DB403.8030805@oracle.com> The appletviewer is just a command that runs the JVM using a special class as the main application (AppletContext?) - that class knows how to load and execute applets. Hotspot can't tell that it is running an applet - it is all just Java bytecode - some belonging to the libraries that enable you to run the applet and some to the applet itself. If you wanted to know when the applet was running then you could add instrumentation hooks into the VM and then turn them on from Java code by modifying the AppletContext so that it turns the hooks on/off around the calls to the Applet control methods (eg start(), stop()). But it all depends on what methods you are interested in. It might pay to start by looking at how the applet viewer works. David Holmes Yi Yang said the following on 08/20/10 03:53: > Hello John, > > Thanks for your reply. Sure. I can use appletviewer to test the applet. > However, my object is not this. I want to add a small code snippet to > the HotSpot VM so that it can print out the methods invoked information > when an applet is running. I think the appletviewer is linked with the > HotSpot under jdk7 directory. How can I link the appletviewer to "my" > HotSpot project? Does it mean I need to directly change the HotSpot code > under jdk7 directory? Thank you very much. > > Best, > Yi > > > 2010/8/19 John Pampuch > > > You'll need to use "appletviewer", which is included in the JDK (in > the bin directory) in order to run an applet outside of the context > of a web browser. > > -John > > On 8/19/10 9:43 AM, Yi Yang wrote: >> Hello everyone, >> >> I have a question about HotSpot VM. Thanks for your attention in >> advance. >> >> My object is to load applet bytecode (applet.class) to HotSpot VM >> and then record the methods invoked by the applet. However, I have >> no idea how to load the applet bytecode. For example, I can use >> the command "gamma testClass" to load the file "testClass.class". >> But how about the applet bytecode without a main entry point? If I >> use "gamma applet", then here is the error message: Exception in >> thread "main" java.lang.NoSuchMethodError: main >> >> Could you please give me some hints?Hope to hearing from you soon. >> Thank you. >> >> Best, >> Yi > > From tony.printezis at oracle.com Thu Aug 19 16:13:09 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Thu, 19 Aug 2010 23:13:09 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20100819231324.F37F9472D1@hg.openjdk.java.net> Changeset: be3f9c242c9d Author: ysr Date: 2010-08-16 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/be3f9c242c9d 6948538: CMS: BOT walkers can fall into object allocation and initialization cracks Summary: GC workers now recognize an intermediate transient state of blocks which are allocated but have not yet completed initialization. blk_start() calls do not attempt to determine the size of a block in the transient state, rather waiting for the block to become initialized so that it is safe to query its size. Audited and ensured the order of initialization of object fields (klass, free bit and size) to respect block state transition protocol. Also included some new assertion checking code enabled in debug mode. Reviewed-by: chrisphi, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/includeDB_core ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/blockOffsetTable.inline.hpp ! src/share/vm/runtime/globals.hpp Changeset: 688c3755d7af Author: tonyp Date: 2010-08-17 14:40 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/688c3755d7af 6959014: G1: assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check Summary: There are a few issues in the code that calculates whether to resize the heap and by how much: a) some calculations can overflow 32-bit size_t's, b) min_desired_capacity is not bounded by the max heap size, and c) the assrt that fires is in the wrong place. The fix also includes some tidying up of the related verbose code. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: bb847e31b836 Author: tonyp Date: 2010-08-17 14:40 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bb847e31b836 6974928: G1: sometimes humongous objects are allocated in young regions Summary: as the title says, sometimes we are allocating humongous objects in young regions and we shouldn't. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: b63010841f78 Author: tonyp Date: 2010-08-17 14:40 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b63010841f78 6975964: G1: print out a more descriptive message for evacuation failure when +PrintGCDetails is set Summary: we're renaming "evacuation failure" to "to-space overflow". I'm also piggy-backing a small additional change which removes the "Mark closure took..." output. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 5ed703250bff Author: ysr Date: 2010-08-18 11:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5ed703250bff 6977970: CMS: concurrentMarkSweepGeneration.cpp:7947 assert(addr <= _limit) failed: sweep invariant Summary: Allow for the possibility (when the heap is expanding) that the sweep might skip over and past, rather than necessarily step on, the sweep limit determined at the beginning of a concurrent marking cycle. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 413ad0331a0c Author: johnc Date: 2010-08-18 10:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/413ad0331a0c 6977924: Changes for 6975078 produce build error with certain gcc versions Summary: The changes introduced for 6975078 assign badHeapOopVal to the _allocation field in the ResourceObj class. In 32 bit linux builds with certain versions of gcc this assignment will be flagged as an error while compiling allocation.cpp. In 32 bit builds the constant value badHeapOopVal (which is cast to an intptr_t) is negative. The _allocation field is typed as an unsigned intptr_t and gcc catches this as an error. Reviewed-by: jcoomes, ysr, phh ! src/share/vm/memory/allocation.cpp Changeset: effb55808a18 Author: johnc Date: 2010-08-18 17:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/effb55808a18 Merge Changeset: 1b0104ab1e5e Author: tonyp Date: 2010-08-19 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1b0104ab1e5e Merge From joe.darcy at oracle.com Thu Aug 19 19:03:27 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 19 Aug 2010 19:03:27 -0700 Subject: Throwable types handled specially in the VM? Message-ID: <4C6DE26F.8020408@oracle.com> Hello. As part of Project Coin, try-with-resources/ARM blocks have recently been integrated into JDK 7. Part of this feature is changes to java.lang.Throwable to support recording of suppressed exception information (6911258 "Project Coin: Add essential API support for Automatic Resource Management (ARM) blocks"). Subsequently, some more changes in Throwable were necessary to fix a regression in the ability to print the stack traces of specially handled OutOfMemoryErrors (6973831 "NPE when printing stack trace of OOME"). Are there any other Throwable types which receive special handling or creation by the VM? If there are any, I'd like to examine them to find and correct and additional issues. Thanks, -Joe From David.Holmes at oracle.com Thu Aug 19 19:24:56 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 20 Aug 2010 12:24:56 +1000 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C6DE26F.8020408@oracle.com> References: <4C6DE26F.8020408@oracle.com> Message-ID: <4C6DE778.5020703@oracle.com> Hi Joe, Joe Darcy said the following on 08/20/10 12:03: > As part of Project Coin, try-with-resources/ARM blocks have recently > been integrated into JDK 7. Part of this feature is changes to > java.lang.Throwable to support recording of suppressed exception > information (6911258 "Project Coin: Add essential API support for > Automatic Resource Management (ARM) blocks"). Subsequently, some more > changes in Throwable were necessary to fix a regression in the ability > to print the stack traces of specially handled OutOfMemoryErrors > (6973831 "NPE when printing stack trace of OOME"). > > Are there any other Throwable types which receive special handling or > creation by the VM? If there are any, I'd like to examine them to find > and correct and additional issues. All the preallocation of exceptions occurs in universe_post_init in universe.cpp. These are as follows // Setup preallocated OutOfMemoryError errors Universe::_out_of_memory_error_java_heap = k_h->allocate_permanent_instance(CHECK_false); Universe::_out_of_memory_error_perm_gen = k_h->allocate_permanent_instance(CHECK_false); Universe::_out_of_memory_error_array_size = k_h->allocate_permanent_instance(CHECK_false); Universe::_out_of_memory_error_gc_overhead_limit = k_h->allocate_permanent_instance(CHECK_false); // Setup preallocated NullPointerException // (this is currently used for a cheap & dirty solution in compiler exception handling) Universe::_null_ptr_exception_instance = instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); // Setup preallocated ArithmeticException // (this is currently used for a cheap & dirty solution in compiler exception handling) Universe::_arithmetic_exception_instance = instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); // Virtual Machine Error for when we get into a situation we can't resolve Universe::_virtual_machine_error_instance = instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); As you're aware from 6973831 these are raw allocations that invoke no constructor, so all fields are implicitly set to their default (null, 0) values. I can't think of any other specialized exception handling. David From aph at redhat.com Fri Aug 20 01:34:29 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Aug 2010 09:34:29 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6CA9D0.3010904@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> Message-ID: <4C6E3E15.6040509@redhat.com> On 08/19/2010 04:49 AM, David Holmes wrote: > diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp > --- a/src/os/linux/vm/os_linux.cpp > +++ b/src/os/linux/vm/os_linux.cpp > @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint > // where we're going to put our guard pages, truncate the mapping at > // that point by munmap()ping it. This ensures that when we later > // munmap() the guard pages we don't leave a hole in the stack > -// mapping. > +// mapping. This only affects the main/initial thread, but guard > +// against future OS changes > bool os::create_stack_guard_pages(char* addr, size_t size) { > uintptr_t stack_extent, stack_base; > - if (get_stack_bounds(&stack_extent, &stack_base)) { > + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { > + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); > if (stack_extent < (uintptr_t)addr) > ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); > } Is stack_extent initialized here in NOT_DEBUG mode? > @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* > } > > // If this is a growable mapping, remove the guard pages entirely by > -// munmap()ping them. If not, just call uncommit_memory(). > +// munmap()ping them. If not, just call uncommit_memory(). This only > +// affects the main/initial thread, but guard against future OS changes > bool os::remove_stack_guard_pages(char* addr, size_t size) { > uintptr_t stack_extent, stack_base; > - if (get_stack_bounds(&stack_extent, &stack_base)) { > + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { > + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); > + > return ::munmap(addr, size) == 0; > } This is basically a good compromise, I think. Andrew. From Ulf.Zibis at gmx.de Fri Aug 20 02:27:47 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 20 Aug 2010 11:27:47 +0200 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C6DE26F.8020408@oracle.com> References: <4C6DE26F.8020408@oracle.com> Message-ID: <4C6E4A93.4030501@gmx.de> A comment aside: Having: int[] ia = new int[SIZE]; Arrays.fill(ia, 1234); The 1st line causes the array to be first filled with zeroes according the JLS. The 2nd line causes the array to be *again* filled with 1234's. This situation could be optimized by the JIT in skipping the zero-filling. Maybe this is just done by HotSpot, then forget my 2 cents. 1 cent more: To give programmer better control of that and to enhance the interpreter in the same way, we would need to have an additional syntax, something like: int [] ia = new int[SIZE](1234); // Project Coin candidate! -Ulf Am 20.08.2010 04:03, schrieb Joe Darcy: > Hello. > > As part of Project Coin, try-with-resources/ARM blocks have recently > been integrated into JDK 7. Part of this feature is changes to > java.lang.Throwable to support recording of suppressed exception > information (6911258 "Project Coin: Add essential API support for > Automatic Resource Management (ARM) blocks"). Subsequently, some more > changes in Throwable were necessary to fix a regression in the ability > to print the stack traces of specially handled OutOfMemoryErrors > (6973831 "NPE when printing stack trace of OOME"). > > Are there any other Throwable types which receive special handling or > creation by the VM? If there are any, I'd like to examine them to > find and correct and additional issues. > > Thanks, > > -Joe > > From aph at redhat.com Fri Aug 20 02:29:51 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Aug 2010 10:29:51 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6CEC4A.9090407@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CEC4A.9090407@redhat.com> Message-ID: <4C6E4B0F.8030507@redhat.com> On 08/19/2010 09:33 AM, Andrew Haley wrote: > On 08/19/2010 12:41 AM, David Holmes wrote: >> >> Was there a regression test created for this bug? That would catch any >> change. > > Yes there was, and it was attached to the very first message in this thread. > > It was never checked in to the source tree, though, and I'm not sure it's > in a suitable form for the regression test suite. I misspoke. See hotspot/test/runtime/6929067. Andrew. From David.Holmes at oracle.com Fri Aug 20 02:54:18 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 20 Aug 2010 19:54:18 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6E3E15.6040509@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> Message-ID: <4C6E50CA.2020607@oracle.com> Andrew Haley said the following on 08/20/10 18:34: > On 08/19/2010 04:49 AM, David Holmes wrote: > >> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >> --- a/src/os/linux/vm/os_linux.cpp >> +++ b/src/os/linux/vm/os_linux.cpp >> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >> // where we're going to put our guard pages, truncate the mapping at >> // that point by munmap()ping it. This ensures that when we later >> // munmap() the guard pages we don't leave a hole in the stack >> -// mapping. >> +// mapping. This only affects the main/initial thread, but guard >> +// against future OS changes >> bool os::create_stack_guard_pages(char* addr, size_t size) { >> uintptr_t stack_extent, stack_base; >> - if (get_stack_bounds(&stack_extent, &stack_base)) { >> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { >> + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); >> if (stack_extent < (uintptr_t)addr) >> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >> } > > Is stack_extent initialized here in NOT_DEBUG mode? It may not be, but in that case it is unused. I filed 6978641 for this and will request a formal review shortly. Thanks, David >> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >> } >> >> // If this is a growable mapping, remove the guard pages entirely by >> -// munmap()ping them. If not, just call uncommit_memory(). >> +// munmap()ping them. If not, just call uncommit_memory(). This only >> +// affects the main/initial thread, but guard against future OS changes >> bool os::remove_stack_guard_pages(char* addr, size_t size) { >> uintptr_t stack_extent, stack_base; >> - if (get_stack_bounds(&stack_extent, &stack_base)) { >> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { >> + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); >> + >> return ::munmap(addr, size) == 0; >> } > > This is basically a good compromise, I think. > > Andrew. From Ulf.Zibis at gmx.de Fri Aug 20 03:19:28 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 20 Aug 2010 12:19:28 +0200 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C6E4A93.4030501@gmx.de> References: <4C6DE26F.8020408@oracle.com> <4C6E4A93.4030501@gmx.de> Message-ID: <4C6E56B0.4090402@gmx.de> Oops, my last comment should have been for "review (M) for 4809552: Optimize Arrays.fill(...)" -Ulf Am 20.08.2010 11:27, schrieb Ulf Zibis: > A comment aside: > Having: > int[] ia = new int[SIZE]; > Arrays.fill(ia, 1234); > > The 1st line causes the array to be first filled with zeroes according > the JLS. > The 2nd line causes the array to be *again* filled with 1234's. > > This situation could be optimized by the JIT in skipping the > zero-filling. > Maybe this is just done by HotSpot, then forget my 2 cents. > > 1 cent more: > To give programmer better control of that and to enhance the > interpreter in the same way, we would need to have an additional > syntax, something like: > int [] ia = new int[SIZE](1234); // Project Coin candidate! > > -Ulf > > > > Am 20.08.2010 04:03, schrieb Joe Darcy: >> Hello. >> >> As part of Project Coin, try-with-resources/ARM blocks have recently >> been integrated into JDK 7. Part of this feature is changes to >> java.lang.Throwable to support recording of suppressed exception >> information (6911258 "Project Coin: Add essential API support for >> Automatic Resource Management (ARM) blocks"). Subsequently, some >> more changes in Throwable were necessary to fix a regression in the >> ability to print the stack traces of specially handled >> OutOfMemoryErrors (6973831 "NPE when printing stack trace of OOME"). >> >> Are there any other Throwable types which receive special handling or >> creation by the VM? If there are any, I'd like to examine them to >> find and correct and additional issues. >> >> Thanks, >> >> -Joe >> >> > > > From erik.trimble at oracle.com Fri Aug 20 03:51:09 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 10:51:09 +0000 Subject: hg: jdk7/hotspot: 7 new changesets Message-ID: <20100820105110.2298C472FC@hg.openjdk.java.net> Changeset: 86a3df41c0c7 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/86a3df41c0c7 Added tag jdk7-b102 for changeset a136a51f5113 ! .hgtags Changeset: f1ba69da5003 Author: ohair Date: 2010-07-26 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f1ba69da5003 6972274: Fix the use of egrep -ci in the top level makefile sanity checks Reviewed-by: prr ! make/sanity-rules.gmk Changeset: be2aedc4e3b1 Author: mikejwre Date: 2010-07-28 21:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/be2aedc4e3b1 Merge Changeset: f8be576feefc Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f8be576feefc Added tag jdk7-b103 for changeset be2aedc4e3b1 ! .hgtags Changeset: 9f96a4269d77 Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/9f96a4269d77 Added tag jdk7-b104 for changeset f8be576feefc ! .hgtags Changeset: 43096cccf1ce Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/43096cccf1ce Added tag jdk7-b105 for changeset 9f96a4269d77 ! .hgtags Changeset: 7d396ad455c3 Author: cl Date: 2010-08-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/7d396ad455c3 Added tag jdk7-b106 for changeset 43096cccf1ce ! .hgtags From erik.trimble at oracle.com Fri Aug 20 03:51:14 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 10:51:14 +0000 Subject: hg: jdk7/hotspot/corba: 5 new changesets Message-ID: <20100820105119.5270C472FD@hg.openjdk.java.net> Changeset: 11e7678c3eb1 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/11e7678c3eb1 Added tag jdk7-b102 for changeset 78561a957790 ! .hgtags Changeset: 9607213481d4 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/9607213481d4 Added tag jdk7-b103 for changeset 11e7678c3eb1 ! .hgtags Changeset: 6f21b030092f Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/6f21b030092f Added tag jdk7-b104 for changeset 9607213481d4 ! .hgtags Changeset: 519daea48888 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/519daea48888 Added tag jdk7-b105 for changeset 6f21b030092f ! .hgtags Changeset: 232adb83eae8 Author: cl Date: 2010-08-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/232adb83eae8 Added tag jdk7-b106 for changeset 519daea48888 ! .hgtags From erik.trimble at oracle.com Fri Aug 20 03:54:30 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 10:54:30 +0000 Subject: hg: jdk7/hotspot/jaxp: 5 new changesets Message-ID: <20100820105430.5D2DF472FE@hg.openjdk.java.net> Changeset: b7722e878864 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/b7722e878864 Added tag jdk7-b102 for changeset 15573625af97 ! .hgtags Changeset: d42c4acb6424 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/d42c4acb6424 Added tag jdk7-b103 for changeset b7722e878864 ! .hgtags Changeset: 3233b9a4c12e Author: cl Date: 2010-08-06 12:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/3233b9a4c12e Added tag jdk7-b104 for changeset d42c4acb6424 ! .hgtags Changeset: 5ba8469212a6 Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/5ba8469212a6 Added tag jdk7-b105 for changeset 3233b9a4c12e ! .hgtags Changeset: 20ee37c1372a Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/20ee37c1372a Added tag jdk7-b106 for changeset 5ba8469212a6 ! .hgtags From erik.trimble at oracle.com Fri Aug 20 03:54:34 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 10:54:34 +0000 Subject: hg: jdk7/hotspot/jaxws: 5 new changesets Message-ID: <20100820105434.81D48472FF@hg.openjdk.java.net> Changeset: 267386d6b923 Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/267386d6b923 Added tag jdk7-b102 for changeset d8580443d181 ! .hgtags Changeset: bbc4cce6c20a Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/bbc4cce6c20a Added tag jdk7-b103 for changeset 267386d6b923 ! .hgtags Changeset: 39eb4f3031f4 Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/39eb4f3031f4 Added tag jdk7-b104 for changeset bbc4cce6c20a ! .hgtags Changeset: bc45ccc5bcca Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/bc45ccc5bcca Added tag jdk7-b105 for changeset 39eb4f3031f4 ! .hgtags Changeset: 017612ea6af4 Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/017612ea6af4 Added tag jdk7-b106 for changeset bc45ccc5bcca ! .hgtags From erik.trimble at oracle.com Fri Aug 20 03:56:13 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 10:56:13 +0000 Subject: hg: jdk7/hotspot/jdk: 51 new changesets Message-ID: <20100820110441.6BEB347300@hg.openjdk.java.net> Changeset: 6488b70a23cc Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6488b70a23cc Added tag jdk7-b102 for changeset 13029a61b16b ! .hgtags Changeset: b839344245a9 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b839344245a9 Added tag jdk7-b103 for changeset 6488b70a23cc ! .hgtags Changeset: 6950da80c75c Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6950da80c75c 6973616: Update minimum boot jdk from 1.5 to 1.6 Reviewed-by: igor, jjg ! make/common/shared/Defs-versions.gmk Changeset: dd48c78218a7 Author: ohair Date: 2010-08-02 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd48c78218a7 6971426: jdk/make/docs docs target does not work on windows Reviewed-by: igor, jjg ! make/docs/Makefile Changeset: f46ec75b1663 Author: ohair Date: 2010-08-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f46ec75b1663 6974239: Correct reference to jdk document site in javadoc Reviewed-by: skannan ! make/docs/Makefile Changeset: 1a92820132a0 Author: cl Date: 2010-08-04 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1a92820132a0 Merge Changeset: d967f8507d9d Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d967f8507d9d Added tag jdk7-b104 for changeset 1a92820132a0 ! .hgtags Changeset: 539528c5d395 Author: lana Date: 2010-07-14 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/539528c5d395 Merge Changeset: cf0c23a99823 Author: lana Date: 2010-07-29 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cf0c23a99823 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: c6f443c3d96a Author: lana Date: 2010-08-02 19:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c6f443c3d96a Merge Changeset: c38803ce0560 Author: uta Date: 2010-07-23 18:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c38803ce0560 6969851: VM hangs/crashes in FileDialog test (VS2008/2010 build) Reviewed-by: prr, art ! src/windows/native/sun/windows/awt.h Changeset: 9bb8d5c093fc Author: lana Date: 2010-07-29 13:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9bb8d5c093fc Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 8a72583dc41d Author: lana Date: 2010-08-02 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8a72583dc41d Merge Changeset: 65403b9bcb58 Author: peterz Date: 2010-07-13 17:26 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/65403b9bcb58 6462562: InternationalFormatter inserts text incorrectly 6578432: Currency format instance does not work with Swing's NumberFormatter Reviewed-by: rupashka ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/InternationalFormatter.java + test/javax/swing/JFormattedTextField/Test6462562.java Changeset: a0d7b76abcd3 Author: alexp Date: 2010-07-29 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a0d7b76abcd3 4743225: Size of JComboBox list is wrong when list is populated via PopupMenuListener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java + test/javax/swing/JComboBox/4743225/bug4743225.java Changeset: 0e8acbf12695 Author: lana Date: 2010-07-29 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0e8acbf12695 Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 - test/java/nio/channels/ServerSocketChannel/AcceptAddress.java - test/java/nio/charset/coders/Surrogate.java - test/tools/launcher/Makefile.SolarisRunpath - test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so - test/tools/launcher/lib/i386/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib32/liblibrary.so - test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so - test/tools/launcher/lib/sparc/lib64/liblibrary.so Changeset: 951e46d93af0 Author: malenkov Date: 2010-07-30 19:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/951e46d93af0 6199676: REGRESSION: ColorChooser loses preview when change LandF in Java5 Reviewed-by: alexp, peterz ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java + test/javax/swing/JColorChooser/Test6199676.java Changeset: f40de306ab66 Author: malenkov Date: 2010-07-30 19:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f40de306ab66 6972468: Security manager should be used for tests in java/beans/XMLEncoder Reviewed-by: peterz ! test/java/beans/XMLEncoder/Test4631471.java ! test/java/beans/XMLEncoder/Test4903007.java ! test/java/beans/XMLEncoder/javax_swing_JLayeredPane.java Changeset: ce1e26600ab7 Author: lana Date: 2010-08-02 19:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ce1e26600ab7 Merge Changeset: 25050030a320 Author: dsamersoff Date: 2010-07-13 15:32 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/25050030a320 6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if java.net.preferIPvStack property set Summary: User can disable ipv6 explicitly, have to check it Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c + test/java/net/NetworkInterface/IPv4Only.java Changeset: f3a4c1947fd1 Author: weijun Date: 2010-07-13 20:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f3a4c1947fd1 6670889: Keystore created under Hindi Locale causing ArrayIndexOutOfBoundsException Reviewed-by: chegar ! src/share/classes/sun/security/util/DerOutputStream.java + test/sun/security/util/DerOutputStream/LocaleInTime.java Changeset: ab65f46ae092 Author: darcy Date: 2010-07-15 18:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ab65f46ae092 6963622: Project Coin: Refinements to suppressed exceptions Reviewed-by: alanb, forax, jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java Changeset: a3747592bdf7 Author: sherman Date: 2010-07-16 16:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a3747592bdf7 6964313: Find sun/nio/cs/ext issue with CreateSymbols, then move sun/nio/cs/ext to charset.jar Summary: Removed the duplicate sun.nio.cs.ext entries from rt.jar and moved X11 charsets into charsets.jar Reviewed-by: ohair ! make/common/Release.gmk ! make/sun/nio/cs/Makefile Changeset: 9a1bd20fc71c Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9a1bd20fc71c 6969683: Generify ResolverConfiguration codes Reviewed-by: alanb, chegar ! src/share/classes/com/sun/jndi/dns/DnsContextFactory.java ! src/share/classes/sun/net/dns/ResolverConfiguration.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java Changeset: 4022e0c84507 Author: weijun Date: 2010-07-19 10:02 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4022e0c84507 6969292: make DNS lookup for realm/kdc really work Reviewed-by: alanb, valeriep ! src/share/classes/sun/security/krb5/Config.java Changeset: 9d1994d53a67 Author: mullan Date: 2010-07-20 10:41 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9d1994d53a67 6870553: X509Certificate.getSigAlgName method description uses non-standard algorithm name as example Reviewed-by: xuelei ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java Changeset: 58f325ba3e27 Author: chegar Date: 2010-07-21 13:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/58f325ba3e27 6969395: TEST_BUG: Tests in java/net sun/net problems Reviewed-by: alanb ! test/ProblemList.txt ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test11.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test6a.java ! test/com/sun/net/httpserver/Test7a.java ! test/com/sun/net/httpserver/Test8a.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/bugs/B6361557.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/java/net/DatagramSocket/DatagramTimeout.java ! test/java/net/DatagramSocket/SendSize.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/SetOutgoingIf.java ! test/java/net/ResponseCache/B6181108.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java - test/java/net/Socket/AccurateTimeout.java ! test/java/net/Socket/CloseAvailable.java ! test/java/net/Socket/DeadlockTest.java ! test/java/net/Socket/LingerTest.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/Socket/ProxyCons.java ! test/java/net/Socket/ReadTimeout.java ! test/java/net/Socket/SetReceiveBufferSize.java ! test/java/net/Socket/SetSoLinger.java ! test/java/net/Socket/ShutdownBoth.java ! test/java/net/Socket/SoTimeout.java ! test/java/net/Socket/Timeout.java ! test/java/net/Socket/UrgentDataTest.java ! test/java/net/Socket/asyncClose/BrokenPipe.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/SocketInputStream/SocketClosedException.java ! test/java/net/SocketInputStream/SocketTimeout.java ! test/java/net/URL/GetContent.java ! test/java/net/URLClassLoader/ClassLoad.java ! test/java/net/URLConnection/DisconnectAfterEOF.java ! test/java/net/URLConnection/HandleContentTypeWithAttrs.java ! test/java/net/URLConnection/HttpContinueStackOverflow.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java ! test/java/net/URLConnection/ResendPostBody.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/net/URLConnection/TimeoutTest.java ! test/java/net/URLConnection/URLConnectionHeaders.java ! test/java/net/URLConnection/ZeroContentLength.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java ! test/sun/net/ftp/FtpGetContent.java ! test/sun/net/ftp/FtpURL.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/HttpClient/MultiThreadTest.java ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java ! test/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java ! test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/protocol/http/DigestTest.java Changeset: f90999d7c404 Author: chegar Date: 2010-07-21 13:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f90999d7c404 6970262: TEST_BUG: test/java/net/NetworkInterface/IPv4Only.java has wrong test name in @run tag Reviewed-by: alanb, dsamersoff ! test/java/net/NetworkInterface/IPv4Only.java Changeset: 3902c742b5b1 Author: alanb Date: 2010-07-21 18:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3902c742b5b1 6963907: (so) Socket adapter need to implement sendUrgentData Reviewed-by: chegar ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c + test/java/nio/channels/SocketChannel/OutOfBand.java Changeset: d899526a187a Author: dcubed Date: 2010-07-21 16:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d899526a187a 6941287: 4/4 jrunscriptTest.sh test does not work right under Cygwin Summary: Add golden_diff variable for doing proper golden file diffs on Cygwin. Reviewed-by: ohair, dholmes ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh Changeset: 946236dc5c96 Author: dcubed Date: 2010-07-21 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/946236dc5c96 6962804: 4/4 ShellScaffold tests can fail without a specific reason Summary: Add more diagnostics for failures. Only copy target file in grepForString when NL is missing. Reviewed-by: ohair, dholmes ! test/com/sun/jdi/ShellScaffold.sh Changeset: 9cb77130999f Author: dcubed Date: 2010-07-21 17:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9cb77130999f 6964018: 3/4 AnonLoggerWeakRefLeak and LoggerWeakRefLeak can fail in JPRT Summary: Refactor test/sun/tools/common/* code and refactor AnonLoggerWeakRefLeak and LoggerWeakRefLeak to use it. Reviewed-by: ohair, alanb ! test/java/util/logging/AnonLoggerWeakRefLeak.java ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.java ! test/java/util/logging/LoggerWeakRefLeak.sh ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/common/CommonTests.sh ! test/sun/tools/common/ShutdownSimpleApplication.java ! test/sun/tools/common/SimpleApplication.java + test/sun/tools/common/SleeperApplication.java ! test/sun/tools/jhat/ParseTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jstack/Basic.sh Changeset: 748f004aeb5c Author: vinnie Date: 2010-07-23 17:41 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/748f004aeb5c 6676075: RegistryContext (com.sun.jndi.url.rmi.rmiURLContext) coding problem Reviewed-by: mullan ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java + test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Changeset: 56217857ccd7 Author: xuelei Date: 2010-07-24 22:59 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/56217857ccd7 6867345: Turkish regional options cause NPE in sun.security.x509.AlgorithmId.algOID Reviewed-by: mullan, weijun ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/x509/AVA.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java + test/sun/security/x509/AlgorithmId/TurkishRegion.java Changeset: 402ff3e81922 Author: weijun Date: 2010-07-26 17:21 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/402ff3e81922 6972005: ConfPlusProp.java test failure when DNS has info for realm Reviewed-by: xuelei ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/confplusprop.conf ! test/sun/security/krb5/confplusprop2.conf Changeset: db21b420d038 Author: martin Date: 2010-07-26 08:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/db21b420d038 6717780: (coll spec) LinkedList api documentation provides the wrong method name Summary: Cleanup by simply making Deque equal status with List Reviewed-by: darcy ! src/share/classes/java/util/LinkedList.java Changeset: 1bfa1c864553 Author: dcubed Date: 2010-07-26 09:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1bfa1c864553 6971847: 4/4 jmap '-histo:live' option is necessary for proper leak detection Summary: Add work around for 6971851. Abort if 'histo:live' option isn't supported. Reviewed-by: alanb, darcy ! test/java/util/logging/AnonLoggerWeakRefLeak.sh ! test/java/util/logging/LoggerWeakRefLeak.sh Changeset: 83be262e654c Author: xuelei Date: 2010-07-27 16:07 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/83be262e654c 6870947: 15 sec delay detecting "socket closed" condition when a TCP connection is reset by an LDAP server Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: 5ff8b884a92c Author: vinnie Date: 2010-07-27 11:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5ff8b884a92c 6972409: Cease emitting LDAP filter debug messages Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Filter.java Changeset: 24741c4bf300 Author: alanb Date: 2010-07-29 13:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/24741c4bf300 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated 6799037: (fs) MappedByteBuffer.load crash with unaligned file-mapping (sol) Reviewed-by: chegar, forax ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/MappedByteBuffer.java ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/windows/native/java/nio/MappedByteBuffer.c ! test/java/nio/MappedByteBuffer/Basic.java + test/java/nio/MappedByteBuffer/Truncate.java Changeset: a8a79f5b669e Author: chegar Date: 2010-07-29 10:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a8a79f5b669e 6972374: NetworkInterface.getNetworkInterfaces throws "java.net.SocketException" on Solaris zone Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/NetworkInterface.c Changeset: d82ed433304e Author: chegar Date: 2010-07-29 17:04 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d82ed433304e Merge Changeset: 48e6f4807e5f Author: lana Date: 2010-07-29 22:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/48e6f4807e5f Merge - src/linux/doc/man/ja/kinit.1 - src/linux/doc/man/ja/klist.1 - src/linux/doc/man/ja/ktab.1 ! test/ProblemList.txt Changeset: 4d72d0ec83f5 Author: michaelm Date: 2010-07-30 18:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4d72d0ec83f5 6510892: com/sun/net/httpserver/bugs/B6361557.java fails Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6361557.java Changeset: 10e7e04d1e96 Author: lana Date: 2010-08-02 19:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/10e7e04d1e96 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 3b0abcb51280 Author: lana Date: 2010-08-09 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3b0abcb51280 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 9ad95be9deae Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9ad95be9deae Added tag jdk7-b105 for changeset 3b0abcb51280 ! .hgtags Changeset: f8bbf376595c Author: yhuang Date: 2010-08-11 02:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8bbf376595c 6959252: convert the anonymous arrays to named arrays in Java List Resource files Reviewed-by: katakai, psun ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/sun/applet/resources/MsgAppletViewer.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java Changeset: 413cede85120 Author: yhuang Date: 2010-08-13 01:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/413cede85120 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: b91ef6b60f4e Author: cl Date: 2010-08-16 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b91ef6b60f4e Merge Changeset: 882103f334bb Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/882103f334bb Added tag jdk7-b106 for changeset b91ef6b60f4e ! .hgtags From erik.trimble at oracle.com Fri Aug 20 04:06:41 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 11:06:41 +0000 Subject: hg: jdk7/hotspot/langtools: 27 new changesets Message-ID: <20100820110730.C2B7947301@hg.openjdk.java.net> Changeset: bd85271c580c Author: mikejwre Date: 2010-07-23 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bd85271c580c Added tag jdk7-b102 for changeset ff9c0a0bf7ed ! .hgtags Changeset: fc7219517ec1 Author: cl Date: 2010-07-29 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fc7219517ec1 Added tag jdk7-b103 for changeset bd85271c580c ! .hgtags Changeset: 49489c1d8fae Author: cl Date: 2010-08-06 12:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/49489c1d8fae Added tag jdk7-b104 for changeset fc7219517ec1 ! .hgtags Changeset: a5454419dd46 Author: jjg Date: 2010-07-13 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a5454419dd46 6966732: replace use of static Log.getLocalizedString with non-static alternative where possible Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: 0e1fab5cffc8 Author: jjg Date: 2010-07-13 19:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0e1fab5cffc8 6968434: test CheckResourceKeys fails on control builds Reviewed-by: darcy ! test/tools/javac/diags/CheckResourceKeys.java Changeset: e57b27703e8b Author: jjg Date: 2010-07-13 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e57b27703e8b 6968789: incorrect text in "diamond not supported" message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: b49b0d72c071 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b49b0d72c071 6967002: JDK7 b99 javac compilation error (java.lang.AssertionError) Summary: bug in JavacParser related to parsing of type annotations in varargs position Reviewed-by: jjg Contributed-by: mahmood at notnoop.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/typeAnnotations/6967002/T6967002.java + test/tools/javac/typeAnnotations/6967002/T6967002.out Changeset: 472e74211e11 Author: mcimadamore Date: 2010-07-15 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/472e74211e11 6964669: javac reports error on miranda methods Summary: synthetic name clash check should not apply to miranda methods Reviewed-by: jjg Contributed-by: tomas.zezula at sun.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/miranda/6964669/T6964669.java + test/tools/javac/miranda/6964669/pkg/A.java + test/tools/javac/miranda/6964669/pkg/B.java + test/tools/javac/miranda/6964669/pkg/C.java Changeset: 13354e1abba7 Author: darcy Date: 2010-07-16 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/13354e1abba7 6911256: Project Coin: Support Automatic Resource Management (ARM) blocks in the compiler 6964740: Project Coin: More tests for ARM compiler changes 6965277: Project Coin: Correctness issues in ARM implementation 6967065: add -Xlint warning category for Automatic Resource Management (ARM) Reviewed-by: jjb, darcy, mcimadamore, jjg, briangoetz Contributed-by: tball at google.com ! make/build.properties ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/TryWithResources/ArmLint.java + test/tools/javac/TryWithResources/ArmLint.out + test/tools/javac/TryWithResources/BadTwr.java + test/tools/javac/TryWithResources/BadTwr.out + test/tools/javac/TryWithResources/BadTwrSyntax.java + test/tools/javac/TryWithResources/BadTwrSyntax.out + test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.java + test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/TryWithResources/ImplicitFinal.java + test/tools/javac/TryWithResources/ImplicitFinal.out + test/tools/javac/TryWithResources/PlainTry.java + test/tools/javac/TryWithResources/PlainTry.out + test/tools/javac/TryWithResources/PlainTry6.out + test/tools/javac/TryWithResources/ResourceOutsideTry.java + test/tools/javac/TryWithResources/ResourceOutsideTry.out + test/tools/javac/TryWithResources/ResourceTypeVar.java + test/tools/javac/TryWithResources/TwrFlow.java + test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/TryWithResources/TwrInference.java + test/tools/javac/TryWithResources/TwrIntersection.java + test/tools/javac/TryWithResources/TwrIntersection02.java + test/tools/javac/TryWithResources/TwrIntersection02.out + test/tools/javac/TryWithResources/TwrMultiCatch.java + test/tools/javac/TryWithResources/TwrOnNonResource.java + test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/TryWithResources/TwrTests.java + test/tools/javac/TryWithResources/WeirdTwr.java + test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: 3640b60bd0f6 Author: jjg Date: 2010-07-22 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/3640b60bd0f6 6968063: provide examples of code that generate diagnostics Reviewed-by: mcimadamore ! make/build.xml + test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/Example.java + test/tools/javac/diags/FileManager.java + test/tools/javac/diags/HTMLWriter.java + test/tools/javac/diags/README.examples.txt + test/tools/javac/diags/RunExamples.java + test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/AbstractCantBeAccessed.java + test/tools/javac/diags/examples/AbstractCantBeInstantiated.java + test/tools/javac/diags/examples/AbstractMethodCantHaveBody.java + test/tools/javac/diags/examples/AlreadyDefined.java + test/tools/javac/diags/examples/AlreadyDefinedImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java + test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/diags/examples/AnnoNotApplicable.java + test/tools/javac/diags/examples/AnnoNotValidForType.java + test/tools/javac/diags/examples/AnnoValueMustBeAnnotation.java + test/tools/javac/diags/examples/AnnoValueMustBeClassLiteral.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/AnnosWithoutProcessors.java + test/tools/javac/diags/examples/AnnosWithoutProcessors/processors/AnnoProc.java + test/tools/javac/diags/examples/AnnotationMissingValue.java + test/tools/javac/diags/examples/AnnotationMustBeNameValue.java + test/tools/javac/diags/examples/AnnotationsNotSupported.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoArgs.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoQualForNew.java + test/tools/javac/diags/examples/AnonClassImplInterfaceNoTypeArgs.java + test/tools/javac/diags/examples/AnonymousClass.java + test/tools/javac/diags/examples/ArrayAndVarargs.java + test/tools/javac/diags/examples/ArrayDimMissing.java + test/tools/javac/diags/examples/ArrayRequired.java + test/tools/javac/diags/examples/AssertAsIdentifier.java + test/tools/javac/diags/examples/AssertAsIdentifier2.java + test/tools/javac/diags/examples/AttrMustBeConstant.java + test/tools/javac/diags/examples/BadSourceFileHeader/BadSourceFileHeader.java + test/tools/javac/diags/examples/BadSourceFileHeader/sourcepath/p/A.java + test/tools/javac/diags/examples/BreakOutsideSwitchLoop.java + test/tools/javac/diags/examples/CallMustBeFirst.java + test/tools/javac/diags/examples/CannotCreateArrayWithTypeArgs.java + test/tools/javac/diags/examples/CantApplyDiamond.java + test/tools/javac/diags/examples/CantAssignToFinal.java + test/tools/javac/diags/examples/CantDeref.java + test/tools/javac/diags/examples/CantExtendIntfAnno.java + test/tools/javac/diags/examples/CantImplement.java + test/tools/javac/diags/examples/CantInheritDiffArg.java + test/tools/javac/diags/examples/CantRefBeforeConstr.java + test/tools/javac/diags/examples/CantResolve.java + test/tools/javac/diags/examples/CantResolveArgs.java + test/tools/javac/diags/examples/CantResolveArgsParams.java + test/tools/javac/diags/examples/CantResolveLocation.java + test/tools/javac/diags/examples/CantResolveLocationArgs.java + test/tools/javac/diags/examples/CantResolveLocationArgsParams.java + test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/ClashesWith.java + test/tools/javac/diags/examples/ClassCantWrite.java + test/tools/javac/diags/examples/ClassPublicInFile.java + test/tools/javac/diags/examples/ConcreteInheritanceConflict.java + test/tools/javac/diags/examples/ConstExprRequired.java + test/tools/javac/diags/examples/ConstantSVUID.java + test/tools/javac/diags/examples/ContinueOutsideLoop.java + test/tools/javac/diags/examples/CountError.java + test/tools/javac/diags/examples/CountErrorPlural.java + test/tools/javac/diags/examples/CountWarn.java + test/tools/javac/diags/examples/CountWarnPlural.java + test/tools/javac/diags/examples/CyclicAnnoElement.java + test/tools/javac/diags/examples/CyclicInheritance.java + test/tools/javac/diags/examples/DefaultAllowedInIntfAnnotationMember.java + test/tools/javac/diags/examples/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedFilenameAdditional.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPlural/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedClass.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedFilename.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPlural.java + test/tools/javac/diags/examples/DeprecatedPluralAdditional/DeprecatedPluralAdditional.java + test/tools/javac/diags/examples/DiamondInvalidArg.java + test/tools/javac/diags/examples/DiamondInvalidArgs.java + test/tools/javac/diags/examples/DiamondNotSupported.java + test/tools/javac/diags/examples/DirPathElementNotFound.java + test/tools/javac/diags/examples/DivZero.java + test/tools/javac/diags/examples/DoesNotOverride.java + test/tools/javac/diags/examples/DoesntExist.java + test/tools/javac/diags/examples/DotClassExpected.java + test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationMemberValue.java + test/tools/javac/diags/examples/DuplicateCaseLabel.java + test/tools/javac/diags/examples/DuplicateClass.java + test/tools/javac/diags/examples/DuplicateDefaultLabel.java + test/tools/javac/diags/examples/ElseWithoutIf.java + test/tools/javac/diags/examples/EmptyBytecodeIdent.java + test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/diags/examples/EmptyIf.java + test/tools/javac/diags/examples/EnclClassRequired.java + test/tools/javac/diags/examples/EnumAnnoValueMustBeEnumConst.java + test/tools/javac/diags/examples/EnumAsIdentifier.java + test/tools/javac/diags/examples/EnumAsIdentifier2.java + test/tools/javac/diags/examples/EnumCantBeInstantiated.java + test/tools/javac/diags/examples/EnumConstRequired.java + test/tools/javac/diags/examples/EnumLabelUnqualified.java + test/tools/javac/diags/examples/EnumNoFinalize.java + test/tools/javac/diags/examples/EnumNoSubclassing.java + test/tools/javac/diags/examples/EnumTypesNotExtensible.java + test/tools/javac/diags/examples/EnumsMustBeStatic.java + test/tools/javac/diags/examples/EnumsNotSupported.java + test/tools/javac/diags/examples/ErrProcMessager/ErrProcMessager.java + test/tools/javac/diags/examples/ErrProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/ErrSyntheticNameConflict.java + test/tools/javac/diags/examples/Error.java + test/tools/javac/diags/examples/ErrorReadingFile.java + test/tools/javac/diags/examples/ExceptAlreadyCaught.java + test/tools/javac/diags/examples/ExceptNeverThrown.java + test/tools/javac/diags/examples/Expected2.java + test/tools/javac/diags/examples/Expected3.java + test/tools/javac/diags/examples/FinalParamCantBeAssigned.java + test/tools/javac/diags/examples/FinallyCannotComplete.java + test/tools/javac/diags/examples/FinallyWithoutTry.java + test/tools/javac/diags/examples/FloatNumberTooLarge.java + test/tools/javac/diags/examples/FloatNumberTooSmall.java + test/tools/javac/diags/examples/ForeachNotApplicable.java + test/tools/javac/diags/examples/ForeachNotSupported.java + test/tools/javac/diags/examples/GenericArrayCreation.java + test/tools/javac/diags/examples/GenericThrowable.java + test/tools/javac/diags/examples/GenericsNotSupported.java + test/tools/javac/diags/examples/HasBeenDeprecated.java + test/tools/javac/diags/examples/IdentifierExpected.java + test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java + test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/IllegalComboModifiers.java + test/tools/javac/diags/examples/IllegalEnumStaticRef.java + test/tools/javac/diags/examples/IllegalEscapeChar.java + test/tools/javac/diags/examples/IllegalForwardRef.java + test/tools/javac/diags/examples/IllegalInitializer.java + test/tools/javac/diags/examples/IllegalLineEndInCharLit.java + test/tools/javac/diags/examples/IllegalNonAsciiDigit.java + test/tools/javac/diags/examples/IllegalQualNotIcls.java + test/tools/javac/diags/examples/IllegalSelfRef.java + test/tools/javac/diags/examples/IllegalStartOfExpr.java + test/tools/javac/diags/examples/IllegalUnderscore.java + test/tools/javac/diags/examples/IllegalUnicodeEscape.java + test/tools/javac/diags/examples/ImportRequiresCanonical/ImportRequiresCanonical.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/Base.java + test/tools/javac/diags/examples/ImportRequiresCanonical/p/ExtendsBase.java + test/tools/javac/diags/examples/ImproperSVUID.java + test/tools/javac/diags/examples/ImproperTypeInnerRawParam.java + test/tools/javac/diags/examples/ImproperTypeParamMissing.java + test/tools/javac/diags/examples/IncomparableTypes.java + test/tools/javac/diags/examples/IncompatibleTypes1.java + test/tools/javac/diags/examples/InconvertibleTypes.java + test/tools/javac/diags/examples/InexactVarargsCall.java + test/tools/javac/diags/examples/InferredDoNotConformToBounds.java + test/tools/javac/diags/examples/InheritFromFinal.java + test/tools/javac/diags/examples/InitializerMustComplete.java + test/tools/javac/diags/examples/InnerClassCantHaveStatic.java + test/tools/javac/diags/examples/IntNumberTooLarge.java + test/tools/javac/diags/examples/InterfaceExpected.java + test/tools/javac/diags/examples/InterfaceNotAllowed.java + test/tools/javac/diags/examples/IntfAnnotationCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfAnnotationMemberClash.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveParams.java + test/tools/javac/diags/examples/IntfAnnotationsCantHaveTypeParams.java + test/tools/javac/diags/examples/IntfMethodCantHaveBody.java + test/tools/javac/diags/examples/InvalidAnnoMemberType.java + test/tools/javac/diags/examples/InvalidBinaryNumber.java + test/tools/javac/diags/examples/InvalidHexNumber.java + test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/diags/examples/InvalidInstanceof.java + test/tools/javac/diags/examples/InvalidMethodDecl.java + test/tools/javac/diags/examples/KindnameClass.java + test/tools/javac/diags/examples/KindnameConstructor.java + test/tools/javac/diags/examples/KindnameMethod.java + test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/LabelInUse.java + test/tools/javac/diags/examples/LocalEnum.java + test/tools/javac/diags/examples/LocalVarNeedsFinal.java + test/tools/javac/diags/examples/LongSVUID.java + test/tools/javac/diags/examples/MalformedFpLit.java + test/tools/javac/diags/examples/MalformedSupported/MalformedSupported.java + test/tools/javac/diags/examples/MalformedSupported/processors/AnnoProc.java + test/tools/javac/diags/examples/MethodDoesNotOverride.java + test/tools/javac/diags/examples/MightBeAssignedInLoop.java + test/tools/javac/diags/examples/MissingDeprecatedAnnotation.java + test/tools/javac/diags/examples/MissingMethodBody.java + test/tools/javac/diags/examples/MissingReturnStatement.java + test/tools/javac/diags/examples/MissingReturnValue.java + test/tools/javac/diags/examples/MissingSVUID.java + test/tools/javac/diags/examples/ModifierNotAllowed.java + test/tools/javac/diags/examples/MulticatchCantBeAssigned.java + test/tools/javac/diags/examples/MulticatchMustBeFinal.java + test/tools/javac/diags/examples/MulticatchNotSupported.java + test/tools/javac/diags/examples/NameClashSameErasure.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NativeMethodCantHaveBody.java + test/tools/javac/diags/examples/NeitherConditionalSubtype.java + test/tools/javac/diags/examples/NewNotAllowedInAnno.java + test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NoExplicitAnnoProcRequested.java + test/tools/javac/diags/examples/NoInterfaceExpected.java + test/tools/javac/diags/examples/NoInterfaceHere.java + test/tools/javac/diags/examples/NoJavaLang.java + test/tools/javac/diags/examples/NoSuperclass.java + test/tools/javac/diags/examples/NonStaticCantBeRef.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/NotDefAccessClassIntfCantAccess.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccess/p/C.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/NotDefPublicCantAccess.java + test/tools/javac/diags/examples/NotDefPublicCantAccess/p/C.java + test/tools/javac/diags/examples/NotEnclClass.java + test/tools/javac/diags/examples/NotLoopLabel.java + test/tools/javac/diags/examples/NotWithinBounds.java + test/tools/javac/diags/examples/Note.java + test/tools/javac/diags/examples/NoteProcMessager/NoteProcMessager.java + test/tools/javac/diags/examples/NoteProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/Orphaned.java + test/tools/javac/diags/examples/OverrideDoesntThrow.java + test/tools/javac/diags/examples/OverrideIncompatibleReturn.java + test/tools/javac/diags/examples/OverrideMeth.java + test/tools/javac/diags/examples/OverrideStatic.java + test/tools/javac/diags/examples/OverrideUncheckedReturn.java + test/tools/javac/diags/examples/OverrideUncheckedThrown.java + test/tools/javac/diags/examples/OverrideVarargsExtra.java + test/tools/javac/diags/examples/OverrideVarargsMissing.java + test/tools/javac/diags/examples/OverrideWeakerAccess.java + test/tools/javac/diags/examples/PackageAnnos.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/p/package-info.java + test/tools/javac/diags/examples/PackageInfoAlreadySeen/package-info.java + test/tools/javac/diags/examples/PathElementNotFound.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q.java + test/tools/javac/diags/examples/PkgClashWithClass/p/q/C.java + test/tools/javac/diags/examples/PossibleFallThrough.java + test/tools/javac/diags/examples/PossibleLossPrecision.java + test/tools/javac/diags/examples/PrematureEOF.java + test/tools/javac/diags/examples/PrintProcessorInfo/PrintProcessorInfo.java + test/tools/javac/diags/examples/PrintProcessorInfo/processors/AnnoProc.java + test/tools/javac/diags/examples/PrintRounds/PrintRounds.java + test/tools/javac/diags/examples/PrintRounds/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcCantFindClass/ProcCantFindClass.java + test/tools/javac/diags/examples/ProcCantFindClass/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcFileReopening/ProcFileReopening.java + test/tools/javac/diags/examples/ProcFileReopening/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIllegalFileName/ProcIllegalFileName.java + test/tools/javac/diags/examples/ProcIllegalFileName/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/ProcIncompatibleSourceVersion.java + test/tools/javac/diags/examples/ProcIncompatibleSourceVersion/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcOnlyNoProcs.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/ProcPackageDoesNotExist.java + test/tools/javac/diags/examples/ProcPackageDoesNotExist/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcTypeRecreate/ProcTypeRecreate.java + test/tools/javac/diags/examples/ProcTypeRecreate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/ProcUnclosedTypeFiles.java + test/tools/javac/diags/examples/ProcUnclosedTypeFiles/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/ProcUseImplicit.java + test/tools/javac/diags/examples/ProcUseImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/ProcUseProcOrImplicit.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcUseProcOrImplicit/sourcepath/p/SomeClass.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/ProcessorCantInstantiate.java + test/tools/javac/diags/examples/ProcessorCantInstantiate/processors/AnnoProc.java + test/tools/javac/diags/examples/ProcessorNotFound.java + test/tools/javac/diags/examples/ProcessorWrongType/ProcessorWrongType.java + test/tools/javac/diags/examples/ProcessorWrongType/processors/AnnoProc.java + test/tools/javac/diags/examples/QualifiedNewStaticClass.java + test/tools/javac/diags/examples/RawClassUse.java + test/tools/javac/diags/examples/RecursiveConstrInvocation.java + test/tools/javac/diags/examples/RedundantCast.java + test/tools/javac/diags/examples/RefAmbiguous.java + test/tools/javac/diags/examples/RepeatedAnnotationTarget.java + test/tools/javac/diags/examples/RepeatedInterface.java + test/tools/javac/diags/examples/RepeatedModifier.java + test/tools/javac/diags/examples/ReportAccess.java + test/tools/javac/diags/examples/ResourceClosed.java + test/tools/javac/diags/examples/ResourceMayNotBeAssigned.java + test/tools/javac/diags/examples/ResourceNotApplicableToType.java + test/tools/javac/diags/examples/ResourceNotReferenced.java + test/tools/javac/diags/examples/ReturnOutsideMethod.java + test/tools/javac/diags/examples/StaticImportNotSupported.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/Other.java + test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java + test/tools/javac/diags/examples/StaticNotQualifiedByType.java + test/tools/javac/diags/examples/StringConstRequired.java + test/tools/javac/diags/examples/StringSwitchNotSupported.java + test/tools/javac/diags/examples/SunApiFilename.java + test/tools/javac/diags/examples/SunApiFilenameAdditional.java + test/tools/javac/diags/examples/SunApiPlural/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPlural/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiFilename.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPlural.java + test/tools/javac/diags/examples/SunApiPluralAdditional/SunApiPluralAdditional.java + test/tools/javac/diags/examples/SunProprietary.java + test/tools/javac/diags/examples/SuperNotAllowedInEnum.java + test/tools/javac/diags/examples/ThrowsNotAllowedInAnno.java + test/tools/javac/diags/examples/TryResourceNotSupported.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinally.java + test/tools/javac/diags/examples/TryWithoutCatchOrFinallyOrResource.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java + test/tools/javac/diags/examples/TypeFoundRequired.java + test/tools/javac/diags/examples/TypeNoParams.java + test/tools/javac/diags/examples/TypeReqClassArray.java + test/tools/javac/diags/examples/TypeReqRef.java + test/tools/javac/diags/examples/TypeVarCantBeDeref.java + test/tools/javac/diags/examples/TypeVarMayNotBeFollowedByOtherBounds.java + test/tools/javac/diags/examples/TypesIncompatible.java + test/tools/javac/diags/examples/UncheckedAssign.java + test/tools/javac/diags/examples/UncheckedAssignToVar.java + test/tools/javac/diags/examples/UncheckedCall.java + test/tools/javac/diags/examples/UncheckedCast.java + test/tools/javac/diags/examples/UncheckedClash.java + test/tools/javac/diags/examples/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedFilenameAdditional.java + test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java + test/tools/javac/diags/examples/UncheckedImplement.java + test/tools/javac/diags/examples/UncheckedMethodInvocation.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedFilename.java + test/tools/javac/diags/examples/UncheckedPlural/UncheckedPlural.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename1.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedFilename2.java + test/tools/javac/diags/examples/UncheckedPluralAdditional/UncheckedPluralAdditional.java + test/tools/javac/diags/examples/UnclosedBytecodeIdent.java + test/tools/javac/diags/examples/UnclosedCharLiteral.java + test/tools/javac/diags/examples/UnclosedComment.java + test/tools/javac/diags/examples/UnclosedStringLiteral.java + test/tools/javac/diags/examples/UndefinedLabel.java + test/tools/javac/diags/examples/UndeterminedType1.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/UnmatchedProcessorOptions.java + test/tools/javac/diags/examples/UnmatchedProcessorOptions/processors/AnnoProc.java + test/tools/javac/diags/examples/UnnamedPackage.java + test/tools/javac/diags/examples/UnreachableStatement.java + test/tools/javac/diags/examples/UnreportedException.java + test/tools/javac/diags/examples/UnreportedExceptionDefaultConstructor.java + test/tools/javac/diags/examples/UnsupportedBinaryLiteral.java + test/tools/javac/diags/examples/UnsupportedEncoding.java + test/tools/javac/diags/examples/UnsupportedFpLit.java + test/tools/javac/diags/examples/UnsupportedUnderscoreLiteral.java + test/tools/javac/diags/examples/VarMightAlreadyBeAssigned.java + test/tools/javac/diags/examples/VarMightNotHaveBeenInitialized.java + test/tools/javac/diags/examples/VarargsClash.java + test/tools/javac/diags/examples/VarargsFilename.java + test/tools/javac/diags/examples/VarargsFilenameAdditional.java + test/tools/javac/diags/examples/VarargsImplement.java + test/tools/javac/diags/examples/VarargsNonReifiableType.java + test/tools/javac/diags/examples/VarargsNotSupported.java + test/tools/javac/diags/examples/VarargsOverride.java + test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java + test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java + test/tools/javac/diags/examples/Verbose.java + test/tools/javac/diags/examples/VoidNotAllowed.java + test/tools/javac/diags/examples/WarnForwardRef.java + test/tools/javac/diags/examples/WarnProcMessager/WarnProcMessager.java + test/tools/javac/diags/examples/WarnProcMessager/processors/AnnoProc.java + test/tools/javac/diags/examples/WarnSelfRef.java + test/tools/javac/diags/examples/WarnSyntheticNameConflict.java + test/tools/javac/diags/examples/WarningAndWerror.java + test/tools/javac/diags/examples/WhereCaptured.java + test/tools/javac/diags/examples/WhereCaptured1.java + test/tools/javac/diags/examples/WhereIntersection.java + test/tools/javac/diags/examples/WhereTypeVar.java + test/tools/javac/diags/examples/WrongNumberTypeArgs.java Changeset: 4172cfff05f0 Author: jjg Date: 2010-07-26 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4172cfff05f0 6971882: Remove -XDstdout from javac test Reviewed-by: darcy ! test/tools/javac/4980495/static/Test.java ! test/tools/javac/4980495/std/Test.java ! test/tools/javac/6304921/T6304921.java ! test/tools/javac/6330920/T6330920.java ! test/tools/javac/6491592/T6491592.java ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/CyclicInheritance.java ! test/tools/javac/Digits.java ! test/tools/javac/ExtendArray.java ! test/tools/javac/ExtendsAccess/ExtendsAccess.java ! test/tools/javac/FloatingPointChanges/BadConstructorModifiers.java ! test/tools/javac/IllegalAnnotation.java ! test/tools/javac/InnerNamedConstant_2.java ! test/tools/javac/InterfaceMemberClassModifiers.java ! test/tools/javac/LocalClasses_2.java ! test/tools/javac/NameCollision.java ! test/tools/javac/NestedInnerClassNames.java ! test/tools/javac/NonStaticFieldExpr1.java ! test/tools/javac/NonStaticFieldExpr2.java ! test/tools/javac/NonStaticFieldExpr3.java ! test/tools/javac/OverridePosition.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_1.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_2.java ! test/tools/javac/QualifiedAccess/QualifiedAccess_3.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.java ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.java ! test/tools/javac/StringsInSwitch/NonConstantLabel.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels1.java ! test/tools/javac/StringsInSwitch/RepeatedStringCaseLabels2.java ! test/tools/javac/SynchronizedClass.java ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4906100.java ! test/tools/javac/T4994049/T4994049.java ! test/tools/javac/T5003235/T5003235a.java ! test/tools/javac/T5003235/T5003235b.java ! test/tools/javac/T5003235/T5003235c.java ! test/tools/javac/T5024091/T5024091.java ! test/tools/javac/T5048776.java ! test/tools/javac/T6214885.java ! test/tools/javac/T6224167.java ! test/tools/javac/T6227617.java ! test/tools/javac/T6230128.java ! test/tools/javac/T6231847.java ! test/tools/javac/T6241723.java ! test/tools/javac/T6245591.java ! test/tools/javac/T6247324.java ! test/tools/javac/T6394563.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depDocComment/DeprecatedDocComment.java ! test/tools/javac/depDocComment/SuppressDeprecation.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/annotation/Test3.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/depOverrides/doccomment/Test3.java ! test/tools/javac/enum/6384542/T6384542.java ! test/tools/javac/enum/6384542/T6384542a.java ! test/tools/javac/enum/forwardRef/T6425594.java ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/6207386/T6207386.java ! test/tools/javac/generics/6359951/T6359951.java ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/wildcards/6437894/T6437894.java ! test/tools/javac/lint/NoWarn.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/miranda/T4666866.java ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/positions/T6253161.java ! test/tools/javac/positions/T6253161a.java ! test/tools/javac/positions/T6264029.java ! test/tools/javac/processing/messager/6362067/T6362067.java ! test/tools/javac/processing/warnings/TestSourceVersionWarnings.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess2.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess3.java ! test/tools/javac/protectedAccess/ProtectedMemberAccess4.java ! test/tools/javac/rawDiags/Error.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/rawDiags/Warning.java ! test/tools/javac/unicode/UnicodeNewline.java ! test/tools/javac/warnings/Deprecation.java ! test/tools/javac/warnings/DivZero.java ! test/tools/javac/warnings/FallThrough.java ! test/tools/javac/warnings/Unchecked.java Changeset: d1bd93028447 Author: jjg Date: 2010-07-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/d1bd93028447 6957438: improve code for generating warning messages containing option names Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/Paths.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/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! test/tools/javac/diags/examples/CountWarn.java ! test/tools/javac/diags/examples/CountWarnPlural.java ! test/tools/javac/diags/examples/Error.java Changeset: b29160d1b3e0 Author: jjg Date: 2010-07-27 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b29160d1b3e0 6972327: JCTree.pos incorrect for annotations without modifiers and package Reviewed-by: mcimadamore Contributed-by: jan.lahoda at sun.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T6972327.java Changeset: ed354a00f76b Author: jjg Date: 2010-07-27 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ed354a00f76b 6403456: -Werror should work with annotation processing Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/werror/WError1.java + test/tools/javac/processing/werror/WError1.out + test/tools/javac/processing/werror/WErrorGen.java + test/tools/javac/processing/werror/WErrorGen.out + test/tools/javac/processing/werror/WErrorLast.java + test/tools/javac/processing/werror/WErrorLast.out Changeset: 36c4ec4525b4 Author: mcimadamore Date: 2010-07-29 15:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/36c4ec4525b4 6938454: Unable to determine generic type in program that compiles under Java 6 Summary: a redundant dubtyping check causes spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6938454/T6938454a.java + test/tools/javac/generics/inference/6938454/T6938454b.java Changeset: e79e8efe1b3e Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/e79e8efe1b3e 6972747: CheckExamples fail when assertions are enabled Summary: The test calls the wrong version of JavacMessage constructor Reviewed-by: jjg ! test/tools/javac/diags/Example.java Changeset: 62f3f07002ea Author: mcimadamore Date: 2010-07-29 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/62f3f07002ea 6970833: Try-with-resource implementation throws an NPE during Flow analysis Summary: Updated logic not to rely upon Symbol.implementation (which check in superinterfaces) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/TryWithResources/ResourceInterface.java + test/tools/javac/TryWithResources/ResourceInterface.out Changeset: 4a7979c3ce15 Author: jjg Date: 2010-07-29 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/4a7979c3ce15 6972556: warning for using a file name instead of a binary name for Filer.createSourceFile Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ProcSuspiciousClassName/ProcSuspiciousClassName.java + test/tools/javac/diags/examples/ProcSuspiciousClassName/processors/AnnoProc.java Changeset: 8a5c98a695ae Author: jjg Date: 2010-07-29 19:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8a5c98a695ae 6340549: javax.tools.JavaCompilerTool.getStandardFileManager().list() includes directories Reviewed-by: darcy + test/tools/javac/T6340549.java Changeset: 2cf925ad67ab Author: jjg Date: 2010-07-29 19:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2cf925ad67ab 6966604: JavacFiler not correctly notified of lastRound Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ProcFileCreateLastRound/ProcFileCreateLastRound.java + test/tools/javac/diags/examples/ProcFileCreateLastRound/processors/AnnoProc.java + test/tools/javac/processing/filer/TestLastRound.java + test/tools/javac/processing/filer/TestLastRound.out ! test/tools/javac/processing/werror/WErrorGen.java Changeset: 077eb94c912d Author: lana Date: 2010-07-29 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/077eb94c912d Merge Changeset: 38e2c23309f1 Author: darcy Date: 2010-08-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/38e2c23309f1 6971877: Project Coin: improve semantics of suppressed exceptions in try-with-resources Reviewed-by: jjb + test/tools/javac/TryWithResources/TwrSuppression.java Changeset: 6318230cdb82 Author: jjg Date: 2010-08-02 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6318230cdb82 6973626: test/tools/javac/processing/* tests fail with assertions enabled Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 186feb2042f0 Author: lana Date: 2010-08-02 19:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/186feb2042f0 Merge Changeset: aaecac256d39 Author: lana Date: 2010-08-09 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/aaecac256d39 Merge Changeset: 112fcc00659d Author: cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/112fcc00659d Added tag jdk7-b105 for changeset aaecac256d39 ! .hgtags Changeset: 2c1c657f69a4 Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2c1c657f69a4 Added tag jdk7-b106 for changeset 112fcc00659d ! .hgtags From erik.trimble at oracle.com Fri Aug 20 04:09:37 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 11:09:37 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20100820110953.8057D47302@hg.openjdk.java.net> Changeset: 30266066c77c Author: cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/30266066c77c Added tag jdk7-b106 for changeset 1b81ca701fa5 ! .hgtags Changeset: 295c3ae4ab5b Author: trims Date: 2010-08-19 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/295c3ae4ab5b Added tag hs19-b05 for changeset cc3fdfeb54b0 ! .hgtags Changeset: bf496cbe9b74 Author: trims Date: 2010-08-19 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bf496cbe9b74 Added tag hs19-b06 for changeset 688a538aa654 ! .hgtags Changeset: 0e509ddd9962 Author: trims Date: 2010-08-20 03:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e509ddd9962 6978726: Bump the HS19 build number to 07 Summary: Update the HS19 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 09cdb1e1c77b Author: trims Date: 2010-08-20 04:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/09cdb1e1c77b Merge - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp From coleen.phillimore at oracle.com Fri Aug 20 06:15:37 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Aug 2010 09:15:37 -0400 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4C6E3E15.6040509@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> Message-ID: <4C6E7FF9.9040009@oracle.com> This change looks fine to me and yes, thanks for pointing out that I did add the test. Coleen Andrew Haley wrote: > On 08/19/2010 04:49 AM, David Holmes wrote: > > >> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >> --- a/src/os/linux/vm/os_linux.cpp >> +++ b/src/os/linux/vm/os_linux.cpp >> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >> // where we're going to put our guard pages, truncate the mapping at >> // that point by munmap()ping it. This ensures that when we later >> // munmap() the guard pages we don't leave a hole in the stack >> -// mapping. >> +// mapping. This only affects the main/initial thread, but guard >> +// against future OS changes >> bool os::create_stack_guard_pages(char* addr, size_t size) { >> uintptr_t stack_extent, stack_base; >> - if (get_stack_bounds(&stack_extent, &stack_base)) { >> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { >> + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); >> if (stack_extent < (uintptr_t)addr) >> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >> } >> > > Is stack_extent initialized here in NOT_DEBUG mode? > > >> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >> } >> >> // If this is a growable mapping, remove the guard pages entirely by >> -// munmap()ping them. If not, just call uncommit_memory(). >> +// munmap()ping them. If not, just call uncommit_memory(). This only >> +// affects the main/initial thread, but guard against future OS changes >> bool os::remove_stack_guard_pages(char* addr, size_t size) { >> uintptr_t stack_extent, stack_base; >> - if (get_stack_bounds(&stack_extent, &stack_base)) { >> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) get_stack_bounds(&stack_extent, &stack_base)) { >> + assert(os::Linux::is_initial_thread(), "growable stack in non-initial thread"); >> + >> return ::munmap(addr, size) == 0; >> } >> > > This is basically a good compromise, I think. > > Andrew. > From tom.rodriguez at oracle.com Fri Aug 20 11:58:31 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 20 Aug 2010 18:58:31 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20100820185842.BC3FD47319@hg.openjdk.java.net> Changeset: 71faaa8e3ccc Author: never Date: 2010-08-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/71faaa8e3ccc 6974176: ShouldNotReachHere, instanceKlass.cpp:1426 Reviewed-by: kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: da877bdc9000 Author: never Date: 2010-08-12 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/da877bdc9000 6975006: assert(check.is_deoptimized_frame()) failed: missed deopt Reviewed-by: kvn, twisti ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.cpp Changeset: a62d332029cf Author: never Date: 2010-08-13 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a62d332029cf 6976372: # assert(_owner == Thread::current()) failed: invariant Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 13b87063b4d8 Author: twisti Date: 2010-08-18 01:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/13b87063b4d8 6977640: Zero and Shark fixes Summary: A number of fixes for Zero and Shark. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: f55c4f82ab9d Author: never Date: 2010-08-19 14:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f55c4f82ab9d 6978249: spill between cpu and fpu registers when those moves are fast Reviewed-by: kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/init.cpp Changeset: ee5cc9e78493 Author: never Date: 2010-08-20 09:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ee5cc9e78493 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp From joe.darcy at oracle.com Fri Aug 20 14:01:01 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 20 Aug 2010 14:01:01 -0700 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C6DE778.5020703@oracle.com> References: <4C6DE26F.8020408@oracle.com> <4C6DE778.5020703@oracle.com> Message-ID: <4C6EED0D.20801@oracle.com> Hi David. David Holmes wrote: > Hi Joe, > > Joe Darcy said the following on 08/20/10 12:03: >> As part of Project Coin, try-with-resources/ARM blocks have recently >> been integrated into JDK 7. Part of this feature is changes to >> java.lang.Throwable to support recording of suppressed exception >> information (6911258 "Project Coin: Add essential API support for >> Automatic Resource Management (ARM) blocks"). Subsequently, some >> more changes in Throwable were necessary to fix a regression in the >> ability to print the stack traces of specially handled >> OutOfMemoryErrors (6973831 "NPE when printing stack trace of OOME"). >> >> Are there any other Throwable types which receive special handling or >> creation by the VM? If there are any, I'd like to examine them to >> find and correct and additional issues. > > All the preallocation of exceptions occurs in universe_post_init in > universe.cpp. These are as follows > > // Setup preallocated OutOfMemoryError errors > Universe::_out_of_memory_error_java_heap = > k_h->allocate_permanent_instance(CHECK_false); > Universe::_out_of_memory_error_perm_gen = > k_h->allocate_permanent_instance(CHECK_false); > Universe::_out_of_memory_error_array_size = > k_h->allocate_permanent_instance(CHECK_false); > Universe::_out_of_memory_error_gc_overhead_limit = > k_h->allocate_permanent_instance(CHECK_false); > > // Setup preallocated NullPointerException > // (this is currently used for a cheap & dirty solution in > compiler exception handling) > Universe::_null_ptr_exception_instance = > instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); > // Setup preallocated ArithmeticException > // (this is currently used for a cheap & dirty solution in > compiler exception handling) > Universe::_arithmetic_exception_instance = > instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); > // Virtual Machine Error for when we get into a situation we can't > resolve > Universe::_virtual_machine_error_instance = > instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); > > As you're aware from 6973831 these are raw allocations that invoke no > constructor, so all fields are implicitly set to their default (null, > 0) values. Right. > > I can't think of any other specialized exception handling. > From the name "allocate_permanent_instance," I assume that these exception objects are saved and reused for the lifetime of the JVM, correct? For better or worse, Throwable and its subclasses are mutable; the suppressed warning information is a new possible mutation, setting the stack trace is an existing mutability avenue. If so, as Remi has recently pointed out, perhaps these fields should be cleared when the exceptions are resued? From an API perspective, perhaps the suppression feature should be modified so that self-suppression is interpreted as not allowing a particular exception instance to record addition suppressed exceptions... -Joe From tony.printezis at oracle.com Fri Aug 20 13:58:36 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 20 Aug 2010 20:58:36 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20100820205857.A496347320@hg.openjdk.java.net> Changeset: 52f2bc645da5 Author: ysr Date: 2010-08-19 12:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/52f2bc645da5 6978533: CMS: Elide BOT update asserts until 6977974 is fixed correctly Reviewed-by: jcoomes, jmasa, tonyp ! src/share/vm/memory/blockOffsetTable.hpp Changeset: 66b9f90a9211 Author: tonyp Date: 2010-08-20 13:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/66b9f90a9211 Merge Changeset: 26faca352942 Author: tonyp Date: 2010-08-20 12:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/26faca352942 Merge From erik.trimble at oracle.com Fri Aug 20 14:26:04 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 20 Aug 2010 21:26:04 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20100820212608.49E4D4732E@hg.openjdk.java.net> Changeset: 571f6b35140b Author: trims Date: 2010-08-20 12:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/571f6b35140b 6978889: Remove premature change of build number to Hotspot 19 Build 07 Summary: Change the build number back to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b0b9d64ed9bc Author: trims Date: 2010-08-20 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b0b9d64ed9bc 6978915: Remove Mercurial tags for Hotspot 19 Build 06 Summary: Delete the hs19-b06 Hg tag, as it was put on incorrectly Reviewed-by: jcoomes ! .hgtags From mandy.chung at oracle.com Fri Aug 20 15:52:11 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Aug 2010 15:52:11 -0700 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C6EED0D.20801@oracle.com> References: <4C6DE26F.8020408@oracle.com> <4C6DE778.5020703@oracle.com> <4C6EED0D.20801@oracle.com> Message-ID: <4C6F071B.3060107@oracle.com> Joe Darcy wrote: > Hi David. > > David Holmes wrote: >> Hi Joe, >> >> Joe Darcy said the following on 08/20/10 12:03: >>> As part of Project Coin, try-with-resources/ARM blocks have recently >>> been integrated into JDK 7. Part of this feature is changes to >>> java.lang.Throwable to support recording of suppressed exception >>> information (6911258 "Project Coin: Add essential API support for >>> Automatic Resource Management (ARM) blocks"). Subsequently, some >>> more changes in Throwable were necessary to fix a regression in the >>> ability to print the stack traces of specially handled >>> OutOfMemoryErrors (6973831 "NPE when printing stack trace of OOME"). >>> >>> Are there any other Throwable types which receive special handling >>> or creation by the VM? If there are any, I'd like to examine them >>> to find and correct and additional issues. >> >> All the preallocation of exceptions occurs in universe_post_init in >> universe.cpp. These are as follows >> >> // Setup preallocated OutOfMemoryError errors >> Universe::_out_of_memory_error_java_heap = >> k_h->allocate_permanent_instance(CHECK_false); >> Universe::_out_of_memory_error_perm_gen = >> k_h->allocate_permanent_instance(CHECK_false); >> Universe::_out_of_memory_error_array_size = >> k_h->allocate_permanent_instance(CHECK_false); >> Universe::_out_of_memory_error_gc_overhead_limit = >> k_h->allocate_permanent_instance(CHECK_false); >> >> // Setup preallocated NullPointerException >> // (this is currently used for a cheap & dirty solution in >> compiler exception handling) >> Universe::_null_ptr_exception_instance = >> instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); >> // Setup preallocated ArithmeticException >> // (this is currently used for a cheap & dirty solution in >> compiler exception handling) >> Universe::_arithmetic_exception_instance = >> instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); >> // Virtual Machine Error for when we get into a situation we >> can't resolve >> Universe::_virtual_machine_error_instance = >> instanceKlass::cast(k)->allocate_permanent_instance(CHECK_false); >> >> As you're aware from 6973831 these are raw allocations that invoke no >> constructor, so all fields are implicitly set to their default (null, >> 0) values. > > Right. > >> >> I can't think of any other specialized exception handling. >> > From the name "allocate_permanent_instance," I assume that these > exception objects are saved and reused for the lifetime of the JVM, > correct? For better or worse, Throwable and its subclasses are > mutable; the suppressed warning information is a new possible > mutation, setting the stack trace is an existing mutability avenue. > > If so, as Remi has recently pointed out, perhaps these fields should > be cleared when the exceptions are resued? > FYI - this is tracked by 6978918. Mandy > From an API perspective, perhaps the suppression feature should be > modified so that self-suppression is interpreted as not allowing a > particular exception instance to record addition suppressed exceptions... > > -Joe From nagy.mostafa at gmail.com Sun Aug 22 12:30:59 2010 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Sun, 22 Aug 2010 12:30:59 -0700 Subject: Bytecode re-writing Message-ID: Hi, I was wondering if there is a way to do bytecode re-writing right before compilation in the C2 compiler. I would like to do this inside the VM and not through a JVMTI event as I need access to VM internal data. Is there a simple way to do that (e.g. through some C/C++ library) ? Would it be simpler to do it at the IR level instead ? The transformation involves injecting some code into the stream so it seems simpler to do it at the bytecode-level. Any suggestions ? Thanks, - nagy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100822/5a367ea8/attachment.html From David.Holmes at oracle.com Sun Aug 22 16:22:42 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 09:22:42 +1000 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <4C6E7FF9.9040009@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> Message-ID: <4C71B142.1000405@oracle.com> Here's the official OpenJKDK webrev for this: http://cr.openjdk.java.net/~dholmes/6978641/ If I can add you both as reviewers that would be great. Coleen can you send me details on which release/build I should use in the CR and also if there is any special "magic" I need to submit via JPRT. Thanks, David Coleen Phillimore said the following on 08/20/10 23:15: > > This change looks fine to me and yes, thanks for pointing out that I did > add the test. > > Coleen > > Andrew Haley wrote: >> On 08/19/2010 04:49 AM, David Holmes wrote: >> >> >>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >>> --- a/src/os/linux/vm/os_linux.cpp >>> +++ b/src/os/linux/vm/os_linux.cpp >>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >>> // where we're going to put our guard pages, truncate the mapping at >>> // that point by munmap()ping it. This ensures that when we later >>> // munmap() the guard pages we don't leave a hole in the stack >>> -// mapping. >>> +// mapping. This only affects the main/initial thread, but guard >>> +// against future OS changes >>> bool os::create_stack_guard_pages(char* addr, size_t size) { >>> uintptr_t stack_extent, stack_base; >>> - if (get_stack_bounds(&stack_extent, &stack_base)) { >>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) >>> get_stack_bounds(&stack_extent, &stack_base)) { >>> + assert(os::Linux::is_initial_thread(), "growable stack in >>> non-initial thread"); >>> if (stack_extent < (uintptr_t)addr) >>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >>> } >>> >> >> Is stack_extent initialized here in NOT_DEBUG mode? >> >> >>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >>> } >>> >>> // If this is a growable mapping, remove the guard pages entirely by >>> -// munmap()ping them. If not, just call uncommit_memory(). >>> +// munmap()ping them. If not, just call uncommit_memory(). This only >>> +// affects the main/initial thread, but guard against future OS changes >>> bool os::remove_stack_guard_pages(char* addr, size_t size) { >>> uintptr_t stack_extent, stack_base; >>> - if (get_stack_bounds(&stack_extent, &stack_base)) { >>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) >>> get_stack_bounds(&stack_extent, &stack_base)) { >>> + assert(os::Linux::is_initial_thread(), "growable stack in >>> non-initial thread"); >>> + >>> return ::munmap(addr, size) == 0; >>> } >> >> This is basically a good compromise, I think. >> >> Andrew. >> From David.Holmes at oracle.com Mon Aug 23 02:48:19 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 19:48:19 +1000 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C6EED0D.20801@oracle.com> References: <4C6DE26F.8020408@oracle.com> <4C6DE778.5020703@oracle.com> <4C6EED0D.20801@oracle.com> Message-ID: <4C7243E3.1000708@oracle.com> Hi Joe, Joe Darcy said the following on 08/21/10 07:01: > From the name "allocate_permanent_instance," I assume that these > exception objects are saved and reused for the lifetime of the JVM, > correct? For better or worse, Throwable and its subclasses are mutable; > the suppressed warning information is a new possible mutation, setting > the stack trace is an existing mutability avenue. > > If so, as Remi has recently pointed out, perhaps these fields should be > cleared when the exceptions are resued? As I have outlined in detail in the thread "Updated ARM Spec" the pre-allocated instances that can be thrown more than once do not have any mutable state (prior to suppressed exceptions) and so there is nothing to clear. I just realized however that clearing the suppressed-exception state is simply not an option as the same exception instance could be thrown concurrently in multiple threads. In short these shared immutable exception instances must remain immutable if they are to be shared. > From an API perspective, perhaps the suppression feature should be > modified so that self-suppression is interpreted as not allowing a > particular exception instance to record addition suppressed exceptions... If you are suggesting this as a way of making the suppression state immutable, then I'd suggest that it might be preferable to model this the same way that stacktraces are handled - they only need to be optionally present. The same thing could be said for suppressed-exceptions. David From David.Holmes at oracle.com Mon Aug 23 03:36:47 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 23 Aug 2010 20:36:47 +1000 Subject: Throwable types handled specially in the VM? In-Reply-To: <4C7243E3.1000708@oracle.com> References: <4C6DE26F.8020408@oracle.com> <4C6DE778.5020703@oracle.com> <4C6EED0D.20801@oracle.com> <4C7243E3.1000708@oracle.com> Message-ID: <4C724F3F.3010604@oracle.com> Corrections and continued discussion in the "Re: Updated ARM Spec" thread. David David Holmes said the following on 08/23/10 19:48: > Hi Joe, > > Joe Darcy said the following on 08/21/10 07:01: >> From the name "allocate_permanent_instance," I assume that these >> exception objects are saved and reused for the lifetime of the JVM, >> correct? For better or worse, Throwable and its subclasses are >> mutable; the suppressed warning information is a new possible >> mutation, setting the stack trace is an existing mutability avenue. >> >> If so, as Remi has recently pointed out, perhaps these fields should >> be cleared when the exceptions are resued? > > As I have outlined in detail in the thread "Updated ARM Spec" the > pre-allocated instances that can be thrown more than once do not have > any mutable state (prior to suppressed exceptions) and so there is > nothing to clear. > > I just realized however that clearing the suppressed-exception state is > simply not an option as the same exception instance could be thrown > concurrently in multiple threads. In short these shared immutable > exception instances must remain immutable if they are to be shared. > >> From an API perspective, perhaps the suppression feature should be >> modified so that self-suppression is interpreted as not allowing a >> particular exception instance to record addition suppressed exceptions... > > If you are suggesting this as a way of making the suppression state > immutable, then I'd suggest that it might be preferable to model this > the same way that stacktraces are handled - they only need to be > optionally present. The same thing could be said for suppressed-exceptions. > > David > From John.Coomes at oracle.com Mon Aug 23 14:10:24 2010 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 23 Aug 2010 14:10:24 -0700 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <4C71B142.1000405@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> <4C71B142.1000405@oracle.com> Message-ID: <19570.58304.571986.204774@oracle.com> David Holmes (David.Holmes at oracle.com) wrote: > Here's the official OpenJKDK webrev for this: > > http://cr.openjdk.java.net/~dholmes/6978641/ Hi David, Looks good to me, aside from one syntax nit: I find it hard to read when control flow is embedded in macros like DEBUG_ONLY(), PRODUCT_ONLY(), etc. Using a separate variable is easier to read and also can be useful in the debugger, e.g., bool chk_bounds = NOT_DEBUG(os::Linux::is_initial_thread()) DEBUG_ONLY(true); if (chk_bounds && get_stack_bounds(&stack_extent, &stack_base)) { assert(...); -John > If I can add you both as reviewers that would be great. > > Coleen can you send me details on which release/build I should use in > the CR and also if there is any special "magic" I need to submit via JPRT. > > Thanks, > David > > Coleen Phillimore said the following on 08/20/10 23:15: > > > > This change looks fine to me and yes, thanks for pointing out that I did > > add the test. > > > > Coleen > > > > Andrew Haley wrote: > >> On 08/19/2010 04:49 AM, David Holmes wrote: > >> > >> > >>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp > >>> --- a/src/os/linux/vm/os_linux.cpp > >>> +++ b/src/os/linux/vm/os_linux.cpp > >>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint > >>> // where we're going to put our guard pages, truncate the mapping at > >>> // that point by munmap()ping it. This ensures that when we later > >>> // munmap() the guard pages we don't leave a hole in the stack > >>> -// mapping. > >>> +// mapping. This only affects the main/initial thread, but guard > >>> +// against future OS changes > >>> bool os::create_stack_guard_pages(char* addr, size_t size) { > >>> uintptr_t stack_extent, stack_base; > >>> - if (get_stack_bounds(&stack_extent, &stack_base)) { > >>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) > >>> get_stack_bounds(&stack_extent, &stack_base)) { > >>> + assert(os::Linux::is_initial_thread(), "growable stack in > >>> non-initial thread"); > >>> if (stack_extent < (uintptr_t)addr) > >>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); > >>> } > >>> > >> > >> Is stack_extent initialized here in NOT_DEBUG mode? > >> > >> > >>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* > >>> } > >>> > >>> // If this is a growable mapping, remove the guard pages entirely by > >>> -// munmap()ping them. If not, just call uncommit_memory(). > >>> +// munmap()ping them. If not, just call uncommit_memory(). This only > >>> +// affects the main/initial thread, but guard against future OS changes > >>> bool os::remove_stack_guard_pages(char* addr, size_t size) { > >>> uintptr_t stack_extent, stack_base; > >>> - if (get_stack_bounds(&stack_extent, &stack_base)) { > >>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) > >>> get_stack_bounds(&stack_extent, &stack_base)) { > >>> + assert(os::Linux::is_initial_thread(), "growable stack in > >>> non-initial thread"); > >>> + > >>> return ::munmap(addr, size) == 0; > >>> } > >> > >> This is basically a good compromise, I think. > >> > >> Andrew. > >> From daniel.daugherty at oracle.com Mon Aug 23 16:35:29 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 23 Aug 2010 23:35:29 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20100823233534.E25C6473D0@hg.openjdk.java.net> Changeset: f8c5d1bdaad4 Author: ptisnovs Date: 2010-08-19 14:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f8c5d1bdaad4 6885308: The incorrect -XX:StackRedPages, -XX:StackShadowPages, -XX:StackYellowPages could cause VM crash Summary: Test minimal stack sizes given (also fixed linux compilation error) Reviewed-by: never, phh, coleenp ! src/share/vm/memory/allocation.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: ebfb7c68865e Author: dcubed Date: 2010-08-23 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ebfb7c68865e Merge ! src/share/vm/memory/allocation.cpp ! src/share/vm/runtime/arguments.cpp From David.Holmes at oracle.com Mon Aug 23 22:38:53 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 24 Aug 2010 15:38:53 +1000 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <19570.58304.571986.204774@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> <4C71B142.1000405@oracle.com> <19570.58304.571986.204774@oracle.com> Message-ID: <4C735AED.6000307@oracle.com> John Coomes said the following on 08/24/10 07:10: > David Holmes (David.Holmes at oracle.com) wrote: >> Here's the official OpenJKDK webrev for this: >> >> http://cr.openjdk.java.net/~dholmes/6978641/ > > Hi David, > > Looks good to me, aside from one syntax nit: I find it hard to read > when control flow is embedded in macros like DEBUG_ONLY(), > PRODUCT_ONLY(), etc. Using a separate variable is easier to read and > also can be useful in the debugger, e.g., > > bool chk_bounds = NOT_DEBUG(os::Linux::is_initial_thread()) DEBUG_ONLY(true); > if (chk_bounds && get_stack_bounds(&stack_extent, &stack_base)) { > assert(...); Thanks John, I've implemented your suggestion - webrev updated. David > -John > >> If I can add you both as reviewers that would be great. >> >> Coleen can you send me details on which release/build I should use in >> the CR and also if there is any special "magic" I need to submit via JPRT. >> >> Thanks, >> David >> >> Coleen Phillimore said the following on 08/20/10 23:15: >>> This change looks fine to me and yes, thanks for pointing out that I did >>> add the test. >>> >>> Coleen >>> >>> Andrew Haley wrote: >>>> On 08/19/2010 04:49 AM, David Holmes wrote: >>>> >>>> >>>>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp >>>>> --- a/src/os/linux/vm/os_linux.cpp >>>>> +++ b/src/os/linux/vm/os_linux.cpp >>>>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint >>>>> // where we're going to put our guard pages, truncate the mapping at >>>>> // that point by munmap()ping it. This ensures that when we later >>>>> // munmap() the guard pages we don't leave a hole in the stack >>>>> -// mapping. >>>>> +// mapping. This only affects the main/initial thread, but guard >>>>> +// against future OS changes >>>>> bool os::create_stack_guard_pages(char* addr, size_t size) { >>>>> uintptr_t stack_extent, stack_base; >>>>> - if (get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) >>>>> get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>> non-initial thread"); >>>>> if (stack_extent < (uintptr_t)addr) >>>>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); >>>>> } >>>>> >>>> Is stack_extent initialized here in NOT_DEBUG mode? >>>> >>>> >>>>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* >>>>> } >>>>> >>>>> // If this is a growable mapping, remove the guard pages entirely by >>>>> -// munmap()ping them. If not, just call uncommit_memory(). >>>>> +// munmap()ping them. If not, just call uncommit_memory(). This only >>>>> +// affects the main/initial thread, but guard against future OS changes >>>>> bool os::remove_stack_guard_pages(char* addr, size_t size) { >>>>> uintptr_t stack_extent, stack_base; >>>>> - if (get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) >>>>> get_stack_bounds(&stack_extent, &stack_base)) { >>>>> + assert(os::Linux::is_initial_thread(), "growable stack in >>>>> non-initial thread"); >>>>> + >>>>> return ::munmap(addr, size) == 0; >>>>> } >>>> This is basically a good compromise, I think. >>>> >>>> Andrew. >>>> > From doko at ubuntu.com Mon Aug 23 23:59:41 2010 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 24 Aug 2010 08:59:41 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX Message-ID: <4C736DDD.9040009@ubuntu.com> hotspot uses overlong command lines, and the build will fail when building on a machine where SC_ARG_MAX is limited. This patch works around this limitation by using a file list for compiling the agent classes, and generating the file list with Makefile features instead of shell code. Matthias -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: too-many-args-ftbfs.diff Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100824/f0d2844e/attachment.ksh From christian.thalinger at oracle.com Tue Aug 24 06:37:41 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 24 Aug 2010 15:37:41 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C736DDD.9040009@ubuntu.com> References: <4C736DDD.9040009@ubuntu.com> Message-ID: <1282657061.1282.3.camel@macbook> [Moved distro-pkg-dev on Bcc.] On Tue, 2010-08-24 at 08:59 +0200, Matthias Klose wrote: > hotspot uses overlong command lines, and the build will fail when building on a > machine where SC_ARG_MAX is limited. > > This patch works around this limitation by using a file list for compiling the > agent classes, and generating the file list with Makefile features instead of > shell code. I don't know very much about building the agent but this seems like a good patch to me. I will give it a try... -- Christian From omajid at redhat.com Tue Aug 24 07:25:48 2010 From: omajid at redhat.com (Omair Majid) Date: Tue, 24 Aug 2010 10:25:48 -0400 Subject: trying to fix 6843484 (os::commit_memory() failures are not handled properly on linux) In-Reply-To: <87k4nq4fx9.fsf@mid.deneb.enyo.de> References: <4C695E47.3040909@redhat.com> <87k4nq4fx9.fsf@mid.deneb.enyo.de> Message-ID: <4C73D66C.2070601@redhat.com> Hi Florian, On 08/16/2010 01:37 PM, Florian Weimer wrote: > * Omair Majid: > >> Hi, >> >> I have been trying to fix 6843484. The bug relies on exact behaviour >> of mmap(2) on linux. I have asked for help from kernel developers and >> they have suggested that this is not a bug. Just so that I am clear, >> here is what I understood from the bug report: >> >> The bug happens if hotspot does >> (1) mmap(ADDR,..., MAP_NORESERVE,...) = succeeds >> followed by >> (2) mmap(ADDR, .....) = fails >> in which case the map from (1) is lost. > > You should change that to mmap(PROT_NONE) followed by memprotect(). > It has got the added benefit of better working with > vm.overcommit_memory=2, too. 8-) Thanks for that advice! However my main problem is still reproducing the bug. As far as I can tell it can not be reproduced at all. Thanks, Omair From John.Coomes at oracle.com Tue Aug 24 09:31:32 2010 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 24 Aug 2010 09:31:32 -0700 Subject: Request for review: 6978641 ( was Re: Request for approval: 6929067: Stack guard pages should be removed when thread is detached) In-Reply-To: <4C735AED.6000307@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4C6897B7.7090807@oracle.com> <4C68A668.2000000@oracle.com> <4C68F9FF.9080700@redhat.com> <4C69C268.8030803@oracle.com> <4C6A44DC.1090703@redhat.com> <4C6C6FBF.3080504@oracle.com> <4C6CA9D0.3010904@oracle.com> <4C6E3E15.6040509@redhat.com> <4C6E7FF9.9040009@oracle.com> <4C71B142.1000405@oracle.com> <19570.58304.571986.204774@oracle.com> <4C735AED.6000307@oracle.com> Message-ID: <19571.62436.493144.455769@oracle.com> David Holmes (David.Holmes at oracle.com) wrote: > John Coomes said the following on 08/24/10 07:10: > > David Holmes (David.Holmes at oracle.com) wrote: > >> Here's the official OpenJKDK webrev for this: > >> > >> http://cr.openjdk.java.net/~dholmes/6978641/ > > > > Hi David, > > > > Looks good to me, aside from one syntax nit: I find it hard to read > > when control flow is embedded in macros like DEBUG_ONLY(), > > PRODUCT_ONLY(), etc. Using a separate variable is easier to read and > > also can be useful in the debugger, e.g., > > > > bool chk_bounds = NOT_DEBUG(os::Linux::is_initial_thread()) DEBUG_ONLY(true); > > if (chk_bounds && get_stack_bounds(&stack_extent, &stack_base)) { > > assert(...); > > Thanks John, I've implemented your suggestion - webrev updated. Looks good. -John > >> If I can add you both as reviewers that would be great. > >> > >> Coleen can you send me details on which release/build I should use in > >> the CR and also if there is any special "magic" I need to submit via JPRT. > >> > >> Thanks, > >> David > >> > >> Coleen Phillimore said the following on 08/20/10 23:15: > >>> This change looks fine to me and yes, thanks for pointing out that I did > >>> add the test. > >>> > >>> Coleen > >>> > >>> Andrew Haley wrote: > >>>> On 08/19/2010 04:49 AM, David Holmes wrote: > >>>> > >>>> > >>>>> diff -r f707b4c0c36f src/os/linux/vm/os_linux.cpp > >>>>> --- a/src/os/linux/vm/os_linux.cpp > >>>>> +++ b/src/os/linux/vm/os_linux.cpp > >>>>> @@ -2628,10 +2628,12 @@ get_stack_bounds(uintptr_t *bottom, uint > >>>>> // where we're going to put our guard pages, truncate the mapping at > >>>>> // that point by munmap()ping it. This ensures that when we later > >>>>> // munmap() the guard pages we don't leave a hole in the stack > >>>>> -// mapping. > >>>>> +// mapping. This only affects the main/initial thread, but guard > >>>>> +// against future OS changes > >>>>> bool os::create_stack_guard_pages(char* addr, size_t size) { > >>>>> uintptr_t stack_extent, stack_base; > >>>>> - if (get_stack_bounds(&stack_extent, &stack_base)) { > >>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) > >>>>> get_stack_bounds(&stack_extent, &stack_base)) { > >>>>> + assert(os::Linux::is_initial_thread(), "growable stack in > >>>>> non-initial thread"); > >>>>> if (stack_extent < (uintptr_t)addr) > >>>>> ::munmap((void*)stack_extent, (uintptr_t)addr - stack_extent); > >>>>> } > >>>>> > >>>> Is stack_extent initialized here in NOT_DEBUG mode? > >>>> > >>>> > >>>>> @@ -2640,10 +2642,13 @@ bool os::create_stack_guard_pages(char* > >>>>> } > >>>>> > >>>>> // If this is a growable mapping, remove the guard pages entirely by > >>>>> -// munmap()ping them. If not, just call uncommit_memory(). > >>>>> +// munmap()ping them. If not, just call uncommit_memory(). This only > >>>>> +// affects the main/initial thread, but guard against future OS changes > >>>>> bool os::remove_stack_guard_pages(char* addr, size_t size) { > >>>>> uintptr_t stack_extent, stack_base; > >>>>> - if (get_stack_bounds(&stack_extent, &stack_base)) { > >>>>> + if (NOT_DEBUG(os::Linux::is_initial_thread() &&) > >>>>> get_stack_bounds(&stack_extent, &stack_base)) { > >>>>> + assert(os::Linux::is_initial_thread(), "growable stack in > >>>>> non-initial thread"); > >>>>> + > >>>>> return ::munmap(addr, size) == 0; > >>>>> } > >>>> This is basically a good compromise, I think. > >>>> > >>>> Andrew. > >>>> > > From kelly.ohair at oracle.com Tue Aug 24 16:28:20 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 24 Aug 2010 16:28:20 -0700 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C736DDD.9040009@ubuntu.com> References: <4C736DDD.9040009@ubuntu.com> Message-ID: Looks ok to me. I think this is basically this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6561870 -kto On Aug 23, 2010, at 11:59 PM, Matthias Klose wrote: > hotspot uses overlong command lines, and the build will fail when > building on a machine where SC_ARG_MAX is limited. > > This patch works around this limitation by using a file list for > compiling the agent classes, and generating the file list with > Makefile features instead of shell code. > > Matthias > From daniel.daugherty at oracle.com Wed Aug 25 06:13:22 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Aug 2010 07:13:22 -0600 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: References: <4C736DDD.9040009@ubuntu.com> Message-ID: <4C7516F2.3090605@oracle.com> Moved distro-pkg-dev at ... to the Bcc list. Kelly, This is the right bug. I moved it to jvm/hotspot/svc_agent. Christian was planning to check out this patch. I'll check with him to see if he want me to take care of this via RT_Baseline. In either case, we'll have to push the change through JPRT and we'll set the contributed by line to Matthias... Dan On 8/24/2010 5:28 PM, Kelly O'Hair wrote: > Looks ok to me. I think this is basically this bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6561870 > > -kto > > On Aug 23, 2010, at 11:59 PM, Matthias Klose wrote: > >> hotspot uses overlong command lines, and the build will fail when >> building on a machine where SC_ARG_MAX is limited. >> >> This patch works around this limitation by using a file list for >> compiling the agent classes, and generating the file list with >> Makefile features instead of shell code. >> >> Matthias >> > From christian.thalinger at oracle.com Wed Aug 25 06:26:40 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Aug 2010 15:26:40 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C7516F2.3090605@oracle.com> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> Message-ID: <1282742800.28481.20.camel@macbook> On Wed, 2010-08-25 at 07:13 -0600, Daniel D. Daugherty wrote: > Moved distro-pkg-dev at ... to the Bcc list. > > Kelly, > > This is the right bug. I moved it to jvm/hotspot/svc_agent. > > Christian was planning to check out this patch. I'll check with > him to see if he want me to take care of this via RT_Baseline. > In either case, we'll have to push the change through JPRT and > we'll set the contributed by line to Matthias... Yes, please take care of it. I guess you know the Makefiles better than I do... -- Christian From daniel.daugherty at oracle.com Wed Aug 25 06:32:12 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Aug 2010 07:32:12 -0600 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <1282742800.28481.20.camel@macbook> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> Message-ID: <4C751B5C.4020500@oracle.com> On 8/25/2010 7:26 AM, Christian Thalinger wrote: > On Wed, 2010-08-25 at 07:13 -0600, Daniel D. Daugherty wrote: > >> Moved distro-pkg-dev at ... to the Bcc list. >> >> Kelly, >> >> This is the right bug. I moved it to jvm/hotspot/svc_agent. >> >> Christian was planning to check out this patch. I'll check with >> him to see if he want me to take care of this via RT_Baseline. >> In either case, we'll have to push the change through JPRT and >> we'll set the contributed by line to Matthias... >> > > Yes, please take care of it. OK. I've grabbed the bug. Can put you down as a code reviewer? Kelly, can put you down as a code reviewer also? > I guess you know the Makefiles better than I do... > I don't know about that, but it seem right that I should be the one to shepherd this one through the processes... :-) Dan From kelly.ohair at oracle.com Wed Aug 25 08:16:03 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 25 Aug 2010 08:16:03 -0700 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C751B5C.4020500@oracle.com> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> Message-ID: <5A9C3D7D-CAF0-478D-8D8F-F162D870443D@oracle.com> On Aug 25, 2010, at 6:32 AM, Daniel D. Daugherty wrote: > On 8/25/2010 7:26 AM, Christian Thalinger wrote: >> On Wed, 2010-08-25 at 07:13 -0600, Daniel D. Daugherty wrote: >> >>> Moved distro-pkg-dev at ... to the Bcc list. >>> >>> Kelly, >>> >>> This is the right bug. I moved it to jvm/hotspot/svc_agent. >>> >>> Christian was planning to check out this patch. I'll check with >>> him to see if he want me to take care of this via RT_Baseline. >>> In either case, we'll have to push the change through JPRT and >>> we'll set the contributed by line to Matthias... >>> >> >> Yes, please take care of it. > > OK. I've grabbed the bug. Can put you down as a code reviewer? > > Kelly, can put you down as a code reviewer also? Yes, It looked fine to me. And thanks for doing this. -kto > > >> I guess you know the Makefiles better than I do... >> > > I don't know about that, but it seem right that I should be > the one to shepherd this one through the processes... :-) > > Dan > From christian.thalinger at oracle.com Wed Aug 25 08:33:18 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Aug 2010 17:33:18 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C751B5C.4020500@oracle.com> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> Message-ID: <1282750398.32311.1.camel@macbook> On Wed, 2010-08-25 at 07:32 -0600, Daniel D. Daugherty wrote: > > Yes, please take care of it. > > OK. I've grabbed the bug. Can put you down as a code reviewer? Yes. The changes look good. Matthias, have you (or Canonical) signed the SCA? Sorry, I forgot. -- Christian From doko at ubuntu.com Wed Aug 25 08:39:19 2010 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 25 Aug 2010 17:39:19 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <1282750398.32311.1.camel@macbook> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> <1282750398.32311.1.camel@macbook> Message-ID: <4C753927.5040208@ubuntu.com> On 25.08.2010 17:33, Christian Thalinger wrote: > On Wed, 2010-08-25 at 07:32 -0600, Daniel D. Daugherty wrote: >>> Yes, please take care of it. >> >> OK. I've grabbed the bug. Can put you down as a code reviewer? > > Yes. The changes look good. > > Matthias, have you (or Canonical) signed the SCA? Sorry, I forgot. Yes, I did. Matthias From ahughes at redhat.com Wed Aug 25 08:49:07 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 25 Aug 2010 16:49:07 +0100 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <1282750398.32311.1.camel@macbook> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> <1282750398.32311.1.camel@macbook> Message-ID: On 25 August 2010 16:33, Christian Thalinger wrote: > On Wed, 2010-08-25 at 07:32 -0600, Daniel D. Daugherty wrote: >> > Yes, please take care of it. >> >> OK. I've grabbed the bug. Can put you down as a code reviewer? > > Yes. ?The changes look good. > > Matthias, have you (or Canonical) signed the SCA? ?Sorry, I forgot. > > -- Christian > > https://sca.dev.java.net/CA_signatories.htm is your friend :-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA? 7927 142C 2591 94EF D9D8 From kelly.ohair at oracle.com Wed Aug 25 08:52:39 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 25 Aug 2010 08:52:39 -0700 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <1282750398.32311.1.camel@macbook> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> <1282750398.32311.1.camel@macbook> Message-ID: <472FFBCB-9D31-4880-95BC-268E7FA3CE3B@oracle.com> On Aug 25, 2010, at 8:33 AM, Christian Thalinger wrote: > On Wed, 2010-08-25 at 07:32 -0600, Daniel D. Daugherty wrote: >>> Yes, please take care of it. >> >> OK. I've grabbed the bug. Can put you down as a code reviewer? > > Yes. The changes look good. > > Matthias, have you (or Canonical) signed the SCA? Sorry, I forgot. > > -- Christian > Looks like it. As far as I know, this is still the official SCA list: https://sca.dev.java.net/CA_signatories.htm -kto From christian.thalinger at oracle.com Wed Aug 25 08:53:00 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Aug 2010 17:53:00 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> <1282750398.32311.1.camel@macbook> Message-ID: <1282751580.32311.2.camel@macbook> On Wed, 2010-08-25 at 16:49 +0100, Dr Andrew John Hughes wrote: > On 25 August 2010 16:33, Christian Thalinger > wrote: > > On Wed, 2010-08-25 at 07:32 -0600, Daniel D. Daugherty wrote: > >> > Yes, please take care of it. > >> > >> OK. I've grabbed the bug. Can put you down as a code reviewer? > > > > Yes. The changes look good. > > > > Matthias, have you (or Canonical) signed the SCA? Sorry, I forgot. > > > > -- Christian > > > > > > https://sca.dev.java.net/CA_signatories.htm is your friend :-) Thanks! I couldn't find the URL anymore :-) -- Christian From daniel.daugherty at oracle.com Wed Aug 25 09:00:56 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Aug 2010 10:00:56 -0600 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C751B5C.4020500@oracle.com> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> Message-ID: <4C753E38.8070208@oracle.com> Thanks for the reviews Kelly and Christian. Is there a reason to not apply these changes to the solaris and windows versions also? I haven't looked yet, but I figured I would ask... Dan On 8/25/2010 7:32 AM, Daniel D. Daugherty wrote: > On 8/25/2010 7:26 AM, Christian Thalinger wrote: >> On Wed, 2010-08-25 at 07:13 -0600, Daniel D. Daugherty wrote: >> >>> Moved distro-pkg-dev at ... to the Bcc list. >>> >>> Kelly, >>> >>> This is the right bug. I moved it to jvm/hotspot/svc_agent. >>> >>> Christian was planning to check out this patch. I'll check with >>> him to see if he want me to take care of this via RT_Baseline. >>> In either case, we'll have to push the change through JPRT and >>> we'll set the contributed by line to Matthias... >>> >> >> Yes, please take care of it. > > OK. I've grabbed the bug. Can put you down as a code reviewer? > > Kelly, can put you down as a code reviewer also? > > >> I guess you know the Makefiles better than I do... >> > > I don't know about that, but it seem right that I should be > the one to shepherd this one through the processes... :-) > > Dan > > From christian.thalinger at oracle.com Wed Aug 25 09:11:23 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Aug 2010 18:11:23 +0200 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <4C753E38.8070208@oracle.com> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> <4C753E38.8070208@oracle.com> Message-ID: <1282752683.32311.4.camel@macbook> On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote: > Thanks for the reviews Kelly and Christian. > > Is there a reason to not apply these changes to the solaris and > windows versions also? I haven't looked yet, but I figured I > would ask... Yeah, I also thought about this for Solaris and it should work there as on Linux. Don't know about Windows, though. -- Christian From daniel.daugherty at oracle.com Wed Aug 25 09:22:35 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Aug 2010 10:22:35 -0600 Subject: [patch] fix hotspot build with small SC_ARG_MAX In-Reply-To: <1282752683.32311.4.camel@macbook> References: <4C736DDD.9040009@ubuntu.com> <4C7516F2.3090605@oracle.com> <1282742800.28481.20.camel@macbook> <4C751B5C.4020500@oracle.com> <4C753E38.8070208@oracle.com> <1282752683.32311.4.camel@macbook> Message-ID: <4C75434B.7080307@oracle.com> On 8/25/2010 10:11 AM, Christian Thalinger wrote: > On Wed, 2010-08-25 at 10:00 -0600, Daniel D. Daugherty wrote: > >> Thanks for the reviews Kelly and Christian. >> >> Is there a reason to not apply these changes to the solaris and >> windows versions also? I haven't looked yet, but I figured I >> would ask... >> > > Yeah, I also thought about this for Solaris and it should work there as > on Linux. Don't know about Windows, though. > Looks like Windows already uses a "make" construct instead of running into the shell command line limitation: > $(GENERATED)\sa-jdi.jar: $(AGENT_FILES1:/=\) $(AGENT_FILES2:/=\) > @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath > $(SA_CLASSPATH) -so > urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES1:/=\) > @$(COMPILE_JAVAC) -source 1.4 -target 1.4 -classpath > $(SA_CLASSPATH) -so > urcepath $(AGENT_SRC_DIR) -d $(SA_CLASSDIR) $(AGENT_FILES2:/=\) I also think this is an "nmake" Makefile instead of a GNU Makefile. I think I'll look at applying the changes to the Solaris Makefile and leave the Windows stuff alone :-) Dan From idealistyy at gmail.com Thu Aug 26 10:23:23 2010 From: idealistyy at gmail.com (Yi Yang) Date: Thu, 26 Aug 2010 10:23:23 -0700 Subject: LinkResolver question Message-ID: Hello everyone, I added a printf statement into the LinkResolver::resolve_invokestatic(), hoping that it would hook a static method call when a invokestatic bytecode happens. However, it prints out more statements than I expected, and the .class file tested actually doesn't have any static method calls (according to javap also). So, my question is, why does resolve_invokestatic() be called even if there is no invokestatic bytecode? Also, do you think adding instrumentation hooks into LinkResolver is a good idea to record the method calls information during the runtime? Thank you. Best, Yi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100826/3a23e4b8/attachment.html From tom.rodriguez at oracle.com Thu Aug 26 14:25:00 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 26 Aug 2010 21:25:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20100826212508.58F8947478@hg.openjdk.java.net> Changeset: 4b29a725c43c Author: jrose Date: 2010-08-20 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b29a725c43c 6912064: type profiles need to be exploited more for dynamic language support Reviewed-by: kvn ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/globals.hpp Changeset: 53dbe853fb3a Author: kvn Date: 2010-08-23 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/53dbe853fb3a 6896381: CTW fails share/vm/ci/bcEscapeAnalyzer.cpp:99, assert(_stack_height < _max_stack,"stack overflow") Summary: Check constant Tag type instead of calling get_constant(). Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 3e8fbc61cee8 Author: twisti Date: 2010-08-25 05:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3e8fbc61cee8 6978355: renaming for 6961697 Summary: This is the renaming part of 6961697 to keep the actual changes small for review. Reviewed-by: kvn, never ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/c1/Runtime1.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FindInCodeCachePanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/icache.cpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b4099f5786da Author: never Date: 2010-08-25 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b4099f5786da Merge ! src/share/vm/runtime/globals.hpp From nagy.mostafa at gmail.com Thu Aug 26 14:31:04 2010 From: nagy.mostafa at gmail.com (Nagy Mostafa) Date: Thu, 26 Aug 2010 14:31:04 -0700 Subject: LinkResolver question In-Reply-To: References: Message-ID: On Thu, Aug 26, 2010 at 10:23 AM, Yi Yang wrote: > Hello everyone, > > I added a printf statement into the LinkResolver::resolve_invokestatic(), > hoping that it would hook a static method call when a invokestatic bytecode > happens. However, it prints out more statements than I expected, and the > .class file tested actually doesn't have any static method calls (according > to javap also). So, my question is, why does resolve_invokestatic() be > called even if there is no invokestatic bytecode? > This is because not just your code gets executed. Other Java class library and initialization code gets executed as well. > Also, do you think adding instrumentation hooks into LinkResolver is a good > idea to record the method calls information during the runtime? Thank you. > > That would be true only if you are running in interpreter-only mode (-Xint). Compiled code, however, has to be instrumented or you can write a JVMTI agent for that purpose but from my experience profiling method calls/returns is extremely slow. > Best, > Yi > - nagy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100826/913bad42/attachment.html From doug.simon at oracle.com Thu Aug 26 23:25:56 2010 From: doug.simon at oracle.com (Douglas Simon) Date: Fri, 27 Aug 2010 08:25:56 +0200 Subject: GNU_STACK ELF header Message-ID: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> As a result of stack overflow detection breaking in Maxine on Linux, I learnt about this ELF header. My experience is described here: http://blogs.sun.com/dns/entry/stacks_with_split_personalities Is this issue known in HotSpot/JDK? If so, how exactly is the header being omitted from the HotSpot and JDK libraries and executables? -Doug From doug.simon at oracle.com Thu Aug 26 23:25:56 2010 From: doug.simon at oracle.com (Douglas Simon) Date: Fri, 27 Aug 2010 08:25:56 +0200 Subject: GNU_STACK ELF header Message-ID: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> As a result of stack overflow detection breaking in Maxine on Linux, I learnt about this ELF header. My experience is described here: http://blogs.sun.com/dns/entry/stacks_with_split_personalities Is this issue known in HotSpot/JDK? If so, how exactly is the header being omitted from the HotSpot and JDK libraries and executables? -Doug From David.Holmes at oracle.com Fri Aug 27 04:10:45 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 27 Aug 2010 21:10:45 +1000 Subject: GNU_STACK ELF header In-Reply-To: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> Message-ID: <4C779D35.3010708@oracle.com> Hi Doug, Douglas Simon said the following on 08/27/10 16:25: > As a result of stack overflow detection breaking in Maxine on Linux, > I learnt about this ELF header. My experience is described here: > http://blogs.sun.com/dns/entry/stacks_with_split_personalities > > Is this issue known in HotSpot/JDK? If so, how exactly is the header > being omitted from the HotSpot and JDK libraries and executables? I could be mistaken but I think these kinds of issues (it occurred with exec-shield in the past - see bug 5099186) are why the Java launcher creates the JVM in a new thread (and why we recommend custom launchers do the same). That ways any OS machinations with the initial thread's stack don't impact on the JVM's stack management. Cheers, David Holmes From David.Holmes at oracle.com Fri Aug 27 04:10:45 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 27 Aug 2010 21:10:45 +1000 Subject: GNU_STACK ELF header In-Reply-To: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> Message-ID: <4C779D35.3010708@oracle.com> Hi Doug, Douglas Simon said the following on 08/27/10 16:25: > As a result of stack overflow detection breaking in Maxine on Linux, > I learnt about this ELF header. My experience is described here: > http://blogs.sun.com/dns/entry/stacks_with_split_personalities > > Is this issue known in HotSpot/JDK? If so, how exactly is the header > being omitted from the HotSpot and JDK libraries and executables? I could be mistaken but I think these kinds of issues (it occurred with exec-shield in the past - see bug 5099186) are why the Java launcher creates the JVM in a new thread (and why we recommend custom launchers do the same). That ways any OS machinations with the initial thread's stack don't impact on the JVM's stack management. Cheers, David Holmes From kelly.ohair at oracle.com Fri Aug 27 08:31:54 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 27 Aug 2010 08:31:54 -0700 Subject: GNU_STACK ELF header In-Reply-To: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> Message-ID: <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> Interesting. Had not heard about this new Elf header. The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty old. 32bit: gcc (GCC) 3.2.1-7a (J2SE release) 64bit: gcc (GCC) 3.2.2 (SuSE Linux) For jdk7, we are using the gcc compiler provided with Fedora 9, gcc 4.3.0 -kto On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: > As a result of stack overflow detection breaking in Maxine on Linux, > I learnt about this ELF header. My experience is described here: http://blogs.sun.com/dns/entry/stacks_with_split_personalities > > Is this issue known in HotSpot/JDK? If so, how exactly is the header > being omitted from the HotSpot and JDK libraries and executables? > > -Doug From kelly.ohair at oracle.com Fri Aug 27 08:31:54 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 27 Aug 2010 08:31:54 -0700 Subject: GNU_STACK ELF header In-Reply-To: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> Message-ID: <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> Interesting. Had not heard about this new Elf header. The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty old. 32bit: gcc (GCC) 3.2.1-7a (J2SE release) 64bit: gcc (GCC) 3.2.2 (SuSE Linux) For jdk7, we are using the gcc compiler provided with Fedora 9, gcc 4.3.0 -kto On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: > As a result of stack overflow detection breaking in Maxine on Linux, > I learnt about this ELF header. My experience is described here: http://blogs.sun.com/dns/entry/stacks_with_split_personalities > > Is this issue known in HotSpot/JDK? If so, how exactly is the header > being omitted from the HotSpot and JDK libraries and executables? > > -Doug From ahughes at redhat.com Fri Aug 27 10:49:15 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 27 Aug 2010 18:49:15 +0100 Subject: GNU_STACK ELF header In-Reply-To: <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> Message-ID: On 27 August 2010 16:31, Kelly O'Hair wrote: > Interesting. Had not heard about this new Elf header. > > The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty > old. > > 32bit: > gcc (GCC) 3.2.1-7a (J2SE release) > > 64bit: > gcc (GCC) 3.2.2 (SuSE Linux) > > For jdk7, we are using the gcc compiler provided with Fedora 9, ?gcc 4.3.0 > > -kto > > > On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: > >> As a result of stack overflow detection breaking in Maxine on Linux, I >> learnt about this ELF header. My experience is described here: >> http://blogs.sun.com/dns/entry/stacks_with_split_personalities >> >> Is this issue known in HotSpot/JDK? If so, how exactly is the header being >> omitted from the HotSpot and JDK libraries and executables? >> >> -Doug > > This was discussed last year: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch. GCC 4.3 is the earliest version of GCC IcedTea has been built with, to my knowledge, rather than the latest. I'm currently building with GCC 4.5.1. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA? 7927 142C 2591 94EF D9D8 From doug.simon at oracle.com Fri Aug 27 13:17:38 2010 From: doug.simon at oracle.com (Douglas Simon) Date: Fri, 27 Aug 2010 22:17:38 +0200 Subject: GNU_STACK ELF header In-Reply-To: References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> Message-ID: <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> On Aug 27, 2010, at 7:49 PM, Dr Andrew John Hughes wrote: > On 27 August 2010 16:31, Kelly O'Hair wrote: >> Interesting. Had not heard about this new Elf header. >> >> The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty >> old. >> >> 32bit: >> gcc (GCC) 3.2.1-7a (J2SE release) >> >> 64bit: >> gcc (GCC) 3.2.2 (SuSE Linux) >> >> For jdk7, we are using the gcc compiler provided with Fedora 9, gcc 4.3.0 >> >> -kto >> >> >> On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: >> >>> As a result of stack overflow detection breaking in Maxine on Linux, I >>> learnt about this ELF header. My experience is described here: >>> http://blogs.sun.com/dns/entry/stacks_with_split_personalities >>> >>> Is this issue known in HotSpot/JDK? If so, how exactly is the header being >>> omitted from the HotSpot and JDK libraries and executables? >>> >>> -Doug >> >> > > This was discussed last year: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html > and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch. > > GCC 4.3 is the earliest version of GCC IcedTea has been built with, to > my knowledge, rather than the latest. I'm currently building with GCC > 4.5.1. If I understand the patch correctly, it still leaves an IcedTea process in the position where all stacks are made executable if an 'executable-stack' native library is loaded. As far as I can tell, there's no way to really avoid this given the behaviour of the dynamic linker on Linux. Or am I missing something? -Doug From doug.simon at oracle.com Fri Aug 27 13:17:38 2010 From: doug.simon at oracle.com (Douglas Simon) Date: Fri, 27 Aug 2010 22:17:38 +0200 Subject: GNU_STACK ELF header In-Reply-To: References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> Message-ID: <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> On Aug 27, 2010, at 7:49 PM, Dr Andrew John Hughes wrote: > On 27 August 2010 16:31, Kelly O'Hair wrote: >> Interesting. Had not heard about this new Elf header. >> >> The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty >> old. >> >> 32bit: >> gcc (GCC) 3.2.1-7a (J2SE release) >> >> 64bit: >> gcc (GCC) 3.2.2 (SuSE Linux) >> >> For jdk7, we are using the gcc compiler provided with Fedora 9, gcc 4.3.0 >> >> -kto >> >> >> On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: >> >>> As a result of stack overflow detection breaking in Maxine on Linux, I >>> learnt about this ELF header. My experience is described here: >>> http://blogs.sun.com/dns/entry/stacks_with_split_personalities >>> >>> Is this issue known in HotSpot/JDK? If so, how exactly is the header being >>> omitted from the HotSpot and JDK libraries and executables? >>> >>> -Doug >> >> > > This was discussed last year: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html > and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch. > > GCC 4.3 is the earliest version of GCC IcedTea has been built with, to > my knowledge, rather than the latest. I'm currently building with GCC > 4.5.1. If I understand the patch correctly, it still leaves an IcedTea process in the position where all stacks are made executable if an 'executable-stack' native library is loaded. As far as I can tell, there's no way to really avoid this given the behaviour of the dynamic linker on Linux. Or am I missing something? -Doug From ahughes at redhat.com Fri Aug 27 13:40:08 2010 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 27 Aug 2010 21:40:08 +0100 Subject: GNU_STACK ELF header In-Reply-To: <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> Message-ID: On 27 August 2010 21:17, Douglas Simon wrote: > > On Aug 27, 2010, at 7:49 PM, Dr Andrew John Hughes wrote: > >> On 27 August 2010 16:31, Kelly O'Hair wrote: >>> Interesting. Had not heard about this new Elf header. >>> >>> The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty >>> old. >>> >>> 32bit: >>> gcc (GCC) 3.2.1-7a (J2SE release) >>> >>> 64bit: >>> gcc (GCC) 3.2.2 (SuSE Linux) >>> >>> For jdk7, we are using the gcc compiler provided with Fedora 9, ?gcc 4.3.0 >>> >>> -kto >>> >>> >>> On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: >>> >>>> As a result of stack overflow detection breaking in Maxine on Linux, I >>>> learnt about this ELF header. My experience is described here: >>>> http://blogs.sun.com/dns/entry/stacks_with_split_personalities >>>> >>>> Is this issue known in HotSpot/JDK? If so, how exactly is the header being >>>> omitted from the HotSpot and JDK libraries and executables? >>>> >>>> -Doug >>> >>> >> >> This was discussed last year: >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html >> and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch. >> >> GCC 4.3 is the earliest version of GCC IcedTea has been built with, to >> my knowledge, rather than the latest. ?I'm currently building with GCC >> 4.5.1. > > > If I understand the patch correctly, it still leaves an IcedTea process in the position where all stacks are made executable if an 'executable-stack' native library is loaded. As far as I can tell, there's no way to really avoid this given the behaviour of the dynamic linker on Linux. Or am I missing something? > > -Doug > > I'm afraid I don't know the details, only that this patch means the VM no longer has executable stack. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA? 7927 142C 2591 94EF D9D8 From doug.simon at oracle.com Sat Aug 28 06:42:18 2010 From: doug.simon at oracle.com (Douglas Simon) Date: Sat, 28 Aug 2010 15:42:18 +0200 Subject: GNU_STACK ELF header In-Reply-To: References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> Message-ID: <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> On Aug 27, 2010, at 10:40 PM, Dr Andrew John Hughes wrote: > On 27 August 2010 21:17, Douglas Simon wrote: >> >> On Aug 27, 2010, at 7:49 PM, Dr Andrew John Hughes wrote: >> >>> On 27 August 2010 16:31, Kelly O'Hair wrote: >>>> Interesting. Had not heard about this new Elf header. >>>> >>>> The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty >>>> old. >>>> >>>> 32bit: >>>> gcc (GCC) 3.2.1-7a (J2SE release) >>>> >>>> 64bit: >>>> gcc (GCC) 3.2.2 (SuSE Linux) >>>> >>>> For jdk7, we are using the gcc compiler provided with Fedora 9, gcc 4.3.0 >>>> >>>> -kto >>>> >>>> >>>> On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: >>>> >>>>> As a result of stack overflow detection breaking in Maxine on Linux, I >>>>> learnt about this ELF header. My experience is described here: >>>>> http://blogs.sun.com/dns/entry/stacks_with_split_personalities >>>>> >>>>> Is this issue known in HotSpot/JDK? If so, how exactly is the header being >>>>> omitted from the HotSpot and JDK libraries and executables? >>>>> >>>>> -Doug >>>> >>>> >>> >>> This was discussed last year: >>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html >>> and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch. >>> >>> GCC 4.3 is the earliest version of GCC IcedTea has been built with, to >>> my knowledge, rather than the latest. I'm currently building with GCC >>> 4.5.1. >> >> >> If I understand the patch correctly, it still leaves an IcedTea process in the position where all stacks are made executable if an 'executable-stack' native library is loaded. As far as I can tell, there's no way to really avoid this given the behaviour of the dynamic linker on Linux. Or am I missing something? >> >> -Doug >> >> > > I'm afraid I don't know the details, only that this patch means the VM > no longer has executable stack. This means that stack overflow detection is broken on IcedTea by a Java application that loads an 'executable-stack' native library. I submitted a test case in the following bug report: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/625820 I think the long term solution is to modify the __make_stacks_executable function in libc/nptl/allocatestack.c such that it only adds the PROT_EXEC bit to each thread's stack and leaves the current values for the PROT_READ and PROT_WRITE bits as is. -Doug From doug.simon at oracle.com Sat Aug 28 06:42:18 2010 From: doug.simon at oracle.com (Douglas Simon) Date: Sat, 28 Aug 2010 15:42:18 +0200 Subject: GNU_STACK ELF header In-Reply-To: References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> Message-ID: <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> On Aug 27, 2010, at 10:40 PM, Dr Andrew John Hughes wrote: > On 27 August 2010 21:17, Douglas Simon wrote: >> >> On Aug 27, 2010, at 7:49 PM, Dr Andrew John Hughes wrote: >> >>> On 27 August 2010 16:31, Kelly O'Hair wrote: >>>> Interesting. Had not heard about this new Elf header. >>>> >>>> The Linux systems and gcc compilers used for jdk5 and jdk6 builds is pretty >>>> old. >>>> >>>> 32bit: >>>> gcc (GCC) 3.2.1-7a (J2SE release) >>>> >>>> 64bit: >>>> gcc (GCC) 3.2.2 (SuSE Linux) >>>> >>>> For jdk7, we are using the gcc compiler provided with Fedora 9, gcc 4.3.0 >>>> >>>> -kto >>>> >>>> >>>> On Aug 26, 2010, at 11:25 PM, Douglas Simon wrote: >>>> >>>>> As a result of stack overflow detection breaking in Maxine on Linux, I >>>>> learnt about this ELF header. My experience is described here: >>>>> http://blogs.sun.com/dns/entry/stacks_with_split_personalities >>>>> >>>>> Is this issue known in HotSpot/JDK? If so, how exactly is the header being >>>>> omitted from the HotSpot and JDK libraries and executables? >>>>> >>>>> -Doug >>>> >>>> >>> >>> This was discussed last year: >>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/006995.html >>> and is patched in IcedTea6 by icedtea-gcc-stack-markings.patch. >>> >>> GCC 4.3 is the earliest version of GCC IcedTea has been built with, to >>> my knowledge, rather than the latest. I'm currently building with GCC >>> 4.5.1. >> >> >> If I understand the patch correctly, it still leaves an IcedTea process in the position where all stacks are made executable if an 'executable-stack' native library is loaded. As far as I can tell, there's no way to really avoid this given the behaviour of the dynamic linker on Linux. Or am I missing something? >> >> -Doug >> >> > > I'm afraid I don't know the details, only that this patch means the VM > no longer has executable stack. This means that stack overflow detection is broken on IcedTea by a Java application that loads an 'executable-stack' native library. I submitted a test case in the following bug report: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/625820 I think the long term solution is to modify the __make_stacks_executable function in libc/nptl/allocatestack.c such that it only adds the PROT_EXEC bit to each thread's stack and leaves the current values for the PROT_READ and PROT_WRITE bits as is. -Doug From David.Holmes at oracle.com Sat Aug 28 16:03:01 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 29 Aug 2010 09:03:01 +1000 Subject: GNU_STACK ELF header In-Reply-To: <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> Message-ID: <4C7995A5.2050408@oracle.com> Douglas Simon said the following on 08/28/10 23:42: > I think the long term solution is to modify the > __make_stacks_executable function in libc/nptl/allocatestack.c such > that it only adds the PROT_EXEC bit to each thread's stack and leaves > the current values for the PROT_READ and PROT_WRITE bits as is. I find it hard to believe that they would overwrite the permission bits rather than augment them in the first place. I can't wait to find out what justification they think they had for doing that. :( David From David.Holmes at oracle.com Sat Aug 28 16:03:01 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 29 Aug 2010 09:03:01 +1000 Subject: GNU_STACK ELF header In-Reply-To: <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> Message-ID: <4C7995A5.2050408@oracle.com> Douglas Simon said the following on 08/28/10 23:42: > I think the long term solution is to modify the > __make_stacks_executable function in libc/nptl/allocatestack.c such > that it only adds the PROT_EXEC bit to each thread's stack and leaves > the current values for the PROT_READ and PROT_WRITE bits as is. I find it hard to believe that they would overwrite the permission bits rather than augment them in the first place. I can't wait to find out what justification they think they had for doing that. :( David From David.Holmes at oracle.com Sun Aug 29 04:39:38 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 29 Aug 2010 21:39:38 +1000 Subject: GNU_STACK ELF header In-Reply-To: <4C7995A5.2050408@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> <4C7995A5.2050408@oracle.com> Message-ID: <4C7A46FA.7070709@oracle.com> David Holmes said the following on 08/29/10 09:03: > Douglas Simon said the following on 08/28/10 23:42: >> I think the long term solution is to modify the >> __make_stacks_executable function in libc/nptl/allocatestack.c such >> that it only adds the PROT_EXEC bit to each thread's stack and leaves >> the current values for the PROT_READ and PROT_WRITE bits as is. > > I find it hard to believe that they would overwrite the permission bits > rather than augment them in the first place. I can't wait to find out > what justification they think they had for doing that. :( Looks like it is because the OS gives no way to do otherwise :( mprotect doesn't allow you to add to the existing permissions only set them - and there's no API that I can see to query page permissions. There's some interesting discussion in this LK thread: http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-02/0145.html David From David.Holmes at oracle.com Sun Aug 29 04:39:38 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 29 Aug 2010 21:39:38 +1000 Subject: GNU_STACK ELF header In-Reply-To: <4C7995A5.2050408@oracle.com> References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> <4C7995A5.2050408@oracle.com> Message-ID: <4C7A46FA.7070709@oracle.com> David Holmes said the following on 08/29/10 09:03: > Douglas Simon said the following on 08/28/10 23:42: >> I think the long term solution is to modify the >> __make_stacks_executable function in libc/nptl/allocatestack.c such >> that it only adds the PROT_EXEC bit to each thread's stack and leaves >> the current values for the PROT_READ and PROT_WRITE bits as is. > > I find it hard to believe that they would overwrite the permission bits > rather than augment them in the first place. I can't wait to find out > what justification they think they had for doing that. :( Looks like it is because the OS gives no way to do otherwise :( mprotect doesn't allow you to add to the existing permissions only set them - and there's no API that I can see to query page permissions. There's some interesting discussion in this LK thread: http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-02/0145.html David From andi at firstfloor.org Mon Aug 30 07:08:27 2010 From: andi at firstfloor.org (Andi Kleen) Date: Mon, 30 Aug 2010 16:08:27 +0200 Subject: GNU_STACK ELF header In-Reply-To: <4C7A46FA.7070709@oracle.com> (David Holmes's message of "Sun, 29 Aug 2010 21:39:38 +1000") References: <3429F3E5-20D9-4589-A0CD-7A031B9F061B@oracle.com> <97310A32-7515-476C-8D12-89835115DFE6@oracle.com> <83A26E6A-EDBE-4A83-A689-2F4229DBF036@oracle.com> <37BD9398-CF17-4086-8EE2-1294944A5000@oracle.com> <4C7995A5.2050408@oracle.com> <4C7A46FA.7070709@oracle.com> Message-ID: <87pqx042hw.fsf@basil.nowhere.org> David Holmes writes: > > Looks like it is because the OS gives no way to do otherwise :( > mprotect doesn't allow you to add to the existing permissions only set > them - and there's no API that I can see to query page permissions. /proc/self/maps. But it's not very nice to use and slow. -Andi From daniel.daugherty at oracle.com Mon Aug 30 10:55:04 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 30 Aug 2010 17:55:04 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20100830175510.7C19B47557@hg.openjdk.java.net> Changeset: c7004d700b49 Author: dholmes Date: 2010-08-25 21:29 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c7004d700b49 6978641: Fix for 6929067 introduces additional overhead in thread creation/termination paths Summary: Disable stack bounds checks in product mode other than for the initial thread Reviewed-by: coleenp, jcoomes, aph ! src/os/linux/vm/os_linux.cpp Changeset: 2528b5bd749c Author: kamg Date: 2010-08-27 15:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2528b5bd749c 6980262: Memory leak when exception is thrown in static initializer Summary: Use resource memory instead of c-heap for the exception message Reviewed-by: phh, jmasa ! src/share/vm/oops/instanceKlass.cpp Changeset: 8397081c7ac1 Author: dcubed Date: 2010-08-27 21:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8397081c7ac1 Merge From tony.printezis at oracle.com Mon Aug 30 13:00:49 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Mon, 30 Aug 2010 20:00:49 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20100830200103.2CCA04755C@hg.openjdk.java.net> Changeset: bba76f745fe6 Author: ysr Date: 2010-08-23 17:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bba76f745fe6 6910183: CMS: assert(_index < capacity(),"_index out of bounds") Summary: Weakened a too-strong, off-by-one assert; added code to keep track of and report any overflows at appropriate level of verbosity. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: e967bad2a9ab Author: tonyp Date: 2010-08-25 08:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e967bad2a9ab 6941275: G1: The MemoryPools are incorrectly supported for G1 Summary: The way we were caluclating the max value meant that it might fluctuate during the run and this broke some assumptions inside the MBeans framework. This change sets the max value of each pool to -1, which means undefined according to the spec. Reviewed-by: mchung, johnc ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 8e5955ddf8e4 Author: jcoomes Date: 2010-08-25 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8e5955ddf8e4 6978300: G1: debug builds crash if ParallelGCThreads==0 Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 21c29458b334 Author: kevinw Date: 2010-08-27 16:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/21c29458b334 6980392: TEST_BUG: gc/6581734/Test6581734.java has typo Summary: simple correction in testcase Reviewed-by: mchung ! test/gc/6581734/Test6581734.java Changeset: 1c63587d925b Author: tonyp Date: 2010-08-27 13:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1c63587d925b 6980206: G1: assert(has_undefined_max_size, "Undefined max size"); Summary: An assert in the management.cpp is too strong and assumes the max size is always defined on memory pools, even when we don't need to use it. Reviewed-by: mchung, johnc ! src/share/vm/services/management.cpp Changeset: af586a7893cf Author: tonyp Date: 2010-08-27 10:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/af586a7893cf Merge Changeset: 75107ee8712f Author: tonyp Date: 2010-08-30 13:00 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/75107ee8712f Merge Changeset: f208bf19192d Author: tonyp Date: 2010-08-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f208bf19192d Merge