From zhengyu.gu at oracle.com Fri Oct 1 00:26:00 2010 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Fri, 01 Oct 2010 07:26:00 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6988363: Rebrand vm vendor property settings (jdk7 only) Message-ID: <20101001072603.04D8847E0F@hg.openjdk.java.net> Changeset: dfb38ea7da17 Author: zgu Date: 2010-09-30 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dfb38ea7da17 6988363: Rebrand vm vendor property settings (jdk7 only) Summary: Vendor properties should be initialized after JDK version is determined. Reviewed-by: kamg, ohair, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp From coleen.phillimore at oracle.com Mon Oct 4 15:45:08 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 04 Oct 2010 18:45:08 -0400 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Message-ID: <4CAA58F4.5030100@oracle.com> Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable Also stress tested various combinations of -Xss and -XX:StackShadowPages=n. This also fixes a bug 6346701: stack overflow in native method results in segfault, not a StackOverflowError or rather it fixes the observed SEGVs with different settings of -Xss and -XX:StackShadowPages in the evaluation. We were getting stack overflow before the stack overflow exception was initialized, causing infinite recusion trying to initialize it. Also fixed a random g++ compilation error. open webrev at http://cr.openjdk.java.net/~coleenp/6983240/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6983240 Thanks, Coleen From David.Holmes at oracle.com Mon Oct 4 17:41:32 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 05 Oct 2010 10:41:32 +1000 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CAA58F4.5030100@oracle.com> References: <4CAA58F4.5030100@oracle.com> Message-ID: <4CAA743C.3060905@oracle.com> Hi Coleen, In os_solaris.cpp this comment should now refer to 2*BytesPerWord // Add in BytesPerWord times page size to account for VM stack during // class initialization depending on 32 or 64 bit VM. That said this formulation (not your I know) is confusing. What does bytesPerWord have to do with the amount of stack needed? Is this just some weird way of getting twice the amount of stack on 64-bit as 32-bit? Are the pages sizes even the same in that case? Also in os_solaris.cpp isn't this guarantee always false: ! guarantee(os::Solaris::min_stack_allowed >= thr_min_stack(), ! "need to increase min_stack_allowed"); AFAICS min_stack_allowed is set to one of these values: ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t os::Solaris::min_stack_allowed = 128*K; ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t os::Solaris::min_stack_allowed = 96*K; ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t os::Solaris::min_stack_allowed = 224*K; ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t os::Solaris::min_stack_allowed = 64*K; but the manpage for thr_min_stack states: thr_min_stack() will return the unsigned int THR_MIN_STACK, which is the minimum-allowable size for a thread's stack. In this implementation the default size for a user-thread's stack is one mega-byte. 1MB > all the above. ??? Cheers, David Coleen Phillimore said the following on 10/05/10 08:45: > Summary: min_stack_allowed is a compile time constant and Stack*Pages > are settable > > Also stress tested various combinations of -Xss and > -XX:StackShadowPages=n. This also fixes a bug > 6346701: stack overflow in native method results in segfault, not a > StackOverflowError > or rather it fixes the observed SEGVs with different settings of -Xss > and -XX:StackShadowPages in the evaluation. We were getting stack > overflow before the stack overflow exception was initialized, causing > infinite recusion trying to initialize it. > > Also fixed a random g++ compilation error. > > open webrev at http://cr.openjdk.java.net/~coleenp/6983240/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6983240 > > Thanks, > Coleen From David.Holmes at oracle.com Mon Oct 4 20:09:22 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 05 Oct 2010 13:09:22 +1000 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CAA743C.3060905@oracle.com> References: <4CAA58F4.5030100@oracle.com> <4CAA743C.3060905@oracle.com> Message-ID: <4CAA96E2.9080608@oracle.com> > but the manpage for thr_min_stack states: > > thr_min_stack() will return the unsigned int THR_MIN_STACK, > which is the minimum-allowable size for a thread's stack. > > In this implementation the default size for a user-thread's > stack is one mega-byte. Never trust a manpage! The actual value I see on my system is 4K. But this makes me wonder how "fixed" THR_MIN_STACK is and whether that guarantee should revert back to the original code and simply set minstack_allowed to the maximum of those two values. David David Holmes said the following on 10/05/10 10:41: > Hi Coleen, > > In os_solaris.cpp this comment should now refer to 2*BytesPerWord > > // Add in BytesPerWord times page size to account for VM stack during > // class initialization depending on 32 or 64 bit VM. > > That said this formulation (not your I know) is confusing. What does > bytesPerWord have to do with the amount of stack needed? Is this just > some weird way of getting twice the amount of stack on 64-bit as 32-bit? > Are the pages sizes even the same in that case? > > Also in os_solaris.cpp isn't this guarantee always false: > > ! guarantee(os::Solaris::min_stack_allowed >= thr_min_stack(), > ! "need to increase min_stack_allowed"); > > AFAICS min_stack_allowed is set to one of these values: > > ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t > os::Solaris::min_stack_allowed = 128*K; > ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t > os::Solaris::min_stack_allowed = 96*K; > ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t > os::Solaris::min_stack_allowed = 224*K; > ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t > os::Solaris::min_stack_allowed = 64*K; > > but the manpage for thr_min_stack states: > > thr_min_stack() will return the unsigned int THR_MIN_STACK, > which is the minimum-allowable size for a thread's stack. > > In this implementation the default size for a user-thread's > stack is one mega-byte. > > 1MB > all the above. ??? > > Cheers, > David > > Coleen Phillimore said the following on 10/05/10 08:45: >> Summary: min_stack_allowed is a compile time constant and Stack*Pages >> are settable >> >> Also stress tested various combinations of -Xss and >> -XX:StackShadowPages=n. This also fixes a bug >> 6346701: stack overflow in native method results in segfault, not a >> StackOverflowError >> or rather it fixes the observed SEGVs with different settings of -Xss >> and -XX:StackShadowPages in the evaluation. We were getting stack >> overflow before the stack overflow exception was initialized, causing >> infinite recusion trying to initialize it. >> >> Also fixed a random g++ compilation error. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6983240/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6983240 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Tue Oct 5 08:26:24 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 05 Oct 2010 11:26:24 -0400 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CAA743C.3060905@oracle.com> References: <4CAA58F4.5030100@oracle.com> <4CAA743C.3060905@oracle.com> Message-ID: <4CAB43A0.60001@oracle.com> Thanks David - some comments inline... On 10/04/10 20:41, David Holmes wrote: > Hi Coleen, > > In os_solaris.cpp this comment should now refer to 2*BytesPerWord Okay. > > // Add in BytesPerWord times page size to account for VM stack during > // class initialization depending on 32 or 64 bit VM. > > That said this formulation (not your I know) is confusing. What does > bytesPerWord have to do with the amount of stack needed? Is this just > some weird way of getting twice the amount of stack on 64-bit as > 32-bit? Are the pages sizes even the same in that case? Yeah, I believe it's just to account for 64 vs. 32 bit. The page sizes are the same if 32 or 64 bit. I have > > Also in os_solaris.cpp isn't this guarantee always false: > > ! guarantee(os::Solaris::min_stack_allowed >= thr_min_stack(), > ! "need to increase min_stack_allowed"); No, it doesn't assert, because in your next mail you found that thr_min_stack() is smaller than our min_stack_allowed. I could revert that change but min_stack_allowed() is for the VM to get initialized rather than this thr_min_stack() which is for the OS to initialize the thread. I would assume the latter is always smaller than the former or something is really wrong. Changing it back probably doesn't hurt anything. Thanks, Coleen > > AFAICS min_stack_allowed is set to one of these values: > > ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t > os::Solaris::min_stack_allowed = 128*K; > ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t > os::Solaris::min_stack_allowed = 96*K; > ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t > os::Solaris::min_stack_allowed = 224*K; > ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t > os::Solaris::min_stack_allowed = 64*K; > > but the manpage for thr_min_stack states: > > thr_min_stack() will return the unsigned int THR_MIN_STACK, > which is the minimum-allowable size for a thread's stack. > > In this implementation the default size for a user-thread's > stack is one mega-byte. > > 1MB > all the above. ??? > > Cheers, > David > > Coleen Phillimore said the following on 10/05/10 08:45: >> Summary: min_stack_allowed is a compile time constant and Stack*Pages >> are settable >> >> Also stress tested various combinations of -Xss and >> -XX:StackShadowPages=n. This also fixes a bug >> 6346701: stack overflow in native method results in segfault, not a >> StackOverflowError >> or rather it fixes the observed SEGVs with different settings of -Xss >> and -XX:StackShadowPages in the evaluation. We were getting stack >> overflow before the stack overflow exception was initialized, causing >> infinite recusion trying to initialize it. >> >> Also fixed a random g++ compilation error. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6983240/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6983240 >> >> Thanks, >> Coleen From karen.kinnear at oracle.com Tue Oct 5 18:00:55 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 06 Oct 2010 01:00:55 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20101006010101.6859F47F28@hg.openjdk.java.net> Changeset: 1c352af0135d Author: acorn Date: 2010-10-04 13:11 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1c352af0135d 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks forever Summary: Absolute time 0 needs to return immediately. Reviewed-by: phh, dcubed, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 644f98c78e33 Author: acorn Date: 2010-10-04 10:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/644f98c78e33 Merge From coleen.phillimore at oracle.com Wed Oct 6 10:55:25 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 06 Oct 2010 13:55:25 -0400 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CAB43A0.60001@oracle.com> References: <4CAA58F4.5030100@oracle.com> <4CAA743C.3060905@oracle.com> <4CAB43A0.60001@oracle.com> Message-ID: <4CACB80D.6060708@oracle.com> Can I get one more review? webrev at http://cr.openjdk.java.net/~coleenp/6983240_2/ Thanks, Coleen On 10/05/10 11:26, Coleen Phillimore wrote: > > Thanks David - some comments inline... > > On 10/04/10 20:41, David Holmes wrote: >> Hi Coleen, >> >> In os_solaris.cpp this comment should now refer to 2*BytesPerWord > Okay. >> >> // Add in BytesPerWord times page size to account for VM stack during >> // class initialization depending on 32 or 64 bit VM. >> >> That said this formulation (not your I know) is confusing. What does >> bytesPerWord have to do with the amount of stack needed? Is this just >> some weird way of getting twice the amount of stack on 64-bit as >> 32-bit? Are the pages sizes even the same in that case? > Yeah, I believe it's just to account for 64 vs. 32 bit. The page > sizes are the same if 32 or 64 bit. I have >> >> Also in os_solaris.cpp isn't this guarantee always false: >> >> ! guarantee(os::Solaris::min_stack_allowed >= thr_min_stack(), >> ! "need to increase min_stack_allowed"); > No, it doesn't assert, because in your next mail you found that > thr_min_stack() is smaller than our min_stack_allowed. I could revert > that change but min_stack_allowed() is for the VM to get initialized > rather than this thr_min_stack() which is for the OS to initialize the > thread. I would assume the latter is always smaller than the former > or something is really wrong. Changing it back probably doesn't hurt > anything. > > Thanks, > Coleen >> >> AFAICS min_stack_allowed is set to one of these values: >> >> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >> os::Solaris::min_stack_allowed = 128*K; >> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >> os::Solaris::min_stack_allowed = 96*K; >> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >> os::Solaris::min_stack_allowed = 224*K; >> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >> os::Solaris::min_stack_allowed = 64*K; >> >> but the manpage for thr_min_stack states: >> >> thr_min_stack() will return the unsigned int THR_MIN_STACK, >> which is the minimum-allowable size for a thread's stack. >> >> In this implementation the default size for a user-thread's >> stack is one mega-byte. >> >> 1MB > all the above. ??? >> >> Cheers, >> David >> >> Coleen Phillimore said the following on 10/05/10 08:45: >>> Summary: min_stack_allowed is a compile time constant and >>> Stack*Pages are settable >>> >>> Also stress tested various combinations of -Xss and >>> -XX:StackShadowPages=n. This also fixes a bug >>> 6346701: stack overflow in native method results in segfault, not a >>> StackOverflowError >>> or rather it fixes the observed SEGVs with different settings of >>> -Xss and -XX:StackShadowPages in the evaluation. We were getting >>> stack overflow before the stack overflow exception was initialized, >>> causing infinite recusion trying to initialize it. >>> >>> Also fixed a random g++ compilation error. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6983240/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6983240 >>> >>> Thanks, >>> Coleen > From vladimir.kozlov at oracle.com Wed Oct 6 11:19:13 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Oct 2010 11:19:13 -0700 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CACB80D.6060708@oracle.com> References: <4CAA58F4.5030100@oracle.com> <4CAA743C.3060905@oracle.com> <4CAB43A0.60001@oracle.com> <4CACB80D.6060708@oracle.com> Message-ID: <4CACBDA1.1090302@oracle.com> Looks good for me. Vladimir Coleen Phillimore wrote: > > Can I get one more review? > > webrev at http://cr.openjdk.java.net/~coleenp/6983240_2/ > > Thanks, > Coleen > > > > On 10/05/10 11:26, Coleen Phillimore wrote: >> >> Thanks David - some comments inline... >> >> On 10/04/10 20:41, David Holmes wrote: >>> Hi Coleen, >>> >>> In os_solaris.cpp this comment should now refer to 2*BytesPerWord >> Okay. >>> >>> // Add in BytesPerWord times page size to account for VM stack during >>> // class initialization depending on 32 or 64 bit VM. >>> >>> That said this formulation (not your I know) is confusing. What does >>> bytesPerWord have to do with the amount of stack needed? Is this just >>> some weird way of getting twice the amount of stack on 64-bit as >>> 32-bit? Are the pages sizes even the same in that case? >> Yeah, I believe it's just to account for 64 vs. 32 bit. The page >> sizes are the same if 32 or 64 bit. I have >>> >>> Also in os_solaris.cpp isn't this guarantee always false: >>> >>> ! guarantee(os::Solaris::min_stack_allowed >= thr_min_stack(), >>> ! "need to increase min_stack_allowed"); >> No, it doesn't assert, because in your next mail you found that >> thr_min_stack() is smaller than our min_stack_allowed. I could revert >> that change but min_stack_allowed() is for the VM to get initialized >> rather than this thr_min_stack() which is for the OS to initialize the >> thread. I would assume the latter is always smaller than the former >> or something is really wrong. Changing it back probably doesn't hurt >> anything. >> >> Thanks, >> Coleen >>> >>> AFAICS min_stack_allowed is set to one of these values: >>> >>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>> os::Solaris::min_stack_allowed = 128*K; >>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>> os::Solaris::min_stack_allowed = 96*K; >>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>> os::Solaris::min_stack_allowed = 224*K; >>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>> os::Solaris::min_stack_allowed = 64*K; >>> >>> but the manpage for thr_min_stack states: >>> >>> thr_min_stack() will return the unsigned int THR_MIN_STACK, >>> which is the minimum-allowable size for a thread's stack. >>> >>> In this implementation the default size for a user-thread's >>> stack is one mega-byte. >>> >>> 1MB > all the above. ??? >>> >>> Cheers, >>> David >>> >>> Coleen Phillimore said the following on 10/05/10 08:45: >>>> Summary: min_stack_allowed is a compile time constant and >>>> Stack*Pages are settable >>>> >>>> Also stress tested various combinations of -Xss and >>>> -XX:StackShadowPages=n. This also fixes a bug >>>> 6346701: stack overflow in native method results in segfault, not a >>>> StackOverflowError >>>> or rather it fixes the observed SEGVs with different settings of >>>> -Xss and -XX:StackShadowPages in the evaluation. We were getting >>>> stack overflow before the stack overflow exception was initialized, >>>> causing infinite recusion trying to initialize it. >>>> >>>> Also fixed a random g++ compilation error. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6983240/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6983240 >>>> >>>> Thanks, >>>> Coleen >> > From vladimir.kozlov at oracle.com Wed Oct 6 11:50:19 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Oct 2010 11:50:19 -0700 Subject: review request for CR 6361589 In-Reply-To: References: <4B20298D.2020506@Sun.Com> <5C69C57C-3D78-41C8-B238-1FBC6F9182B9@sun.com> <4B217B41.7060203@Sun.Com> <4B2190B8.6020608@sun.com> <4B219614.8030600@Sun.Com> <4B21A781.1090700@sun.com> <4B21C625.9070202@Sun.Com> Message-ID: <4CACC4EB.4090200@oracle.com> Volker, Did you got a respond on this? Thanks, Vladimir Volker Simonis wrote: > Hi Yumin, > > I know that this CR has already been submitted, but I've discovered a > small problem which I think should be fixed. I vmError.cpp you don't > check for '_thread' beeing NULL which can lead to a SIGSEGV if the > VMError object was constructed with a zero thread argument. Instead, > the corresponding if-line should read like the if-lines of the other > steps which use '_thread': > > STEP(135, "(printing target Java thread stack)" ) > > // printing Java thread stack trace if it is involved in GC crash > if (_verbose && _thread && (_thread->is_Named_thread())) { > > Thank you and best regards, > Volker > > On Fri, Dec 11, 2009 at 6:10 AM, Yumin Qi wrote: >> Thanks. >> >> I modified the code and submitted again. Please take a look again, will >> commit if it is OK. >> >> Thanks >> Yumin >> >> Coleen Phillimore wrote: >>> Yumin, >>> I've already reviewed a previous version and this still looks great to me. >>> I hope this makes diagnosing crashes during gc much better, rather than >>> having to decode the thread manually as you've been doing for years. >>> Thanks everyone for the additional comments. The later suggested changes >>> are really good. >>> >>> Coleen >>> >>> Yumin Qi wrote: >>>> Thanks for you all the good suggestions: >>>> >>>> 1) update the hierarchy comments --- we miss some there >>>> 2) Use c'tor-d'tor idiom for remembering JavaThread in GC thread >>>> 3) Add one more STEP (135) >>>> 4) update vmStructs so the SA can check this value. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> >>>> David Holmes - Sun Microsystems wrote: >>>>> Hi Yumin, >>>>> >>>>> Can you update the thread hierarchy comments in thread.hpp: >>>>> >>>>> 49 // Class hierarchy >>>>> 50 // - Thread >>>>> 51 // - VMThread >>>>> 52 // - JavaThread >>>>> 53 // - WatcherThread >>>>> >>>>> This seems incomplete anyway so it would be good to update it. >>>>> >>>>> I would also find it useful to add more comments to the NamedThread >>>>> class explaining the role of this new field. It really has nothing to do >>>>> with being a "named thread" - but then NamedThread should really have been >>>>> called something more general. Pity we can't rename it - can we? :) >>>>> >>>>> In vmError.cpp: >>>>> >>>>> 506 // printing Java thread stack trace if it is involved in GC >>>>> crash >>>>> 507 >>>>> 508 if (_verbose && (_thread->is_Named_thread())) { >>>>> >>>>> Can/Should this be a new STEP? >>>>> >>>>> David >>>>> >>>>> Yumin Qi said the following on 12/11/09 08:50: >>>>>> Tom, >>>>>> >>>>>> Thanks, changed as pointed. >>>>>> Sorry I forget to include GC group. >>>>>> >>>>>> Can someone else give a look? >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6361589 >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> Overall this looks pretty nice. >>>>>>> >>>>>>> java_thread_gc isn't a very clear name. Maybe collected_thread or >>>>>>> processed_thread? The comment should describe it's purpose more explicitly. >>>>>>> >>>>>>> Is this assert really needed? >>>>>>> >>>>>>> + assert(thread != this, "Should not be java thread itself"); >>>>>>> >>>>>>> I think you should add is_NamedThread() instead of distinguishing all >>>>>>> these cases individually. >>>>>>> >>>>>>> If VMThread is now a NamedTread why don't you call set_name instead of >>>>>>> having it override name again? >>>>>>> >>>>>>> vmError.cpp: >>>>>>> >>>>>>> I think the printing output should look more like this: >>>>>>> >>>>>>> + st->print_cr("JavaThread " PTR_FORMAT " was being processed >>>>>>> during the crash, id = " UINTX_FORMAT, jt, jt->osthread()->thread_id()); >>>>>>> >>>>>>> tom >>>>>>> >>>>>>> On Dec 9, 2009, at 2:49 PM, Yumin Qi wrote: >>>>>>> >>>>>>> >>>>>>>> Fixed 6361589: Print out stack trace for target thread of GC crash >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6361589 >>>>>>>> >>>>>>>> Comments: This is a facility to assist for JVM crash analysis. To >>>>>>>> implement this function, it needs record JavaThread which may involve crash >>>>>>>> somewhere in GC thread. The place chosen here is NamedThread from which all >>>>>>>> GC threads but VMThread derive. I change VMThread's base from Thread to >>>>>>>> NamedThread, so the recording of JavaThread covers for GC threads and >>>>>>>> VMThread. Once the JavaThread recorded in GC thread seen during error >>>>>>>> report, its stack trace be printed out. To test this function, add a debug >>>>>>>> flag CrashGCForDumpingJavaThread, once it is set, it will crash immediately >>>>>>>> in VMThread or GC Thread to core dump. Note this is for test only purpose, >>>>>>>> no defects in involved JavaThread. >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>> >> From vladimir.kozlov at oracle.com Wed Oct 6 16:17:01 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Oct 2010 16:17:01 -0700 Subject: review request for CR 6361589 In-Reply-To: <4CACDE33.50709@oracle.com> References: <4B20298D.2020506@Sun.Com> <5C69C57C-3D78-41C8-B238-1FBC6F9182B9@sun.com> <4B217B41.7060203@Sun.Com> <4B2190B8.6020608@sun.com> <4B219614.8030600@Sun.Com> <4B21A781.1090700@sun.com> <4B21C625.9070202@Sun.Com> <4CACC4EB.4090200@oracle.com> <4CACDE33.50709@oracle.com> Message-ID: <4CAD036D.2070003@oracle.com> We should fix it in HS19 also. If we do it this week it will be ready for next promoted build of 6u23. Thanks, Vladimir Yumin Qi wrote: > Hi, all > > Somehow I missed this email. Yes, Volker is right, this part miss a > check if _thread is valid. > We need to fix it under a bug number(even it is a very simple fix). I > will file a bug for it. > > Thanks > Yumin > > On 2010/10/6 11:50, Vladimir Kozlov wrote: >> Volker, >> >> Did you got a respond on this? >> >> Thanks, >> Vladimir >> >> Volker Simonis wrote: >>> Hi Yumin, >>> >>> I know that this CR has already been submitted, but I've discovered a >>> small problem which I think should be fixed. I vmError.cpp you don't >>> check for '_thread' beeing NULL which can lead to a SIGSEGV if the >>> VMError object was constructed with a zero thread argument. Instead, >>> the corresponding if-line should read like the if-lines of the other >>> steps which use '_thread': >>> >>> STEP(135, "(printing target Java thread stack)" ) >>> >>> // printing Java thread stack trace if it is involved in GC crash >>> if (_verbose && _thread && (_thread->is_Named_thread())) { >>> >>> Thank you and best regards, >>> Volker >>> >>> On Fri, Dec 11, 2009 at 6:10 AM, Yumin Qi wrote: >>>> Thanks. >>>> >>>> I modified the code and submitted again. Please take a look again, will >>>> commit if it is OK. >>>> >>>> Thanks >>>> Yumin >>>> >>>> Coleen Phillimore wrote: >>>>> Yumin, >>>>> I've already reviewed a previous version and this still looks great >>>>> to me. >>>>> I hope this makes diagnosing crashes during gc much better, rather >>>>> than >>>>> having to decode the thread manually as you've been doing for years. >>>>> Thanks everyone for the additional comments. The later suggested >>>>> changes >>>>> are really good. >>>>> >>>>> Coleen >>>>> >>>>> Yumin Qi wrote: >>>>>> Thanks for you all the good suggestions: >>>>>> >>>>>> 1) update the hierarchy comments --- we miss some there >>>>>> 2) Use c'tor-d'tor idiom for remembering JavaThread in GC thread >>>>>> 3) Add one more STEP (135) >>>>>> 4) update vmStructs so the SA can check this value. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> >>>>>> David Holmes - Sun Microsystems wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> Can you update the thread hierarchy comments in thread.hpp: >>>>>>> >>>>>>> 49 // Class hierarchy >>>>>>> 50 // - Thread >>>>>>> 51 // - VMThread >>>>>>> 52 // - JavaThread >>>>>>> 53 // - WatcherThread >>>>>>> >>>>>>> This seems incomplete anyway so it would be good to update it. >>>>>>> >>>>>>> I would also find it useful to add more comments to the NamedThread >>>>>>> class explaining the role of this new field. It really has >>>>>>> nothing to do >>>>>>> with being a "named thread" - but then NamedThread should really >>>>>>> have been >>>>>>> called something more general. Pity we can't rename it - can we? :) >>>>>>> >>>>>>> In vmError.cpp: >>>>>>> >>>>>>> 506 // printing Java thread stack trace if it is involved in GC >>>>>>> crash >>>>>>> 507 >>>>>>> 508 if (_verbose && (_thread->is_Named_thread())) { >>>>>>> >>>>>>> Can/Should this be a new STEP? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> Yumin Qi said the following on 12/11/09 08:50: >>>>>>>> Tom, >>>>>>>> >>>>>>>> Thanks, changed as pointed. >>>>>>>> Sorry I forget to include GC group. >>>>>>>> >>>>>>>> Can someone else give a look? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6361589 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> Overall this looks pretty nice. >>>>>>>>> >>>>>>>>> java_thread_gc isn't a very clear name. Maybe collected_thread or >>>>>>>>> processed_thread? The comment should describe it's purpose >>>>>>>>> more explicitly. >>>>>>>>> >>>>>>>>> Is this assert really needed? >>>>>>>>> >>>>>>>>> + assert(thread != this, "Should not be java thread itself"); >>>>>>>>> >>>>>>>>> I think you should add is_NamedThread() instead of >>>>>>>>> distinguishing all >>>>>>>>> these cases individually. >>>>>>>>> >>>>>>>>> If VMThread is now a NamedTread why don't you call set_name >>>>>>>>> instead of >>>>>>>>> having it override name again? >>>>>>>>> >>>>>>>>> vmError.cpp: >>>>>>>>> >>>>>>>>> I think the printing output should look more like this: >>>>>>>>> >>>>>>>>> + st->print_cr("JavaThread " PTR_FORMAT " was being >>>>>>>>> processed >>>>>>>>> during the crash, id = " UINTX_FORMAT, jt, >>>>>>>>> jt->osthread()->thread_id()); >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>> On Dec 9, 2009, at 2:49 PM, Yumin Qi wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Fixed 6361589: Print out stack trace for target thread of GC >>>>>>>>>> crash >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/6361589 >>>>>>>>>> >>>>>>>>>> Comments: This is a facility to assist for JVM crash analysis. To >>>>>>>>>> implement this function, it needs record JavaThread which may >>>>>>>>>> involve crash >>>>>>>>>> somewhere in GC thread. The place chosen here is NamedThread >>>>>>>>>> from which all >>>>>>>>>> GC threads but VMThread derive. I change VMThread's base from >>>>>>>>>> Thread to >>>>>>>>>> NamedThread, so the recording of JavaThread covers for GC >>>>>>>>>> threads and >>>>>>>>>> VMThread. Once the JavaThread recorded in GC thread seen >>>>>>>>>> during error >>>>>>>>>> report, its stack trace be printed out. To test this function, >>>>>>>>>> add a debug >>>>>>>>>> flag CrashGCForDumpingJavaThread, once it is set, it will >>>>>>>>>> crash immediately >>>>>>>>>> in VMThread or GC Thread to core dump. Note this is for test >>>>>>>>>> only purpose, >>>>>>>>>> no defects in involved JavaThread. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>> >>>> > From coleen.phillimore at oracle.com Thu Oct 7 10:30:30 2010 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 07 Oct 2010 17:30:30 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Message-ID: <20101007173033.D464547F95@hg.openjdk.java.net> Changeset: b6aedd1acdc0 Author: coleenp Date: 2010-10-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b6aedd1acdc0 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable Reviewed-by: dholmes, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/exceptions.cpp From coleen.phillimore at oracle.com Thu Oct 7 11:11:58 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Oct 2010 14:11:58 -0400 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CAE045E.3080304@oracle.com> References: <4CACC58E.90400@oracle.com> <4CAE045E.3080304@oracle.com> Message-ID: <4CAE0D6E.2070603@oracle.com> I just checked it in... sorry I didn't wait. Dmitriy Samersoff wrote: > Coleen, > > Code looks good for me but I have a few questions (below): > > 1. > > Is it possible to create > > static inline size_t min_stack_allowed(){ > return > (size_t)(StackYellowPages+StackRedPages+StackShadowPages+ > 2*BytesPerWord COMPILER2_PRESENT(+1)) * os::vm_page_size(); > > in os.hpp ? > This would have been better but the constant value for min_stack_allowed had some comment about being documented, so I didn't want to mess with that. I don't actually know where it's documented though. > 1". > If not: > > os_linux.cpp uses Linux::page_size() > os_solaris.cpp uses page_size > os_windows.cpp uses os::vm_page_size() > > I believe all three returns a correct value but is it possible to keep > the same semantics across OSes i.e. always use either > {Linux,Solaris,Windows}::page_size or os::vm_page_size() ? > This does need cleanup. They should all use os::vm_page_size(). I don't know why there was ever a linux variant. On solaris, you can have bigger page sizes so the semantics are more complicated. > > 2. We don't store calculated min_stack_allowed under windows. > I'm not a windows expert - do we have a reason for it? > And (a nit) I'm a little bit worried about cast from size_t > to int here. It apparently was never in the documentation so I didn't want to add it. Windows default page size is really big. The windows didn't compile this final version so I had to change the local variable min_stack_allowed to a size_t to get it through jprt, so the cast is gone. Thanks, Coleen > > -Dmitry > > > > On 2010-10-06 22:53, Coleen Phillimore wrote: >> -------- Original Message -------- >> Subject: Re: Review request 6983240: >> guarantee((Solaris::min_stack_allowed >= >> (StackYellowPages+StackRedPages...) wrong >> Date: Wed, 06 Oct 2010 11:19:13 -0700 >> From: Vladimir Kozlov >> To: Coleen Phillimore >> CC: hotspot-runtime-dev at openjdk.java.net >> References: <4CAA58F4.5030100 at oracle.com> >> <4CAA743C.3060905 at oracle.com> >> <4CAB43A0.60001 at oracle.com> <4CACB80D.6060708 at oracle.com> >> >> >> >> Looks good for me. >> >> Vladimir >> >> Coleen Phillimore wrote: >>> >>> Can I get one more review? >>> >>> webrev athttp://cr.openjdk.java.net/~coleenp/6983240_2/ >>> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 10/05/10 11:26, Coleen Phillimore wrote: >>>> >>>> Thanks David - some comments inline... >>>> >>>> On 10/04/10 20:41, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> In os_solaris.cpp this comment should now refer to 2*BytesPerWord >>>> Okay. >>>>> >>>>> // Add in BytesPerWord times page size to account for VM stack >>>>> during >>>>> // class initialization depending on 32 or 64 bit VM. >>>>> >>>>> That said this formulation (not your I know) is confusing. What does >>>>> bytesPerWord have to do with the amount of stack needed? Is this >>>>> just >>>>> some weird way of getting twice the amount of stack on 64-bit as >>>>> 32-bit? Are the pages sizes even the same in that case? >>>> Yeah, I believe it's just to account for 64 vs. 32 bit. The page >>>> sizes are the same if 32 or 64 bit. I have >>>>> >>>>> Also in os_solaris.cpp isn't this guarantee always false: >>>>> >>>>> ! guarantee(os::Solaris::min_stack_allowed>= thr_min_stack(), >>>>> ! "need to increase min_stack_allowed"); >>>> No, it doesn't assert, because in your next mail you found that >>>> thr_min_stack() is smaller than our min_stack_allowed. I could >>>> revert >>>> that change but min_stack_allowed() is for the VM to get initialized >>>> rather than this thr_min_stack() which is for the OS to initialize >>>> the >>>> thread. I would assume the latter is always smaller than the former >>>> or something is really wrong. Changing it back probably doesn't hurt >>>> anything. >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> AFAICS min_stack_allowed is set to one of these values: >>>>> >>>>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>>>> os::Solaris::min_stack_allowed = 128*K; >>>>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>>>> os::Solaris::min_stack_allowed = 96*K; >>>>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>>>> os::Solaris::min_stack_allowed = 224*K; >>>>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>>>> os::Solaris::min_stack_allowed = 64*K; >>>>> >>>>> but the manpage for thr_min_stack states: >>>>> >>>>> thr_min_stack() will return the unsigned int THR_MIN_STACK, >>>>> which is the minimum-allowable size for a thread's stack. >>>>> >>>>> In this implementation the default size for a user-thread's >>>>> stack is one mega-byte. >>>>> >>>>> 1MB> all the above. ??? >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> Coleen Phillimore said the following on 10/05/10 08:45: >>>>>> Summary: min_stack_allowed is a compile time constant and >>>>>> Stack*Pages are settable >>>>>> >>>>>> Also stress tested various combinations of -Xss and >>>>>> -XX:StackShadowPages=n. This also fixes a bug >>>>>> 6346701: stack overflow in native method results in segfault, not a >>>>>> StackOverflowError >>>>>> or rather it fixes the observed SEGVs with different settings of >>>>>> -Xss and -XX:StackShadowPages in the evaluation. We were getting >>>>>> stack overflow before the stack overflow exception was initialized, >>>>>> causing infinite recusion trying to initialize it. >>>>>> >>>>>> Also fixed a random g++ compilation error. >>>>>> >>>>>> open webrev athttp://cr.openjdk.java.net/~coleenp/6983240/ >>>>>> bug link athttp://bugs.sun.com/view_bug.do?bug_id=6983240 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >>> >> > > From yumin.qi at oracle.com Wed Oct 6 13:38:11 2010 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 06 Oct 2010 13:38:11 -0700 Subject: review request for CR 6361589 In-Reply-To: <4CACC4EB.4090200@oracle.com> References: <4B20298D.2020506@Sun.Com> <5C69C57C-3D78-41C8-B238-1FBC6F9182B9@sun.com> <4B217B41.7060203@Sun.Com> <4B2190B8.6020608@sun.com> <4B219614.8030600@Sun.Com> <4B21A781.1090700@sun.com> <4B21C625.9070202@Sun.Com> <4CACC4EB.4090200@oracle.com> Message-ID: <4CACDE33.50709@oracle.com> Hi, all Somehow I missed this email. Yes, Volker is right, this part miss a check if _thread is valid. We need to fix it under a bug number(even it is a very simple fix). I will file a bug for it. Thanks Yumin On 2010/10/6 11:50, Vladimir Kozlov wrote: > Volker, > > Did you got a respond on this? > > Thanks, > Vladimir > > Volker Simonis wrote: >> Hi Yumin, >> >> I know that this CR has already been submitted, but I've discovered a >> small problem which I think should be fixed. I vmError.cpp you don't >> check for '_thread' beeing NULL which can lead to a SIGSEGV if the >> VMError object was constructed with a zero thread argument. Instead, >> the corresponding if-line should read like the if-lines of the other >> steps which use '_thread': >> >> STEP(135, "(printing target Java thread stack)" ) >> >> // printing Java thread stack trace if it is involved in GC crash >> if (_verbose && _thread && (_thread->is_Named_thread())) { >> >> Thank you and best regards, >> Volker >> >> On Fri, Dec 11, 2009 at 6:10 AM, Yumin Qi wrote: >>> Thanks. >>> >>> I modified the code and submitted again. Please take a look again, will >>> commit if it is OK. >>> >>> Thanks >>> Yumin >>> >>> Coleen Phillimore wrote: >>>> Yumin, >>>> I've already reviewed a previous version and this still looks great >>>> to me. >>>> I hope this makes diagnosing crashes during gc much better, rather >>>> than >>>> having to decode the thread manually as you've been doing for years. >>>> Thanks everyone for the additional comments. The later suggested >>>> changes >>>> are really good. >>>> >>>> Coleen >>>> >>>> Yumin Qi wrote: >>>>> Thanks for you all the good suggestions: >>>>> >>>>> 1) update the hierarchy comments --- we miss some there >>>>> 2) Use c'tor-d'tor idiom for remembering JavaThread in GC thread >>>>> 3) Add one more STEP (135) >>>>> 4) update vmStructs so the SA can check this value. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> >>>>> David Holmes - Sun Microsystems wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> Can you update the thread hierarchy comments in thread.hpp: >>>>>> >>>>>> 49 // Class hierarchy >>>>>> 50 // - Thread >>>>>> 51 // - VMThread >>>>>> 52 // - JavaThread >>>>>> 53 // - WatcherThread >>>>>> >>>>>> This seems incomplete anyway so it would be good to update it. >>>>>> >>>>>> I would also find it useful to add more comments to the NamedThread >>>>>> class explaining the role of this new field. It really has >>>>>> nothing to do >>>>>> with being a "named thread" - but then NamedThread should really >>>>>> have been >>>>>> called something more general. Pity we can't rename it - can we? :) >>>>>> >>>>>> In vmError.cpp: >>>>>> >>>>>> 506 // printing Java thread stack trace if it is involved in GC >>>>>> crash >>>>>> 507 >>>>>> 508 if (_verbose && (_thread->is_Named_thread())) { >>>>>> >>>>>> Can/Should this be a new STEP? >>>>>> >>>>>> David >>>>>> >>>>>> Yumin Qi said the following on 12/11/09 08:50: >>>>>>> Tom, >>>>>>> >>>>>>> Thanks, changed as pointed. >>>>>>> Sorry I forget to include GC group. >>>>>>> >>>>>>> Can someone else give a look? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/6361589 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> Overall this looks pretty nice. >>>>>>>> >>>>>>>> java_thread_gc isn't a very clear name. Maybe collected_thread or >>>>>>>> processed_thread? The comment should describe it's purpose >>>>>>>> more explicitly. >>>>>>>> >>>>>>>> Is this assert really needed? >>>>>>>> >>>>>>>> + assert(thread != this, "Should not be java thread itself"); >>>>>>>> >>>>>>>> I think you should add is_NamedThread() instead of >>>>>>>> distinguishing all >>>>>>>> these cases individually. >>>>>>>> >>>>>>>> If VMThread is now a NamedTread why don't you call set_name >>>>>>>> instead of >>>>>>>> having it override name again? >>>>>>>> >>>>>>>> vmError.cpp: >>>>>>>> >>>>>>>> I think the printing output should look more like this: >>>>>>>> >>>>>>>> + st->print_cr("JavaThread " PTR_FORMAT " was being >>>>>>>> processed >>>>>>>> during the crash, id = " UINTX_FORMAT, jt, >>>>>>>> jt->osthread()->thread_id()); >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> On Dec 9, 2009, at 2:49 PM, Yumin Qi wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Fixed 6361589: Print out stack trace for target thread of GC >>>>>>>>> crash >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/6361589 >>>>>>>>> >>>>>>>>> Comments: This is a facility to assist for JVM crash analysis. To >>>>>>>>> implement this function, it needs record JavaThread which may >>>>>>>>> involve crash >>>>>>>>> somewhere in GC thread. The place chosen here is NamedThread >>>>>>>>> from which all >>>>>>>>> GC threads but VMThread derive. I change VMThread's base from >>>>>>>>> Thread to >>>>>>>>> NamedThread, so the recording of JavaThread covers for GC >>>>>>>>> threads and >>>>>>>>> VMThread. Once the JavaThread recorded in GC thread seen >>>>>>>>> during error >>>>>>>>> report, its stack trace be printed out. To test this function, >>>>>>>>> add a debug >>>>>>>>> flag CrashGCForDumpingJavaThread, once it is set, it will >>>>>>>>> crash immediately >>>>>>>>> in VMThread or GC Thread to core dump. Note this is for test >>>>>>>>> only purpose, >>>>>>>>> no defects in involved JavaThread. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>> >>> From Dmitriy.Samersoff at oracle.com Thu Oct 7 10:33:18 2010 From: Dmitriy.Samersoff at oracle.com (Dmitriy Samersoff) Date: Thu, 07 Oct 2010 21:33:18 +0400 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CACC58E.90400@oracle.com> References: <4CACC58E.90400@oracle.com> Message-ID: <4CAE045E.3080304@oracle.com> Coleen, Code looks good for me but I have a few questions (below): 1. Is it possible to create static inline size_t min_stack_allowed(){ return (size_t)(StackYellowPages+StackRedPages+StackShadowPages+ 2*BytesPerWord COMPILER2_PRESENT(+1)) * os::vm_page_size(); in os.hpp ? 1". If not: os_linux.cpp uses Linux::page_size() os_solaris.cpp uses page_size os_windows.cpp uses os::vm_page_size() I believe all three returns a correct value but is it possible to keep the same semantics across OSes i.e. always use either {Linux,Solaris,Windows}::page_size or os::vm_page_size() ? 2. We don't store calculated min_stack_allowed under windows. I'm not a windows expert - do we have a reason for it? And (a nit) I'm a little bit worried about cast from size_t to int here. -Dmitry On 2010-10-06 22:53, Coleen Phillimore wrote: > -------- Original Message -------- > Subject: Re: Review request 6983240: > guarantee((Solaris::min_stack_allowed >= > (StackYellowPages+StackRedPages...) wrong > Date: Wed, 06 Oct 2010 11:19:13 -0700 > From: Vladimir Kozlov > To: Coleen Phillimore > CC: hotspot-runtime-dev at openjdk.java.net > References: <4CAA58F4.5030100 at oracle.com> <4CAA743C.3060905 at oracle.com> > <4CAB43A0.60001 at oracle.com> <4CACB80D.6060708 at oracle.com> > > > > Looks good for me. > > Vladimir > > Coleen Phillimore wrote: >> >> Can I get one more review? >> >> webrev athttp://cr.openjdk.java.net/~coleenp/6983240_2/ >> >> Thanks, >> Coleen >> >> >> >> On 10/05/10 11:26, Coleen Phillimore wrote: >>> >>> Thanks David - some comments inline... >>> >>> On 10/04/10 20:41, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> In os_solaris.cpp this comment should now refer to 2*BytesPerWord >>> Okay. >>>> >>>> // Add in BytesPerWord times page size to account for VM stack during >>>> // class initialization depending on 32 or 64 bit VM. >>>> >>>> That said this formulation (not your I know) is confusing. What does >>>> bytesPerWord have to do with the amount of stack needed? Is this just >>>> some weird way of getting twice the amount of stack on 64-bit as >>>> 32-bit? Are the pages sizes even the same in that case? >>> Yeah, I believe it's just to account for 64 vs. 32 bit. The page >>> sizes are the same if 32 or 64 bit. I have >>>> >>>> Also in os_solaris.cpp isn't this guarantee always false: >>>> >>>> ! guarantee(os::Solaris::min_stack_allowed>= thr_min_stack(), >>>> ! "need to increase min_stack_allowed"); >>> No, it doesn't assert, because in your next mail you found that >>> thr_min_stack() is smaller than our min_stack_allowed. I could revert >>> that change but min_stack_allowed() is for the VM to get initialized >>> rather than this thr_min_stack() which is for the OS to initialize the >>> thread. I would assume the latter is always smaller than the former >>> or something is really wrong. Changing it back probably doesn't hurt >>> anything. >>> >>> Thanks, >>> Coleen >>>> >>>> AFAICS min_stack_allowed is set to one of these values: >>>> >>>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>>> os::Solaris::min_stack_allowed = 128*K; >>>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>>> os::Solaris::min_stack_allowed = 96*K; >>>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>>> os::Solaris::min_stack_allowed = 224*K; >>>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>>> os::Solaris::min_stack_allowed = 64*K; >>>> >>>> but the manpage for thr_min_stack states: >>>> >>>> thr_min_stack() will return the unsigned int THR_MIN_STACK, >>>> which is the minimum-allowable size for a thread's stack. >>>> >>>> In this implementation the default size for a user-thread's >>>> stack is one mega-byte. >>>> >>>> 1MB> all the above. ??? >>>> >>>> Cheers, >>>> David >>>> >>>> Coleen Phillimore said the following on 10/05/10 08:45: >>>>> Summary: min_stack_allowed is a compile time constant and >>>>> Stack*Pages are settable >>>>> >>>>> Also stress tested various combinations of -Xss and >>>>> -XX:StackShadowPages=n. This also fixes a bug >>>>> 6346701: stack overflow in native method results in segfault, not a >>>>> StackOverflowError >>>>> or rather it fixes the observed SEGVs with different settings of >>>>> -Xss and -XX:StackShadowPages in the evaluation. We were getting >>>>> stack overflow before the stack overflow exception was initialized, >>>>> causing infinite recusion trying to initialize it. >>>>> >>>>> Also fixed a random g++ compilation error. >>>>> >>>>> open webrev athttp://cr.openjdk.java.net/~coleenp/6983240/ >>>>> bug link athttp://bugs.sun.com/view_bug.do?bug_id=6983240 >>>>> >>>>> Thanks, >>>>> Coleen >>> >> > -- Dmitry Samersoff J2SE Sustaining team, SPB04 * Give Rabbit time and he'll always get the answer ... From Dmitriy.Samersoff at oracle.com Thu Oct 7 12:06:47 2010 From: Dmitriy.Samersoff at oracle.com (Dmitriy Samersoff) Date: Thu, 07 Oct 2010 23:06:47 +0400 Subject: Review request 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong In-Reply-To: <4CAE0D6E.2070603@oracle.com> References: <4CACC58E.90400@oracle.com> <4CAE045E.3080304@oracle.com> <4CAE0D6E.2070603@oracle.com> Message-ID: <4CAE1A47.4030908@oracle.com> Coleen, Thank you for the explanation. -Dmitry On 2010-10-07 22:11, Coleen Phillimore wrote: > I just checked it in... sorry I didn't wait. > > Dmitriy Samersoff wrote: >> Coleen, >> >> Code looks good for me but I have a few questions (below): >> >> 1. >> >> Is it possible to create >> >> static inline size_t min_stack_allowed(){ >> return >> (size_t)(StackYellowPages+StackRedPages+StackShadowPages+ >> 2*BytesPerWord COMPILER2_PRESENT(+1)) * os::vm_page_size(); >> >> in os.hpp ? >> > This would have been better but the constant value for min_stack_allowed > had some comment about being documented, so I didn't want to mess with > that. I don't actually know where it's documented though. >> 1". >> If not: >> >> os_linux.cpp uses Linux::page_size() >> os_solaris.cpp uses page_size >> os_windows.cpp uses os::vm_page_size() >> >> I believe all three returns a correct value but is it possible to keep >> the same semantics across OSes i.e. always use either >> {Linux,Solaris,Windows}::page_size or os::vm_page_size() ? >> > This does need cleanup. They should all use os::vm_page_size(). I don't > know why there was ever a linux variant. On solaris, you can have bigger > page sizes so the semantics are more complicated. >> >> 2. We don't store calculated min_stack_allowed under windows. >> I'm not a windows expert - do we have a reason for it? >> And (a nit) I'm a little bit worried about cast from size_t >> to int here. > It apparently was never in the documentation so I didn't want to add it. > Windows default page size is really big. The windows didn't compile this > final version so I had to change the local variable min_stack_allowed to > a size_t to get it through jprt, so the cast is gone. > > Thanks, > Coleen >> >> -Dmitry >> >> >> >> On 2010-10-06 22:53, Coleen Phillimore wrote: >>> -------- Original Message -------- >>> Subject: Re: Review request 6983240: >>> guarantee((Solaris::min_stack_allowed >= >>> (StackYellowPages+StackRedPages...) wrong >>> Date: Wed, 06 Oct 2010 11:19:13 -0700 >>> From: Vladimir Kozlov >>> To: Coleen Phillimore >>> CC: hotspot-runtime-dev at openjdk.java.net >>> References: <4CAA58F4.5030100 at oracle.com> <4CAA743C.3060905 at oracle.com> >>> <4CAB43A0.60001 at oracle.com> <4CACB80D.6060708 at oracle.com> >>> >>> >>> >>> Looks good for me. >>> >>> Vladimir >>> >>> Coleen Phillimore wrote: >>>> >>>> Can I get one more review? >>>> >>>> webrev athttp://cr.openjdk.java.net/~coleenp/6983240_2/ >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >>>> On 10/05/10 11:26, Coleen Phillimore wrote: >>>>> >>>>> Thanks David - some comments inline... >>>>> >>>>> On 10/04/10 20:41, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> In os_solaris.cpp this comment should now refer to 2*BytesPerWord >>>>> Okay. >>>>>> >>>>>> // Add in BytesPerWord times page size to account for VM stack during >>>>>> // class initialization depending on 32 or 64 bit VM. >>>>>> >>>>>> That said this formulation (not your I know) is confusing. What does >>>>>> bytesPerWord have to do with the amount of stack needed? Is this just >>>>>> some weird way of getting twice the amount of stack on 64-bit as >>>>>> 32-bit? Are the pages sizes even the same in that case? >>>>> Yeah, I believe it's just to account for 64 vs. 32 bit. The page >>>>> sizes are the same if 32 or 64 bit. I have >>>>>> >>>>>> Also in os_solaris.cpp isn't this guarantee always false: >>>>>> >>>>>> ! guarantee(os::Solaris::min_stack_allowed>= thr_min_stack(), >>>>>> ! "need to increase min_stack_allowed"); >>>>> No, it doesn't assert, because in your next mail you found that >>>>> thr_min_stack() is smaller than our min_stack_allowed. I could revert >>>>> that change but min_stack_allowed() is for the VM to get initialized >>>>> rather than this thr_min_stack() which is for the OS to initialize the >>>>> thread. I would assume the latter is always smaller than the former >>>>> or something is really wrong. Changing it back probably doesn't hurt >>>>> anything. >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> AFAICS min_stack_allowed is set to one of these values: >>>>>> >>>>>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>>>>> os::Solaris::min_stack_allowed = 128*K; >>>>>> ./os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp:size_t >>>>>> os::Solaris::min_stack_allowed = 96*K; >>>>>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>>>>> os::Solaris::min_stack_allowed = 224*K; >>>>>> ./os_cpu/solaris_x86/vm/os_solaris_x86.cpp:size_t >>>>>> os::Solaris::min_stack_allowed = 64*K; >>>>>> >>>>>> but the manpage for thr_min_stack states: >>>>>> >>>>>> thr_min_stack() will return the unsigned int THR_MIN_STACK, >>>>>> which is the minimum-allowable size for a thread's stack. >>>>>> >>>>>> In this implementation the default size for a user-thread's >>>>>> stack is one mega-byte. >>>>>> >>>>>> 1MB> all the above. ??? >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> Coleen Phillimore said the following on 10/05/10 08:45: >>>>>>> Summary: min_stack_allowed is a compile time constant and >>>>>>> Stack*Pages are settable >>>>>>> >>>>>>> Also stress tested various combinations of -Xss and >>>>>>> -XX:StackShadowPages=n. This also fixes a bug >>>>>>> 6346701: stack overflow in native method results in segfault, not a >>>>>>> StackOverflowError >>>>>>> or rather it fixes the observed SEGVs with different settings of >>>>>>> -Xss and -XX:StackShadowPages in the evaluation. We were getting >>>>>>> stack overflow before the stack overflow exception was initialized, >>>>>>> causing infinite recusion trying to initialize it. >>>>>>> >>>>>>> Also fixed a random g++ compilation error. >>>>>>> >>>>>>> open webrev athttp://cr.openjdk.java.net/~coleenp/6983240/ >>>>>>> bug link athttp://bugs.sun.com/view_bug.do?bug_id=6983240 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>> >>>> >>> >> >> -- Dmitry Samersoff J2SE Sustaining team, SPB04 * Give Rabbit time and he'll always get the answer ... From bob.vandette at oracle.com Thu Oct 7 12:30:48 2010 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 7 Oct 2010 15:30:48 -0400 Subject: Request for Review: 6989297 - more portability improvements Message-ID: http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ This bug tracks additional Hotspot portability improvements that have been made since the push of the larger group of changes under CR#6953477. 6953477: Increase portability and flexibility of building Hotspot These additional changes include making the UseMembar flags platform specific, the addition of dsqrt runtime call for PPC platforms, a fix to allow a jvmg1 target using gcc 4 compilers and a one off problem in attachListener_linux.cpp. http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ Bob. From vladimir.kozlov at oracle.com Thu Oct 7 13:14:26 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Oct 2010 13:14:26 -0700 Subject: Request for Review: 6989297 - more portability improvements In-Reply-To: References: Message-ID: <4CAE2A22.2010805@oracle.com> Additional cast in next file is already in main baseline now src/cpu/x86/vm/methodHandles_x86.cpp Next changeset added it: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c93c652551b5 Thanks, Vladimir Bob Vandette wrote: > http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ > > > This bug tracks additional Hotspot portability improvements that > have been made since the push of the larger group of changes under CR#6953477. > > 6953477: Increase portability and flexibility of building Hotspot > > These additional changes include making the UseMembar flags platform specific, > the addition of dsqrt runtime call for PPC platforms, a fix to allow a jvmg1 target using > gcc 4 compilers and a one off problem in attachListener_linux.cpp. > > http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ > > Bob. > From coleen.phillimore at Oracle.com Thu Oct 7 13:22:25 2010 From: coleen.phillimore at Oracle.com (Coleen Phillimore) Date: Thu, 07 Oct 2010 16:22:25 -0400 Subject: Request for Review: 6989297 - more portability improvements In-Reply-To: <4CAE2A22.2010805@oracle.com> References: <4CAE2A22.2010805@oracle.com> Message-ID: <4CAE2C01.8010703@oracle.com> I also checked that same cast into hotspot-rt today, because I thought I needed it to get through jprt. Coleen Vladimir Kozlov wrote: > Additional cast in next file is already in main baseline now > > src/cpu/x86/vm/methodHandles_x86.cpp > > Next changeset added it: > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c93c652551b5 > > Thanks, > Vladimir > > Bob Vandette wrote: >> http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ >> >> >> This bug tracks additional Hotspot portability improvements that >> have been made since the push of the larger group of changes under >> CR#6953477. >> >> 6953477: Increase portability and flexibility of building Hotspot >> >> These additional changes include making the UseMembar flags platform >> specific, >> the addition of dsqrt runtime call for PPC platforms, a fix to allow >> a jvmg1 target using >> gcc 4 compilers and a one off problem in attachListener_linux.cpp. >> >> http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ >> >> Bob. >> From David.Holmes at oracle.com Thu Oct 7 19:47:37 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 08 Oct 2010 12:47:37 +1000 Subject: Request for Review: 6989297 - more portability improvements In-Reply-To: <4CAE2C01.8010703@oracle.com> References: <4CAE2A22.2010805@oracle.com> <4CAE2C01.8010703@oracle.com> Message-ID: <4CAE8649.60704@oracle.com> Coleen Phillimore said the following on 10/08/10 06:22: > I also checked that same cast into hotspot-rt today, because I thought I > needed it to get through jprt. Also see "6990479 PTR_FORMAT needs to be a pointer format" for my rant on this. David > > Coleen > > Vladimir Kozlov wrote: >> Additional cast in next file is already in main baseline now >> >> src/cpu/x86/vm/methodHandles_x86.cpp >> >> Next changeset added it: >> >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c93c652551b5 >> >> Thanks, >> Vladimir >> >> Bob Vandette wrote: >>> http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ >>> >>> >>> This bug tracks additional Hotspot portability improvements that >>> have been made since the push of the larger group of changes under >>> CR#6953477. >>> >>> 6953477: Increase portability and flexibility of building Hotspot >>> >>> These additional changes include making the UseMembar flags platform >>> specific, >>> the addition of dsqrt runtime call for PPC platforms, a fix to allow >>> a jvmg1 target using >>> gcc 4 compilers and a one off problem in attachListener_linux.cpp. >>> >>> http://cr.openjdk.java.net/~bobv/6989297/webrev.00/ >>> >>> Bob. >>> From keith.mcguigan at oracle.com Fri Oct 8 11:35:40 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 08 Oct 2010 14:35:40 -0400 Subject: request for review (XS) Message-ID: <4CAF647C.5030903@oracle.com> New flag for turning off the printing of warnings: webrev: http://cr.openjdk.java.net/~kamg/6392697/webrev.00/ -- - Keith From coleen.phillimore at oracle.com Fri Oct 8 12:08:58 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 08 Oct 2010 15:08:58 -0400 Subject: request for review (XS) In-Reply-To: <4CAF647C.5030903@oracle.com> References: <4CAF647C.5030903@oracle.com> Message-ID: <4CAF6C4A.7090400@oracle.com> Sure, why not? Looks ok to me. Did they file another bug for the warning in the original bug? Actually, I think it was fixed some other way a long time ago, around 2006-03-01, wasn't it? Coleen Keith McGuigan wrote: > > New flag for turning off the printing of warnings: > > webrev: http://cr.openjdk.java.net/~kamg/6392697/webrev.00/ > > -- > - Keith From karen.kinnear at oracle.com Fri Oct 8 13:07:05 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Oct 2010 16:07:05 -0400 Subject: request for review (XS) In-Reply-To: <4CAF647C.5030903@oracle.com> References: <4CAF647C.5030903@oracle.com> Message-ID: <26C0ADEC-04DD-49DB-8188-CB33EB922FD8@oracle.com> Keith, Looks good. I could have sworn we added this years ago - but that a develop flag PrintJVMWarnings - which only appears to say whether you have used "deprecated?" JVM_XXX APIs. I wonder if you could change that flag to product and use it for all warnings? thanks, Karen On Oct 8, 2010, at 2:35 PM, Keith McGuigan wrote: > > New flag for turning off the printing of warnings: > > webrev: http://cr.openjdk.java.net/~kamg/6392697/webrev.00/ > > -- > - Keith From bugmail-sender at Sun.COM Fri Oct 8 13:31:06 2010 From: bugmail-sender at Sun.COM (bugmail-sender at Sun.COM) Date: Fri, 8 Oct 2010 14:31:06 -0600 (MDT) Subject: CR 6990754 Created, P3 hotspot/runtime_syst Use native memory and reference counting to implement SymbolTable Message-ID: <27335091.1286569866817.JavaMail.sbladm@swsblss3-new> *Synopsis*: Use native memory and reference counting to implement SymbolTable From David.Holmes at oracle.com Fri Oct 8 19:05:30 2010 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 09 Oct 2010 12:05:30 +1000 Subject: request for review (XS) In-Reply-To: <26C0ADEC-04DD-49DB-8188-CB33EB922FD8@oracle.com> References: <4CAF647C.5030903@oracle.com> <26C0ADEC-04DD-49DB-8188-CB33EB922FD8@oracle.com> Message-ID: <4CAFCDEA.5040900@oracle.com> Hi Karen, Karen Kinnear said the following on 10/09/10 06:07: > Looks good. > > I could have sworn we added this years ago - but that a develop flag > PrintJVMWarnings - which only appears to say whether you have > used "deprecated?" JVM_XXX APIs. I wonder if you could change > that flag to product and use it for all warnings? Keith initially proposed that approach internally but it had some issues because some of those "deprecated" JVM_XXX functions actually get called - in particular the Compiler API functions get invoked by AWT code. Because warnings are enabled by default, this would cause warnings to appears for every app that uses the AWT. Though with the current discussion regarding the "invisible VM" I'm unclear whether the accepted approach is for warnings to be enabled by default or not ??? David > thanks, > Karen > > On Oct 8, 2010, at 2:35 PM, Keith McGuigan wrote: > >> >> New flag for turning off the printing of warnings: >> >> webrev: http://cr.openjdk.java.net/~kamg/6392697/webrev.00/ >> >> -- >> - Keith > From bob.vandette at oracle.com Sat Oct 9 02:54:17 2010 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Sat, 09 Oct 2010 09:54:17 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20101009095427.5095547006@hg.openjdk.java.net> Changeset: 3dc12ef8735e Author: bobv Date: 2010-10-07 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3dc12ef8735e 6989297: Integrate additional portability improvements Reviewed-by: vladidan, dholmes ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/linux/vm/attachListener_linux.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 7491c8b96111 Author: bobv Date: 2010-10-07 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7491c8b96111 Merge From keith.mcguigan at oracle.com Tue Oct 12 09:50:44 2010 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 12 Oct 2010 16:50:44 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6392697: Additional flag needed to supress Hotspot warning messages Message-ID: <20101012165046.AB310470B3@hg.openjdk.java.net> Changeset: c77b5c592eab Author: kamg Date: 2010-10-12 10:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c77b5c592eab 6392697: Additional flag needed to supress Hotspot warning messages Summary: Apply PrintJvmWarnings flag to all warnings Reviewed-by: coleenp, phh ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp From karen.kinnear at oracle.com Thu Oct 14 05:49:44 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Thu, 14 Oct 2010 12:49:44 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 35 new changesets Message-ID: <20101014125048.7E1D947132@hg.openjdk.java.net> Changeset: 5511edd5d719 Author: iveresov Date: 2010-09-30 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5511edd5d719 6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler Summary: The workaround changes the scope of the variable Reviewed-by: phh, ysr, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: beef35b96b81 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/beef35b96b81 Added tag jdk7-b112 for changeset 5511edd5d719 ! .hgtags Changeset: 1c52033222eb Author: trims Date: 2010-10-01 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1c52033222eb Added tag hs20-b01 for changeset 5511edd5d719 ! .hgtags Changeset: c77e8f982901 Author: never Date: 2010-09-15 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c77e8f982901 6984979: OptimizeFill misses some cases with an odd memory graph Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: fd5d4527cdf5 Author: iveresov Date: 2010-09-21 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fd5d4527cdf5 6986270: guarantee(*bcp != Bytecodes::_monitorenter || exec_mode != Deoptimization::Unpack_exception) fails Summary: Propagate the compiler type of the deopting method to vframeArrayElement::unpack_on_stack() Reviewed-by: jrose, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 5867d89c129b Author: never Date: 2010-09-22 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5867d89c129b 6982537: Crash in Node*step_through_mergemem Reviewed-by: kvn ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp Changeset: 87b64980e2f1 Author: never Date: 2010-09-22 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/87b64980e2f1 6972540: sun/nio/ch/SocketChannelImpl compilation crashed when executing CompileTheWorld Reviewed-by: kvn ! 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_LinearScan.cpp Changeset: c40600e85311 Author: never Date: 2010-09-22 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c40600e85311 6986028: assert(_base == Int) failed: Not an Int in CmpINode::sub Reviewed-by: kvn, twisti ! src/share/vm/opto/stringopts.cpp Changeset: c93c652551b5 Author: twisti Date: 2010-09-24 03:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c93c652551b5 6986944: JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site Reviewed-by: never, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/ci/ciMethod.cpp Changeset: f02a8bbe6ed4 Author: roland Date: 2009-12-29 19:08 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f02a8bbe6ed4 6986046: C1 valuestack cleanup Summary: fixes an historical oddity in C1 with inlining where all of the expression stacks are kept in the topmost ValueStack instead of being in their respective ValueStacks. Reviewed-by: never Contributed-by: Christian Wimmer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/includeDB_compiler1 Changeset: 861f533d12b0 Author: roland Date: 2010-09-24 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/861f533d12b0 Merge Changeset: df015ec64052 Author: iveresov Date: 2010-09-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/df015ec64052 6987115: Non-tiered compilation policy creates unnecessary C1 threads Summary: Fixed NonTieredCompPolicy::compiler_count() to return correct thread count. Reviewed-by: twisti, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 1375bc8922e4 Author: never Date: 2010-09-27 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1375bc8922e4 6987763: assert(kind() == EmptyExceptionState) failed: only EmptyExceptionStates can be modified Reviewed-by: roland, kvn, iveresov ! src/share/vm/c1/c1_ValueStack.hpp Changeset: 8aa5fd5d2046 Author: twisti Date: 2010-09-29 00:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8aa5fd5d2046 6987634: JSR 292 assert(start_bci() >= 0 && start_bci() < code_size()) failed: correct osr_bci argument Reviewed-by: never, kvn ! src/share/vm/opto/doCall.cpp Changeset: ad0638ff8ea4 Author: roland Date: 2010-09-29 18:53 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ad0638ff8ea4 6988303: 6986046 breaks build with recent gcc Summary: fixes build break Reviewed-by: never, kvn ! src/share/vm/c1/c1_Instruction.hpp Changeset: 80c9354976b0 Author: iveresov Date: 2010-09-29 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/80c9354976b0 6988346: 6986046 breaks tiered Summary: adjusted profiling code generation to use the new ValueStack implementation; lowered optimization level for c1_LinearScan.cpp on solaris x64. Reviewed-by: kvn, never ! make/solaris/makefiles/amd64.make ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 56601ef83436 Author: kvn Date: 2010-09-30 18:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/56601ef83436 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Summary: Missing check for not empty worklist when puting memory node back on worklist and expecting address type update. Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp Changeset: 52e82a6bedaf Author: never Date: 2010-10-04 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/52e82a6bedaf 6968348: Byteswapped memory access can point to wrong location after JIT Reviewed-by: twisti, kvn, iveresov ! src/cpu/x86/vm/x86_64.ad + test/compiler/6968348/Test6968348.java Changeset: 3f9a70eb8b1f Author: iveresov Date: 2010-10-05 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/3f9a70eb8b1f 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Summary: Fix ciMethod::instructions_size() to return correct value Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp Changeset: fe08403130db Author: kvn Date: 2010-10-05 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fe08403130db 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Summary: Set upper limit 256 for ObjectAlignmentInBytes value. Reviewed-by: never, iveresov ! src/share/vm/runtime/arguments.cpp Changeset: a3f7f95b0165 Author: never Date: 2010-10-05 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a3f7f95b0165 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: iveresov, kvn, kamg ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: a50abfc67f31 Author: never Date: 2010-10-05 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a50abfc67f31 6989736: fix mapfile warnings on solaris Reviewed-by: kvn, iveresov, jcoomes ! make/linux/adlc_updater ! make/solaris/adlc_updater ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_TIERED_amd64 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc ! make/solaris/makefiles/reorder_TIERED_sparcv9 Changeset: 22e4420d19f7 Author: kvn Date: 2010-10-06 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/22e4420d19f7 Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8b10f48633dc Author: jmasa Date: 2010-09-20 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8b10f48633dc 6984287: Regularize how GC parallel workers are specified. Summary: Associate number of GC workers with the workgang as opposed to the task. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 22cace5e30b5 Author: jcoomes Date: 2010-09-08 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/22cace5e30b5 6983296: build sanity checks for jdk7 should require SS12u1 Reviewed-by: ohair ! make/solaris/makefiles/sparcWorks.make Changeset: 4805b9f4779e Author: johnc Date: 2010-09-28 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4805b9f4779e 6941395: G1: Use only lock-free versions of region stack push() and pop() Summary: Re-enable use of the lock-free versions of region stack push() and pop() by recording aborted regions in a thread-local structure, which are then processed when scanning of the region stack restarts. The previous locking versions of these routines are retained for diagnostic purposes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 894b1d7c7e01 Author: jcoomes Date: 2010-09-28 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/894b1d7c7e01 6423256: GC stacks should use a better data structure 6942771: SEGV in ParScanThreadState::take_from_overflow_stack Reviewed-by: apetrusenko, ysr, pbk ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + src/share/vm/utilities/stack.hpp + src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: c99c53f07c14 Author: ysr Date: 2010-09-29 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c99c53f07c14 6692906: CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time Summary: Inserted missing yield(check)s in closures used during the work-stealing phase of parallel concurrent marking, a missing synchronous yield-request in the cms perm gen allocation path, and a terminator-terminator for the offer_termination invocation that monitors the yield status of the concurrent marking task. Elaborated some documentation comments and made some task queue termination loop flags configurable at start-up to aid debugging in the field. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8f6f7587d292 Author: jcoomes Date: 2010-09-30 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8f6f7587d292 6988678: fatal error deadlock handling was unintentionally disabled Reviewed-by: ysr ! src/share/vm/runtime/thread.cpp Changeset: e41cd7fd68a6 Author: ysr Date: 2010-10-01 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/e41cd7fd68a6 6794422: Perm gen expansion policy for concurrent collectors Summary: Concurrent collectors should expand the perm gen without a full STW GC, but possibly by triggering a concurrent collection. Temporary band-aid for G1 where no concurrent collection is kicked off since the perm gen is not collected concurrently. Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp Changeset: 4e0094bc41fa Author: johnc Date: 2010-10-01 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4e0094bc41fa 6983311: G1: LoopTest hangs when run with -XX:+ExplicitInvokesConcurrent Summary: Clear the concurrent marking "in progress" flag while the FullGCCount_lock is held. This avoids a race that can cause back to back System.gc() calls, when ExplicitGCInvokesConcurrent is enabled, to fail to initiate a marking cycle causing the requesting thread to hang. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 32a1f7bf0c21 Author: johnc Date: 2010-10-01 21:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/32a1f7bf0c21 Merge Changeset: 6e0aac35bfa9 Author: tonyp Date: 2010-10-01 16:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6e0aac35bfa9 6980838: G1: guarantee(false) failed: thread has an unexpected active value in its SATB queue Summary: Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1. Reviewed-by: iveresov, ysr, johnc, jcoomes ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0715f0cf171d Author: jcoomes Date: 2010-10-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0715f0cf171d Merge ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 75b0735b4d04 Author: acorn Date: 2010-10-13 11:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/75b0735b4d04 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp From Alan.Bateman at oracle.com Thu Oct 14 13:21:51 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Oct 2010 21:21:51 +0100 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) Message-ID: <4CB7665F.502@oracle.com> We have changes coming in the the libraries for 4837564 that requires adding a VM option to configure if direct buffers are page aligned or not. The changes are trivial and the webrev is here: http://cr.openjdk.java.net/~alanb/4837564/hotspot/ I'm using a separate CR for the hotspot change (6992192), to keep the bug management simple. Thank, -Alan. From mandy.chung at oracle.com Thu Oct 14 13:40:24 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Oct 2010 13:40:24 -0700 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB7665F.502@oracle.com> References: <4CB7665F.502@oracle.com> Message-ID: <4CB76AB8.9090208@oracle.com> jvm.cpp line 290 - typo: you meant "sun.nio.PageAlignDirectMemory" Otherwise, looks good. Mandy On 10/14/10 13:21, Alan Bateman wrote: > > We have changes coming in the the libraries for 4837564 that requires > adding a VM option to configure if direct buffers are page aligned or > not. The changes are trivial and the webrev is here: > http://cr.openjdk.java.net/~alanb/4837564/hotspot/ > > I'm using a separate CR for the hotspot change (6992192), to keep the > bug management simple. > > Thank, > > -Alan. From karen.kinnear at oracle.com Thu Oct 14 13:49:46 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Oct 2010 16:49:46 -0400 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB76AB8.9090208@oracle.com> References: <4CB7665F.502@oracle.com> <4CB76AB8.9090208@oracle.com> Message-ID: Good catch Mandy. Other than that - the code looks good. thanks, Karen On Oct 14, 2010, at 4:40 PM, Mandy Chung wrote: > jvm.cpp line 290 - typo: you meant "sun.nio.PageAlignDirectMemory" > > Otherwise, looks good. > > Mandy > > On 10/14/10 13:21, Alan Bateman wrote: >> >> We have changes coming in the the libraries for 4837564 that >> requires adding a VM option to configure if direct buffers are page >> aligned or not. The changes are trivial and the webrev is here: >> http://cr.openjdk.java.net/~alanb/4837564/hotspot/ >> >> I'm using a separate CR for the hotspot change (6992192), to keep >> the bug management simple. >> >> Thank, >> >> -Alan. > From David.Holmes at oracle.com Thu Oct 14 16:38:10 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Oct 2010 09:38:10 +1000 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB7665F.502@oracle.com> References: <4CB7665F.502@oracle.com> Message-ID: <4CB79462.7060803@oracle.com> Alan Bateman said the following on 10/15/10 06:21: > > We have changes coming in the the libraries for 4837564 that requires > adding a VM option to configure if direct buffers are page aligned or > not. The changes are trivial and the webrev is here: > http://cr.openjdk.java.net/~alanb/4837564/hotspot/ What am I missing here. We set a VM option that sets a property. Why doesn't the end user just set the property directly ??? David > I'm using a separate CR for the hotspot change (6992192), to keep the > bug management simple. > > Thank, > > -Alan. From Alan.Bateman at oracle.com Fri Oct 15 01:02:08 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Oct 2010 09:02:08 +0100 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB79462.7060803@oracle.com> References: <4CB7665F.502@oracle.com> <4CB79462.7060803@oracle.com> Message-ID: <4CB80A80.10600@oracle.com> David Holmes wrote: > : > What am I missing here. We set a VM option that sets a property. Why > doesn't the end user just set the property directly ??? It has to be the command-line as explicitly called System.setProperty may be too late. The reason for making it a VM option is that its a comrade to the existing MaxDirectMemorySize option, and it might be strange/inconsistent to configure the same resource partly with a VM option and partly with a system property. -Alan From Alan.Bateman at oracle.com Fri Oct 15 01:06:57 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Oct 2010 09:06:57 +0100 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB76AB8.9090208@oracle.com> References: <4CB7665F.502@oracle.com> <4CB76AB8.9090208@oracle.com> Message-ID: <4CB80BA1.4070006@oracle.com> Mandy Chung wrote: > jvm.cpp line 290 - typo: you meant "sun.nio.PageAlignDirectMemory" Thanks Mandy - I'll fix that typo in in the comment. -Alan. From David.Holmes at oracle.com Fri Oct 15 04:44:57 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Oct 2010 21:44:57 +1000 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB80A80.10600@oracle.com> References: <4CB7665F.502@oracle.com> <4CB79462.7060803@oracle.com> <4CB80A80.10600@oracle.com> Message-ID: <4CB83EB9.3010200@oracle.com> Alan Bateman said the following on 10/15/10 18:02: > David Holmes wrote: >> : >> What am I missing here. We set a VM option that sets a property. Why >> doesn't the end user just set the property directly ??? > It has to be the command-line as explicitly called System.setProperty > may be too late. The reason for making it a VM option is that its a > comrade to the existing MaxDirectMemorySize option, and it might be > strange/inconsistent to configure the same resource partly with a VM > option and partly with a system property. Sorry but I don't understand why either of them are VM options when it would appear you could just do: java -Dsun.nio.MaxDirectMemorySize=16M -Dsun.nio.PageAlignDirectMemory=true David From Alan.Bateman at oracle.com Fri Oct 15 04:50:56 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Oct 2010 12:50:56 +0100 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB83EB9.3010200@oracle.com> References: <4CB7665F.502@oracle.com> <4CB79462.7060803@oracle.com> <4CB80A80.10600@oracle.com> <4CB83EB9.3010200@oracle.com> Message-ID: <4CB84020.10907@oracle.com> David Holmes wrote: > : > Sorry but I don't understand why either of them are VM options when it > would appear you could just do: > > java -Dsun.nio.MaxDirectMemorySize=16M > -Dsun.nio.PageAlignDirectMemory=true -XX:MaxDirectMemorySize is a long standing VM option, used in my environments so I don't think we can change it. -Alan. From David.Holmes at oracle.com Fri Oct 15 05:00:15 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Oct 2010 22:00:15 +1000 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB84020.10907@oracle.com> References: <4CB7665F.502@oracle.com> <4CB79462.7060803@oracle.com> <4CB80A80.10600@oracle.com> <4CB83EB9.3010200@oracle.com> <4CB84020.10907@oracle.com> Message-ID: <4CB8424F.6040109@oracle.com> Alan Bateman said the following on 10/15/10 21:50: > David Holmes wrote: >> : >> Sorry but I don't understand why either of them are VM options when it >> would appear you could just do: >> >> java -Dsun.nio.MaxDirectMemorySize=16M >> -Dsun.nio.PageAlignDirectMemory=true > -XX:MaxDirectMemorySize is a long standing VM option, used in my > environments so I don't think we can change it. You don't need to change it. All it does is set the property, so the user can do that too. You could deprecate the use of -XX option but it will still be there. David From Alan.Bateman at oracle.com Fri Oct 15 05:04:40 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Oct 2010 13:04:40 +0100 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB8424F.6040109@oracle.com> References: <4CB7665F.502@oracle.com> <4CB79462.7060803@oracle.com> <4CB80A80.10600@oracle.com> <4CB83EB9.3010200@oracle.com> <4CB84020.10907@oracle.com> <4CB8424F.6040109@oracle.com> Message-ID: <4CB84358.5080409@oracle.com> David Holmes wrote: > Alan Bateman said the following on 10/15/10 21:50: >> David Holmes wrote: >>> : >>> Sorry but I don't understand why either of them are VM options when >>> it would appear you could just do: >>> >>> java -Dsun.nio.MaxDirectMemorySize=16M >>> -Dsun.nio.PageAlignDirectMemory=true >> -XX:MaxDirectMemorySize is a long standing VM option, used in my >> environments so I don't think we can change it. > > You don't need to change it. All it does is set the property, so the > user can do that too. You could deprecate the use of -XX option but it > will still be there. It can't currently be set on the command line as it is overridden by the VM. I believe that was the intention when this was added many years ago (before my time). I don't have a strong objection to changing this but it does mean that we would have to document/support these properties and at the same time continue to support the long standing VM option. -Alan. From David.Holmes at oracle.com Fri Oct 15 05:10:21 2010 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 15 Oct 2010 22:10:21 +1000 Subject: 6992192: Need option to configure if direct memory is page aligned (XS) In-Reply-To: <4CB84358.5080409@oracle.com> References: <4CB7665F.502@oracle.com> <4CB79462.7060803@oracle.com> <4CB80A80.10600@oracle.com> <4CB83EB9.3010200@oracle.com> <4CB84020.10907@oracle.com> <4CB8424F.6040109@oracle.com> <4CB84358.5080409@oracle.com> Message-ID: <4CB844AD.7030608@oracle.com> Alan Bateman said the following on 10/15/10 22:04: > David Holmes wrote: >> Alan Bateman said the following on 10/15/10 21:50: >>> David Holmes wrote: >>>> : >>>> Sorry but I don't understand why either of them are VM options when >>>> it would appear you could just do: >>>> >>>> java -Dsun.nio.MaxDirectMemorySize=16M >>>> -Dsun.nio.PageAlignDirectMemory=true >>> -XX:MaxDirectMemorySize is a long standing VM option, used in my >>> environments so I don't think we can change it. >> >> You don't need to change it. All it does is set the property, so the >> user can do that too. You could deprecate the use of -XX option but it >> will still be there. > It can't currently be set on the command line as it is overridden by the > VM. I believe that was the intention when this was added many years ago > (before my time). I don't have a strong objection to changing this but > it does mean that we would have to document/support these properties and > at the same time continue to support the long standing VM option. Okay I see the VM code would have to be moved to change this. But it seems really strange to have this set up this way. Why disallow overriding with -D when the same user that puts the -D on the command line puts the -XX? Maybe this was some strange security thing where the VM was in a wrapper that could take -D args but not -XX and the VM settings were not to be modified. Anyway I'll back off. It make me cringe, but I'll back off. Cheers, David From coleen.phillimore at Sun.COM Tue Oct 19 15:11:30 2010 From: coleen.phillimore at Sun.COM (coleen phillimore) Date: Tue, 19 Oct 2010 18:11:30 -0400 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel Message-ID: <4CBE1792.8060301@Sun.COM> Summary: allocate methodData before taking out the MethodData_lock open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 Thanks to Ramki for the diagnosis and suggestion for the fix. Coleen From tom.rodriguez at oracle.com Tue Oct 19 15:34:52 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 19 Oct 2010 15:34:52 -0700 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBE1792.8060301@Sun.COM> References: <4CBE1792.8060301@Sun.COM> Message-ID: <2B6B0496-5F64-4C9A-9F11-48115DC716AE@oracle.com> On Oct 19, 2010, at 3:11 PM, coleen phillimore wrote: > Summary: allocate methodData before taking out the MethodData_lock > open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 > > Thanks to Ramki for the diagnosis and suggestion for the fix. That looks ok, though if the only purpose of MethodData_lock is setting that field we could just as well use a cmpxchg_ptr to set the method data field and no lock. One less heavyweight lock seems good. tom > > Coleen From David.Holmes at oracle.com Tue Oct 19 15:59:46 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 20 Oct 2010 08:59:46 +1000 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBE1792.8060301@Sun.COM> References: <4CBE1792.8060301@Sun.COM> Message-ID: <4CBE22E2.8090808@oracle.com> Hi Coleen, coleen phillimore said the following on 10/20/10 08:11: > Summary: allocate methodData before taking out the MethodData_lock > open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 > > Thanks to Ramki for the diagnosis and suggestion for the fix. This is a variation on the unsafe double-checked-locking idiom. 286 if (method->method_data() == NULL) { 291 methodDataOop method_data = oopFactory::new_methodData(method, CHECK); 292 MutexLocker ml(MethodData_lock, THREAD); 295 if (method->method_data() == NULL) { 296 method->set_method_data(method_data); In general terms any stores associated with the method_data construction are not guaranteed to be visible by the time set_method_data is called. A second thread could then see a non-null method->method_data() but access uninitialized method_data values. A general solution would need memory barriers before 286 and after 291 to ensure correctness on all platforms. A simpler, though perhaps heavier solution would be to use a MutexUnlocker around the allocation: MutexLocker ml(MethodData_lock, THREAD); if (method->method_data() == NULL) { methodDataOop method_data = NULL; { // need new block for scope MutexUnLocker ml(MethodData_lock, THREAD); method_data = oopFactory::new_methodData(method, CHECK); } // someone might have beaten us to it if (method->method_data() == NULL) { method->set_method_data(method_data); } } A lock-less solution as Tom proposed would also require suitable memory-barriers. David From igor.veresov at oracle.com Tue Oct 19 23:52:47 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 19 Oct 2010 23:52:47 -0700 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBE22E2.8090808@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> Message-ID: <4CBE91BF.20503@oracle.com> David, There's no question a store-store barrier is needed after 291 for non-TSO if we were to make it lock-free (with the current code monitor lock should contain such barrier anyway). But why do you think it needs barrier before 286? There seems to be nothing wrong in allocating an extra MDO... Moreover, the code is written under this assumption. igor On 10/19/10 3:59 PM, David Holmes wrote: > Hi Coleen, > > coleen phillimore said the following on 10/20/10 08:11: >> Summary: allocate methodData before taking out the MethodData_lock >> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >> >> Thanks to Ramki for the diagnosis and suggestion for the fix. > > This is a variation on the unsafe double-checked-locking idiom. > > 286 if (method->method_data() == NULL) { > 291 methodDataOop method_data = oopFactory::new_methodData(method, CHECK); > 292 MutexLocker ml(MethodData_lock, THREAD); > 295 if (method->method_data() == NULL) { > 296 method->set_method_data(method_data); > > In general terms any stores associated with the method_data construction > are not guaranteed to be visible by the time set_method_data is called. > A second thread could then see a non-null method->method_data() but > access uninitialized method_data values. > > A general solution would need memory barriers before 286 and after 291 > to ensure correctness on all platforms. A simpler, though perhaps > heavier solution would be to use a MutexUnlocker around the allocation: > > MutexLocker ml(MethodData_lock, THREAD); > if (method->method_data() == NULL) { > methodDataOop method_data = NULL; > { // need new block for scope > MutexUnLocker ml(MethodData_lock, THREAD); > method_data = oopFactory::new_methodData(method, CHECK); > } > // someone might have beaten us to it > if (method->method_data() == NULL) { > method->set_method_data(method_data); > } > } > > A lock-less solution as Tom proposed would also require suitable > memory-barriers. > > David From karen.kinnear at oracle.com Tue Oct 19 23:57:50 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 20 Oct 2010 06:57:50 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 16 new changesets Message-ID: <20101020065818.4D641472B6@hg.openjdk.java.net> Changeset: 75588558f1bf Author: never Date: 2010-10-07 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/75588558f1bf 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp Changeset: a222fcfba398 Author: twisti Date: 2010-10-08 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a222fcfba398 6990549: Zero and Shark fixes after 6978355 and 6953144 Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/shark/sharkCompiler.hpp Changeset: d55217dc206f Author: twisti Date: 2010-10-11 04:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d55217dc206f 6829194: JSR 292 needs to support compressed oops Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: a932f331ef90 Author: twisti Date: 2010-10-12 02:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a932f331ef90 6991065: missed a review comment in 6829194 Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp Changeset: c393f046f4c5 Author: iveresov Date: 2010-10-12 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c393f046f4c5 6991512: G1 barriers fail with 64bit C1 Summary: Fix compare-and-swap intrinsic problem with G1 post-barriers and issue with branch ranges in G1 stubs on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 5beba6174298 Author: twisti Date: 2010-10-13 01:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5beba6174298 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Reviewed-by: never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp + test/compiler/6987555/Test6987555.java Changeset: ecca2e3e2767 Author: twisti Date: 2010-10-13 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ecca2e3e2767 Merge Changeset: 357451a9ae6a Author: roland Date: 2010-10-13 10:29 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/357451a9ae6a 6991211: assert failure on sparc: "can not have caller-save register operands at calls" Summary: fixes sparc only assert failure following 6972540 Reviewed-by: never ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp Changeset: 94d77a279225 Author: roland Date: 2010-10-13 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/94d77a279225 Merge Changeset: b98784e85f71 Author: kvn Date: 2010-10-14 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b98784e85f71 Merge Changeset: c32059ef4dc0 Author: johnc Date: 2010-10-12 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c32059ef4dc0 6971296: G1: simplify G1RemSet class hierarchy Summary: Remove G1RemSet base class and StupidG1RemSet class; rename HRInto_G1RemSet to just G1RemSet. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.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/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b14ec34b1e07 Author: jcoomes Date: 2010-10-12 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b14ec34b1e07 6989448: G1: refactor and simplify G1ParScanThreadState Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: ee813f7b46e4 Author: jcoomes Date: 2010-10-14 11:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ee813f7b46e4 Merge Changeset: beba40b26a79 Author: acorn Date: 2010-10-15 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/beba40b26a79 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: 07a218de38cb Author: never Date: 2010-10-15 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/07a218de38cb 6992477: fix for 6991512 broke sparc barriers Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 75ab0162aa84 Author: never Date: 2010-10-18 09:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/75ab0162aa84 Merge From David.Holmes at oracle.com Wed Oct 20 00:16:53 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 20 Oct 2010 17:16:53 +1000 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBE91BF.20503@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> Message-ID: <4CBE9765.2040807@oracle.com> HI Igor, Igor Veresov said the following on 10/20/10 16:52: > There's no question a store-store barrier is needed after 291 for > non-TSO if we were to make it lock-free (with the current code monitor > lock should contain such barrier anyway). There's no requirement for a storestore barrier when acquiring a lock. You will happen to get that on sparc and x86 if the lock acquisition involves a CAS, but that is not true on other archs. In general terms it is considered safe to move stores into a critical section at which time it can be reordered with other stores inside the critical section. > But why do you think it needs barrier before 286? I was thinking in very general terms from age old discussions on DCL whereby from a theoretical perspective you need a read-barrier to make sure that the load through the pointer must read from main memory if the pointer itself was freshly read from main memory. In our terms we would need a loadload barrier between the load of method->method_data and any subsequent loads via that pointer. Again this would be a noop on x86 and sparc, but not other archs. > There seems to be > nothing wrong in allocating an extra MDO... Moreover, the code is > written under this assumption. Right. If it were not safe/correct for more than one thread to create a MDO, and have all but one thrown away, then we'd have a different problem to solve. Which reminds we, if another thread does beat us to storing the MDO then we need to delete the one we created. Cheers, David > > igor > > On 10/19/10 3:59 PM, David Holmes wrote: >> Hi Coleen, >> >> coleen phillimore said the following on 10/20/10 08:11: >>> Summary: allocate methodData before taking out the MethodData_lock >>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>> >>> Thanks to Ramki for the diagnosis and suggestion for the fix. >> >> This is a variation on the unsafe double-checked-locking idiom. >> >> 286 if (method->method_data() == NULL) { >> 291 methodDataOop method_data = oopFactory::new_methodData(method, >> CHECK); >> 292 MutexLocker ml(MethodData_lock, THREAD); >> 295 if (method->method_data() == NULL) { >> 296 method->set_method_data(method_data); >> >> In general terms any stores associated with the method_data construction >> are not guaranteed to be visible by the time set_method_data is called. >> A second thread could then see a non-null method->method_data() but >> access uninitialized method_data values. >> >> A general solution would need memory barriers before 286 and after 291 >> to ensure correctness on all platforms. A simpler, though perhaps >> heavier solution would be to use a MutexUnlocker around the allocation: >> >> MutexLocker ml(MethodData_lock, THREAD); >> if (method->method_data() == NULL) { >> methodDataOop method_data = NULL; >> { // need new block for scope >> MutexUnLocker ml(MethodData_lock, THREAD); >> method_data = oopFactory::new_methodData(method, CHECK); >> } >> // someone might have beaten us to it >> if (method->method_data() == NULL) { >> method->set_method_data(method_data); >> } >> } >> >> A lock-less solution as Tom proposed would also require suitable >> memory-barriers. >> >> David > From igor.veresov at oracle.com Wed Oct 20 01:31:48 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 20 Oct 2010 01:31:48 -0700 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBE9765.2040807@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> Message-ID: <4CBEA8F4.6000605@oracle.com> On 10/20/10 12:16 AM, David Holmes wrote: > HI Igor, > > Igor Veresov said the following on 10/20/10 16:52: >> There's no question a store-store barrier is needed after 291 for >> non-TSO if we were to make it lock-free (with the current code monitor >> lock should contain such barrier anyway). > > There's no requirement for a storestore barrier when acquiring a lock. > You will happen to get that on sparc and x86 if the lock acquisition > involves a CAS, but that is not true on other archs. In general terms it > is considered safe to move stores into a critical section at which time > it can be reordered with other stores inside the critical section. Yes, that's what I meant. Basically a lock should guarantee that all stores before the lock precede stores in the critical section, which is essentially a storestore barrier. > >> But why do you think it needs barrier before 286? > > I was thinking in very general terms from age old discussions on DCL > whereby from a theoretical perspective you need a read-barrier to make > sure that the load through the pointer must read from main memory if the > pointer itself was freshly read from main memory. In our terms we would > need a loadload barrier between the load of method->method_data and any > subsequent loads via that pointer. Again this would be a noop on x86 and > sparc, but not other archs. > >> There seems to be nothing wrong in allocating an extra MDO... >> Moreover, the code is written under this assumption. > > Right. If it were not safe/correct for more than one thread to create a > MDO, and have all but one thrown away, then we'd have a different > problem to solve. Which reminds we, if another thread does beat us to > storing the MDO then we need to delete the one we created. Yes, perhaps we can try to deallocate. Although I suppose the race should occur infrequently and GC will take care of the unused copy anyway. igor > > Cheers, > David > >> >> igor >> >> On 10/19/10 3:59 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> coleen phillimore said the following on 10/20/10 08:11: >>>> Summary: allocate methodData before taking out the MethodData_lock >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>> >>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>> >>> This is a variation on the unsafe double-checked-locking idiom. >>> >>> 286 if (method->method_data() == NULL) { >>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>> CHECK); >>> 292 MutexLocker ml(MethodData_lock, THREAD); >>> 295 if (method->method_data() == NULL) { >>> 296 method->set_method_data(method_data); >>> >>> In general terms any stores associated with the method_data construction >>> are not guaranteed to be visible by the time set_method_data is called. >>> A second thread could then see a non-null method->method_data() but >>> access uninitialized method_data values. >>> >>> A general solution would need memory barriers before 286 and after 291 >>> to ensure correctness on all platforms. A simpler, though perhaps >>> heavier solution would be to use a MutexUnlocker around the allocation: >>> >>> MutexLocker ml(MethodData_lock, THREAD); >>> if (method->method_data() == NULL) { >>> methodDataOop method_data = NULL; >>> { // need new block for scope >>> MutexUnLocker ml(MethodData_lock, THREAD); >>> method_data = oopFactory::new_methodData(method, CHECK); >>> } >>> // someone might have beaten us to it >>> if (method->method_data() == NULL) { >>> method->set_method_data(method_data); >>> } >>> } >>> >>> A lock-less solution as Tom proposed would also require suitable >>> memory-barriers. >>> >>> David >> From David.Holmes at oracle.com Wed Oct 20 01:44:44 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 20 Oct 2010 18:44:44 +1000 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBEA8F4.6000605@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> <4CBEA8F4.6000605@oracle.com> Message-ID: <4CBEABFC.1020804@oracle.com> Igor Veresov said the following on 10/20/10 18:31: > On 10/20/10 12:16 AM, David Holmes wrote: >> Igor Veresov said the following on 10/20/10 16:52: >>> There's no question a store-store barrier is needed after 291 for >>> non-TSO if we were to make it lock-free (with the current code monitor >>> lock should contain such barrier anyway). >> >> There's no requirement for a storestore barrier when acquiring a lock. >> You will happen to get that on sparc and x86 if the lock acquisition >> involves a CAS, but that is not true on other archs. In general terms it >> is considered safe to move stores into a critical section at which time >> it can be reordered with other stores inside the critical section. > > Yes, that's what I meant. Basically a lock should guarantee that all > stores before the lock precede stores in the critical section, which is > essentially a storestore barrier. But my point is that locks in general don't guarantee this. >> Right. If it were not safe/correct for more than one thread to create a >> MDO, and have all but one thrown away, then we'd have a different >> problem to solve. Which reminds we, if another thread does beat us to >> storing the MDO then we need to delete the one we created. > > Yes, perhaps we can try to deallocate. Although I suppose the race > should occur infrequently and GC will take care of the unused copy anyway. Ah! Is this a GC'able oop we are creating? I had assumed it was a C/C++ object. David > igor > >> >> Cheers, >> David >> >>> >>> igor >>> >>> On 10/19/10 3:59 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> coleen phillimore said the following on 10/20/10 08:11: >>>>> Summary: allocate methodData before taking out the MethodData_lock >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>>> >>>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>>> >>>> This is a variation on the unsafe double-checked-locking idiom. >>>> >>>> 286 if (method->method_data() == NULL) { >>>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>>> CHECK); >>>> 292 MutexLocker ml(MethodData_lock, THREAD); >>>> 295 if (method->method_data() == NULL) { >>>> 296 method->set_method_data(method_data); >>>> >>>> In general terms any stores associated with the method_data >>>> construction >>>> are not guaranteed to be visible by the time set_method_data is called. >>>> A second thread could then see a non-null method->method_data() but >>>> access uninitialized method_data values. >>>> >>>> A general solution would need memory barriers before 286 and after 291 >>>> to ensure correctness on all platforms. A simpler, though perhaps >>>> heavier solution would be to use a MutexUnlocker around the allocation: >>>> >>>> MutexLocker ml(MethodData_lock, THREAD); >>>> if (method->method_data() == NULL) { >>>> methodDataOop method_data = NULL; >>>> { // need new block for scope >>>> MutexUnLocker ml(MethodData_lock, THREAD); >>>> method_data = oopFactory::new_methodData(method, CHECK); >>>> } >>>> // someone might have beaten us to it >>>> if (method->method_data() == NULL) { >>>> method->set_method_data(method_data); >>>> } >>>> } >>>> >>>> A lock-less solution as Tom proposed would also require suitable >>>> memory-barriers. >>>> >>>> David >>> > From coleen.phillimore at oracle.com Wed Oct 20 07:24:54 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Oct 2010 10:24:54 -0400 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBEABFC.1020804@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> <4CBEA8F4.6000605@oracle.com> <4CBEABFC.1020804@oracle.com> Message-ID: <4CBEFBB6.5060209@oracle.com> Thank you for the discussion. I am reimplementing this with a CAS as Tom suggested. I guess it's not such a simple fix, anyway, see below: David Holmes wrote: > Igor Veresov said the following on 10/20/10 18:31: >> On 10/20/10 12:16 AM, David Holmes wrote: >>> Igor Veresov said the following on 10/20/10 16:52: >>>> There's no question a store-store barrier is needed after 291 for >>>> non-TSO if we were to make it lock-free (with the current code monitor >>>> lock should contain such barrier anyway). >>> >>> There's no requirement for a storestore barrier when acquiring a lock. >>> You will happen to get that on sparc and x86 if the lock acquisition >>> involves a CAS, but that is not true on other archs. In general >>> terms it >>> is considered safe to move stores into a critical section at which time >>> it can be reordered with other stores inside the critical section. >> >> Yes, that's what I meant. Basically a lock should guarantee that all >> stores before the lock precede stores in the critical section, which >> is essentially a storestore barrier. > > But my point is that locks in general don't guarantee this. > Does a CAS guarantee this? If there isn't a guarantee, I will add an Atomic::storestore(), plus make _method_data volatile. >>> Right. If it were not safe/correct for more than one thread to create a >>> MDO, and have all but one thrown away, then we'd have a different >>> problem to solve. Which reminds we, if another thread does beat us to >>> storing the MDO then we need to delete the one we created. >> >> Yes, perhaps we can try to deallocate. Although I suppose the race >> should occur infrequently and GC will take care of the unused copy >> anyway. > > Ah! Is this a GC'able oop we are creating? I had assumed it was a > C/C++ object. > Right now the extra MDO would get GC'ed because nothing references it and it's in the PermGen. But we're moving everything out of the PermGen. When it's not allocated in the PermGen, this extra MDO will get deallocated when the memory region associated with it's classloader is deallocated. I think we should revisit this thing though at that point because it would be leaked with the bootclassloader. Thanks, Coleen > David > >> igor >> >>> >>> Cheers, >>> David >>> >>>> >>>> igor >>>> >>>> On 10/19/10 3:59 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> coleen phillimore said the following on 10/20/10 08:11: >>>>>> Summary: allocate methodData before taking out the MethodData_lock >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>>>> >>>>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>>>> >>>>> This is a variation on the unsafe double-checked-locking idiom. >>>>> >>>>> 286 if (method->method_data() == NULL) { >>>>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>>>> CHECK); >>>>> 292 MutexLocker ml(MethodData_lock, THREAD); >>>>> 295 if (method->method_data() == NULL) { >>>>> 296 method->set_method_data(method_data); >>>>> >>>>> In general terms any stores associated with the method_data >>>>> construction >>>>> are not guaranteed to be visible by the time set_method_data is >>>>> called. >>>>> A second thread could then see a non-null method->method_data() but >>>>> access uninitialized method_data values. >>>>> >>>>> A general solution would need memory barriers before 286 and after >>>>> 291 >>>>> to ensure correctness on all platforms. A simpler, though perhaps >>>>> heavier solution would be to use a MutexUnlocker around the >>>>> allocation: >>>>> >>>>> MutexLocker ml(MethodData_lock, THREAD); >>>>> if (method->method_data() == NULL) { >>>>> methodDataOop method_data = NULL; >>>>> { // need new block for scope >>>>> MutexUnLocker ml(MethodData_lock, THREAD); >>>>> method_data = oopFactory::new_methodData(method, CHECK); >>>>> } >>>>> // someone might have beaten us to it >>>>> if (method->method_data() == NULL) { >>>>> method->set_method_data(method_data); >>>>> } >>>>> } >>>>> >>>>> A lock-less solution as Tom proposed would also require suitable >>>>> memory-barriers. >>>>> >>>>> David >>>> >> From tom.rodriguez at oracle.com Wed Oct 20 13:43:20 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 20 Oct 2010 13:43:20 -0700 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBEFBB6.5060209@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> <4CBEA8F4.6000605@oracle.com> <4CBEABFC.1020804@oracle.com> <4CBEFBB6.5060209@oracle.com> Message-ID: <003449EF-3E07-46C0-A518-2A046B895BD3@oracle.com> On Oct 20, 2010, at 7:24 AM, Coleen Phillimore wrote: > > Thank you for the discussion. I am reimplementing this with a CAS as Tom suggested. I guess it's not such a simple fix, anyway, see below: > > David Holmes wrote: >> Igor Veresov said the following on 10/20/10 18:31: >>> On 10/20/10 12:16 AM, David Holmes wrote: >>>> Igor Veresov said the following on 10/20/10 16:52: >>>>> There's no question a store-store barrier is needed after 291 for >>>>> non-TSO if we were to make it lock-free (with the current code monitor >>>>> lock should contain such barrier anyway). >>>> >>>> There's no requirement for a storestore barrier when acquiring a lock. >>>> You will happen to get that on sparc and x86 if the lock acquisition >>>> involves a CAS, but that is not true on other archs. In general terms it >>>> is considered safe to move stores into a critical section at which time >>>> it can be reordered with other stores inside the critical section. >>> >>> Yes, that's what I meant. Basically a lock should guarantee that all stores before the lock precede stores in the critical section, which is essentially a storestore barrier. >> >> But my point is that locks in general don't guarantee this. >> > Does a CAS guarantee this? If there isn't a guarantee, I will add an Atomic::storestore(), plus make _method_data volatile. It should. > >>>> Right. If it were not safe/correct for more than one thread to create a >>>> MDO, and have all but one thrown away, then we'd have a different >>>> problem to solve. Which reminds we, if another thread does beat us to >>>> storing the MDO then we need to delete the one we created. >>> >>> Yes, perhaps we can try to deallocate. Although I suppose the race should occur infrequently and GC will take care of the unused copy anyway. >> >> Ah! Is this a GC'able oop we are creating? I had assumed it was a C/C++ object. >> > Right now the extra MDO would get GC'ed because nothing references it and it's in the PermGen. But we're moving everything out of the PermGen. When it's not allocated in the PermGen, this extra MDO will get deallocated when the memory region associated with it's classloader is deallocated. I think we should revisit this thing though at that point because it would be leaked with the bootclassloader. Freeing won't be easy in the new world since we're using pointer bumping. We might actually need to use a lock for this so that we don't allocate wasted space, though maybe it's rare enough that we could ignore it. tom > > Thanks, > Coleen >> David >> >>> igor >>> >>>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> igor >>>>> >>>>> On 10/19/10 3:59 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> coleen phillimore said the following on 10/20/10 08:11: >>>>>>> Summary: allocate methodData before taking out the MethodData_lock >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>>>>> >>>>>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>>>>> >>>>>> This is a variation on the unsafe double-checked-locking idiom. >>>>>> >>>>>> 286 if (method->method_data() == NULL) { >>>>>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>>>>> CHECK); >>>>>> 292 MutexLocker ml(MethodData_lock, THREAD); >>>>>> 295 if (method->method_data() == NULL) { >>>>>> 296 method->set_method_data(method_data); >>>>>> >>>>>> In general terms any stores associated with the method_data construction >>>>>> are not guaranteed to be visible by the time set_method_data is called. >>>>>> A second thread could then see a non-null method->method_data() but >>>>>> access uninitialized method_data values. >>>>>> >>>>>> A general solution would need memory barriers before 286 and after 291 >>>>>> to ensure correctness on all platforms. A simpler, though perhaps >>>>>> heavier solution would be to use a MutexUnlocker around the allocation: >>>>>> >>>>>> MutexLocker ml(MethodData_lock, THREAD); >>>>>> if (method->method_data() == NULL) { >>>>>> methodDataOop method_data = NULL; >>>>>> { // need new block for scope >>>>>> MutexUnLocker ml(MethodData_lock, THREAD); >>>>>> method_data = oopFactory::new_methodData(method, CHECK); >>>>>> } >>>>>> // someone might have beaten us to it >>>>>> if (method->method_data() == NULL) { >>>>>> method->set_method_data(method_data); >>>>>> } >>>>>> } >>>>>> >>>>>> A lock-less solution as Tom proposed would also require suitable >>>>>> memory-barriers. >>>>>> >>>>>> David >>>>> >>> From paul.hohensee at oracle.com Wed Oct 20 14:12:11 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 20 Oct 2010 17:12:11 -0400 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <003449EF-3E07-46C0-A518-2A046B895BD3@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> <4CBEA8F4.6000605@oracle.com> <4CBEABFC.1020804@oracle.com> <4CBEFBB6.5060209@oracle.com> <003449EF-3E07-46C0-A518-2A046B895BD3@oracle.com> Message-ID: <4CBF5B2B.3090606@oracle.com> Atomic::cmpxchg() guarantees a membar, even if the actual hw cas instruction (assuming there is one: ppc used load-locked/store-conditional) doesn't guarantee it. So use Atomic::cmpxchg() with confidence. :) Paul On 10/20/10 4:43 PM, Tom Rodriguez wrote: > On Oct 20, 2010, at 7:24 AM, Coleen Phillimore wrote: > >> Thank you for the discussion. I am reimplementing this with a CAS as Tom suggested. I guess it's not such a simple fix, anyway, see below: >> >> David Holmes wrote: >>> Igor Veresov said the following on 10/20/10 18:31: >>>> On 10/20/10 12:16 AM, David Holmes wrote: >>>>> Igor Veresov said the following on 10/20/10 16:52: >>>>>> There's no question a store-store barrier is needed after 291 for >>>>>> non-TSO if we were to make it lock-free (with the current code monitor >>>>>> lock should contain such barrier anyway). >>>>> There's no requirement for a storestore barrier when acquiring a lock. >>>>> You will happen to get that on sparc and x86 if the lock acquisition >>>>> involves a CAS, but that is not true on other archs. In general terms it >>>>> is considered safe to move stores into a critical section at which time >>>>> it can be reordered with other stores inside the critical section. >>>> Yes, that's what I meant. Basically a lock should guarantee that all stores before the lock precede stores in the critical section, which is essentially a storestore barrier. >>> But my point is that locks in general don't guarantee this. >>> >> Does a CAS guarantee this? If there isn't a guarantee, I will add an Atomic::storestore(), plus make _method_data volatile. > It should. > >>>>> Right. If it were not safe/correct for more than one thread to create a >>>>> MDO, and have all but one thrown away, then we'd have a different >>>>> problem to solve. Which reminds we, if another thread does beat us to >>>>> storing the MDO then we need to delete the one we created. >>>> Yes, perhaps we can try to deallocate. Although I suppose the race should occur infrequently and GC will take care of the unused copy anyway. >>> Ah! Is this a GC'able oop we are creating? I had assumed it was a C/C++ object. >>> >> Right now the extra MDO would get GC'ed because nothing references it and it's in the PermGen. But we're moving everything out of the PermGen. When it's not allocated in the PermGen, this extra MDO will get deallocated when the memory region associated with it's classloader is deallocated. I think we should revisit this thing though at that point because it would be leaked with the bootclassloader. > Freeing won't be easy in the new world since we're using pointer bumping. We might actually need to use a lock for this so that we don't allocate wasted space, though maybe it's rare enough that we could ignore it. > > tom > >> Thanks, >> Coleen >>> David >>> >>>> igor >>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> igor >>>>>> >>>>>> On 10/19/10 3:59 PM, David Holmes wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> coleen phillimore said the following on 10/20/10 08:11: >>>>>>>> Summary: allocate methodData before taking out the MethodData_lock >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>>>>>> >>>>>>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>>>>>> This is a variation on the unsafe double-checked-locking idiom. >>>>>>> >>>>>>> 286 if (method->method_data() == NULL) { >>>>>>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>>>>>> CHECK); >>>>>>> 292 MutexLocker ml(MethodData_lock, THREAD); >>>>>>> 295 if (method->method_data() == NULL) { >>>>>>> 296 method->set_method_data(method_data); >>>>>>> >>>>>>> In general terms any stores associated with the method_data construction >>>>>>> are not guaranteed to be visible by the time set_method_data is called. >>>>>>> A second thread could then see a non-null method->method_data() but >>>>>>> access uninitialized method_data values. >>>>>>> >>>>>>> A general solution would need memory barriers before 286 and after 291 >>>>>>> to ensure correctness on all platforms. A simpler, though perhaps >>>>>>> heavier solution would be to use a MutexUnlocker around the allocation: >>>>>>> >>>>>>> MutexLocker ml(MethodData_lock, THREAD); >>>>>>> if (method->method_data() == NULL) { >>>>>>> methodDataOop method_data = NULL; >>>>>>> { // need new block for scope >>>>>>> MutexUnLocker ml(MethodData_lock, THREAD); >>>>>>> method_data = oopFactory::new_methodData(method, CHECK); >>>>>>> } >>>>>>> // someone might have beaten us to it >>>>>>> if (method->method_data() == NULL) { >>>>>>> method->set_method_data(method_data); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> A lock-less solution as Tom proposed would also require suitable >>>>>>> memory-barriers. >>>>>>> >>>>>>> David From coleen.phillimore at oracle.com Wed Oct 20 14:36:02 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Oct 2010 17:36:02 -0400 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <003449EF-3E07-46C0-A518-2A046B895BD3@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> <4CBEA8F4.6000605@oracle.com> <4CBEABFC.1020804@oracle.com> <4CBEFBB6.5060209@oracle.com> <003449EF-3E07-46C0-A518-2A046B895BD3@oracle.com> Message-ID: <4CBF60C2.2050709@oracle.com> >> Right now the extra MDO would get GC'ed because nothing references it and it's in the PermGen. But we're moving everything out of the PermGen. When it's not allocated in the PermGen, this extra MDO will get deallocated when the memory region associated with it's classloader is deallocated. I think we should revisit this thing though at that point because it would be leaked with the bootclassloader. >> > > Freeing won't be easy in the new world since we're using pointer bumping. We might actually need to use a lock for this so that we don't allocate wasted space, though maybe it's rare enough that we could ignore it. > It's so rare right now, I can't reproduce it! :-( We might want to use C Heap allocation for MDOs and use an explicit free if this becomes a problem in the new world. Coleen > tom > > >> Thanks, >> Coleen >> >>> David >>> >>> >>>> igor >>>> >>>> >>>>> Cheers, >>>>> David >>>>> >>>>> >>>>>> igor >>>>>> >>>>>> On 10/19/10 3:59 PM, David Holmes wrote: >>>>>> >>>>>>> Hi Coleen, >>>>>>> >>>>>>> coleen phillimore said the following on 10/20/10 08:11: >>>>>>> >>>>>>>> Summary: allocate methodData before taking out the MethodData_lock >>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>>>>>> >>>>>>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>>>>>>> >>>>>>> This is a variation on the unsafe double-checked-locking idiom. >>>>>>> >>>>>>> 286 if (method->method_data() == NULL) { >>>>>>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>>>>>> CHECK); >>>>>>> 292 MutexLocker ml(MethodData_lock, THREAD); >>>>>>> 295 if (method->method_data() == NULL) { >>>>>>> 296 method->set_method_data(method_data); >>>>>>> >>>>>>> In general terms any stores associated with the method_data construction >>>>>>> are not guaranteed to be visible by the time set_method_data is called. >>>>>>> A second thread could then see a non-null method->method_data() but >>>>>>> access uninitialized method_data values. >>>>>>> >>>>>>> A general solution would need memory barriers before 286 and after 291 >>>>>>> to ensure correctness on all platforms. A simpler, though perhaps >>>>>>> heavier solution would be to use a MutexUnlocker around the allocation: >>>>>>> >>>>>>> MutexLocker ml(MethodData_lock, THREAD); >>>>>>> if (method->method_data() == NULL) { >>>>>>> methodDataOop method_data = NULL; >>>>>>> { // need new block for scope >>>>>>> MutexUnLocker ml(MethodData_lock, THREAD); >>>>>>> method_data = oopFactory::new_methodData(method, CHECK); >>>>>>> } >>>>>>> // someone might have beaten us to it >>>>>>> if (method->method_data() == NULL) { >>>>>>> method->set_method_data(method_data); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> A lock-less solution as Tom proposed would also require suitable >>>>>>> memory-barriers. >>>>>>> >>>>>>> David >>>>>>> > > From coleen.phillimore at oracle.com Wed Oct 20 14:36:42 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Oct 2010 17:36:42 -0400 Subject: Request for review: 6922246: Deadlock during intensive class loading in parallel In-Reply-To: <4CBF5B2B.3090606@oracle.com> References: <4CBE1792.8060301@Sun.COM> <4CBE22E2.8090808@oracle.com> <4CBE91BF.20503@oracle.com> <4CBE9765.2040807@oracle.com> <4CBEA8F4.6000605@oracle.com> <4CBEABFC.1020804@oracle.com> <4CBEFBB6.5060209@oracle.com> <003449EF-3E07-46C0-A518-2A046B895BD3@oracle.com> <4CBF5B2B.3090606@oracle.com> Message-ID: <4CBF60EA.80201@oracle.com> Paul Hohensee wrote: > Atomic::cmpxchg() guarantees a membar, even if the actual hw cas > instruction (assuming there is one: ppc used > load-locked/store-conditional) > doesn't guarantee it. So use Atomic::cmpxchg() with confidence. :) > Great! thanks. Coleen > Paul > > On 10/20/10 4:43 PM, Tom Rodriguez wrote: >> On Oct 20, 2010, at 7:24 AM, Coleen Phillimore wrote: >> >>> Thank you for the discussion. I am reimplementing this with a CAS >>> as Tom suggested. I guess it's not such a simple fix, anyway, see >>> below: >>> >>> David Holmes wrote: >>>> Igor Veresov said the following on 10/20/10 18:31: >>>>> On 10/20/10 12:16 AM, David Holmes wrote: >>>>>> Igor Veresov said the following on 10/20/10 16:52: >>>>>>> There's no question a store-store barrier is needed after 291 for >>>>>>> non-TSO if we were to make it lock-free (with the current code >>>>>>> monitor >>>>>>> lock should contain such barrier anyway). >>>>>> There's no requirement for a storestore barrier when acquiring a >>>>>> lock. >>>>>> You will happen to get that on sparc and x86 if the lock acquisition >>>>>> involves a CAS, but that is not true on other archs. In general >>>>>> terms it >>>>>> is considered safe to move stores into a critical section at >>>>>> which time >>>>>> it can be reordered with other stores inside the critical section. >>>>> Yes, that's what I meant. Basically a lock should guarantee that >>>>> all stores before the lock precede stores in the critical section, >>>>> which is essentially a storestore barrier. >>>> But my point is that locks in general don't guarantee this. >>>> >>> Does a CAS guarantee this? If there isn't a guarantee, I will add >>> an Atomic::storestore(), plus make _method_data volatile. >> It should. >> >>>>>> Right. If it were not safe/correct for more than one thread to >>>>>> create a >>>>>> MDO, and have all but one thrown away, then we'd have a different >>>>>> problem to solve. Which reminds we, if another thread does beat >>>>>> us to >>>>>> storing the MDO then we need to delete the one we created. >>>>> Yes, perhaps we can try to deallocate. Although I suppose the race >>>>> should occur infrequently and GC will take care of the unused copy >>>>> anyway. >>>> Ah! Is this a GC'able oop we are creating? I had assumed it was a >>>> C/C++ object. >>>> >>> Right now the extra MDO would get GC'ed because nothing references >>> it and it's in the PermGen. But we're moving everything out of the >>> PermGen. When it's not allocated in the PermGen, this extra MDO will >>> get deallocated when the memory region associated with it's >>> classloader is deallocated. I think we should revisit this thing >>> though at that point because it would be leaked with the >>> bootclassloader. >> Freeing won't be easy in the new world since we're using pointer >> bumping. We might actually need to use a lock for this so that we >> don't allocate wasted space, though maybe it's rare enough that we >> could ignore it. >> >> tom >> >>> Thanks, >>> Coleen >>>> David >>>> >>>>> igor >>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> igor >>>>>>> >>>>>>> On 10/19/10 3:59 PM, David Holmes wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> coleen phillimore said the following on 10/20/10 08:11: >>>>>>>>> Summary: allocate methodData before taking out the >>>>>>>>> MethodData_lock >>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6922246/ >>>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6922246 >>>>>>>>> >>>>>>>>> Thanks to Ramki for the diagnosis and suggestion for the fix. >>>>>>>> This is a variation on the unsafe double-checked-locking idiom. >>>>>>>> >>>>>>>> 286 if (method->method_data() == NULL) { >>>>>>>> 291 methodDataOop method_data = oopFactory::new_methodData(method, >>>>>>>> CHECK); >>>>>>>> 292 MutexLocker ml(MethodData_lock, THREAD); >>>>>>>> 295 if (method->method_data() == NULL) { >>>>>>>> 296 method->set_method_data(method_data); >>>>>>>> >>>>>>>> In general terms any stores associated with the method_data >>>>>>>> construction >>>>>>>> are not guaranteed to be visible by the time set_method_data is >>>>>>>> called. >>>>>>>> A second thread could then see a non-null method->method_data() >>>>>>>> but >>>>>>>> access uninitialized method_data values. >>>>>>>> >>>>>>>> A general solution would need memory barriers before 286 and >>>>>>>> after 291 >>>>>>>> to ensure correctness on all platforms. A simpler, though perhaps >>>>>>>> heavier solution would be to use a MutexUnlocker around the >>>>>>>> allocation: >>>>>>>> >>>>>>>> MutexLocker ml(MethodData_lock, THREAD); >>>>>>>> if (method->method_data() == NULL) { >>>>>>>> methodDataOop method_data = NULL; >>>>>>>> { // need new block for scope >>>>>>>> MutexUnLocker ml(MethodData_lock, THREAD); >>>>>>>> method_data = oopFactory::new_methodData(method, CHECK); >>>>>>>> } >>>>>>>> // someone might have beaten us to it >>>>>>>> if (method->method_data() == NULL) { >>>>>>>> method->set_method_data(method_data); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> A lock-less solution as Tom proposed would also require suitable >>>>>>>> memory-barriers. >>>>>>>> >>>>>>>> David From keith.mcguigan at oracle.com Mon Oct 25 08:18:36 2010 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Mon, 25 Oct 2010 15:18:36 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6991315: RedefineClasses fails with java.lang.VerifyError Message-ID: <20101025151848.049D147401@hg.openjdk.java.net> Changeset: a4c7fe54bf3f Author: kamg Date: 2010-10-21 10:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a4c7fe54bf3f 6991315: RedefineClasses fails with java.lang.VerifyError Summary: Repair stackmap table attribute when relocating bytecode Reviewed-by: acorn, never + src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp From karen.kinnear at oracle.com Mon Oct 25 15:38:12 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 25 Oct 2010 22:38:12 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20101025223816.7B0B947416@hg.openjdk.java.net> Changeset: fa83ab460c54 Author: acorn Date: 2010-10-22 15:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fa83ab460c54 6988353: refactor contended sync subsystem Summary: reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp + src/share/vm/prims/jvmtiRawMonitor.cpp + src/share/vm/prims/jvmtiRawMonitor.hpp + src/share/vm/runtime/basicLock.cpp + src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/mutex.hpp + src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp + src/share/vm/runtime/park.cpp + src/share/vm/runtime/park.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a312a67b32ef Author: acorn Date: 2010-10-25 13:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a312a67b32ef Merge ! src/share/vm/includeDB_core From y.s.ramakrishna at oracle.com Mon Oct 25 17:49:33 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 25 Oct 2010 17:49:33 -0700 Subject: Long young generation GC? In-Reply-To: References: Message-ID: <4CC6259D.5050303@oracle.com> On 10/25/2010 5:32 PM, Hi Guava wrote: > The third young generation GC took 439.2720750 secs but the user and > real time are only 0.08 seconds. What does it mean? The machine may be using NTP, and the time may have been changed? JVM timestamps on Linux seem still to be based on TOD rather than on TSC. Someone in the runtime team (cc'd) may have more detail on why that might still be so. -- ramki > > 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 secs] > 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 sys=1.10, > real=1.25 secs] > 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 secs] > 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 sys=0.03, > real=0.29 secs] > 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 > secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 > sys=0.00, real=0.08 secs] > > Environment: > Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02 > Linux Version 2.6.18-128.1.1.el5 on amd64 > -Xms6400m > -Xmx6400m > -Xss256k > -XX:+UseConcMarkSweepGC > -XX:+PrintGCDetails > -XX:+PrintGCTimeStamps > -XX:+UseCompressedOops > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at oracle.com Mon Oct 25 17:51:57 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 25 Oct 2010 17:51:57 -0700 Subject: Long young generation GC? In-Reply-To: <4CC6259D.5050303@oracle.com> References: <4CC6259D.5050303@oracle.com> Message-ID: <4CC6262D.6050608@oracle.com> On 10/25/2010 5:49 PM, Y. Srinivas Ramakrishna wrote: > On 10/25/2010 5:32 PM, Hi Guava wrote: >> The third young generation GC took 439.2720750 secs but the user and >> real time are only 0.08 seconds. What does it mean? > > The machine may be using NTP, and the time may have been changed? Seems a rather large jump, so may not be NTP (which i am told uses adjtime() to slowly accelerate the time forward or decelerate it backward), but rather an abrupt perhaps manual change in TOD. Over to the experts.... > JVM timestamps on Linux seem still to be based on TOD rather than > on TSC. Someone in the runtime team (cc'd) may have more detail on > why that might still be so. > > -- ramki > > >> >> 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 secs] >> 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 sys=1.10, >> real=1.25 secs] >> 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 secs] >> 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 sys=0.03, >> real=0.29 secs] >> 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 >> secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 >> sys=0.00, real=0.08 secs] >> >> Environment: >> Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02 >> Linux Version 2.6.18-128.1.1.el5 on amd64 >> -Xms6400m >> -Xmx6400m >> -Xss256k >> -XX:+UseConcMarkSweepGC >> -XX:+PrintGCDetails >> -XX:+PrintGCTimeStamps >> -XX:+UseCompressedOops >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > From y.s.ramakrishna at oracle.com Tue Oct 26 09:34:40 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 26 Oct 2010 09:34:40 -0700 Subject: Long young generation GC? In-Reply-To: References: <4CC6259D.5050303@oracle.com> <4CC6262D.6050608@oracle.com> Message-ID: <4CC70320.4080207@oracle.com> On 10/26/10 07:07, Hi Guava wrote: > Here is additional information about the machine running the JVM. It > is a virtual machine running in a private cloud. Could it be something > like swapping that caused problem? Not swapping, but perhaps the management of "time" perhaps in a virtualized setting (by that i mean that there may be interactions between the host/hypervisor and the guest OS that could cause the JVM to observe time jumps of this sort)? I'd suggest gathering more data on its reproducibility (or otherwise) in both a VM and non-VM setting. Over to the time experts in the runtime team who may have encountered issues in VM settings previously. (I have heard of occasional such reports in virtual settings before but don't know if any of these were definitively chased down.) You might also want to check with the VM provider to see if they might know of such issues. -- ramki > > On Mon, Oct 25, 2010 at 8:51 PM, Y. Srinivas Ramakrishna > wrote: >> On 10/25/2010 5:49 PM, Y. Srinivas Ramakrishna wrote: >>> On 10/25/2010 5:32 PM, Hi Guava wrote: >>>> The third young generation GC took 439.2720750 secs but the user and >>>> real time are only 0.08 seconds. What does it mean? >>> The machine may be using NTP, and the time may have been changed? >> Seems a rather large jump, so may not be NTP (which i am told uses >> adjtime() to slowly accelerate the time forward or decelerate it backward), >> but rather an abrupt perhaps manual change in TOD. >> >> Over to the experts.... >> >>> JVM timestamps on Linux seem still to be based on TOD rather than >>> on TSC. Someone in the runtime team (cc'd) may have more detail on >>> why that might still be so. >>> >>> -- ramki >>> >>> >>>> 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 secs] >>>> 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 sys=1.10, >>>> real=1.25 secs] >>>> 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 secs] >>>> 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 sys=0.03, >>>> real=0.29 secs] >>>> 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 >>>> secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 >>>> sys=0.00, real=0.08 secs] >>>> >>>> Environment: >>>> Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02 >>>> Linux Version 2.6.18-128.1.1.el5 on amd64 >>>> -Xms6400m >>>> -Xmx6400m >>>> -Xss256k >>>> -XX:+UseConcMarkSweepGC >>>> -XX:+PrintGCDetails >>>> -XX:+PrintGCTimeStamps >>>> -XX:+UseCompressedOops >>>> _______________________________________________ >>>> hotspot-gc-use mailing list >>>> hotspot-gc-use at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> From higuava at gmail.com Tue Oct 26 07:07:04 2010 From: higuava at gmail.com (Hi Guava) Date: Tue, 26 Oct 2010 10:07:04 -0400 Subject: Long young generation GC? In-Reply-To: <4CC6262D.6050608@oracle.com> References: <4CC6259D.5050303@oracle.com> <4CC6262D.6050608@oracle.com> Message-ID: Here is additional information about the machine running the JVM. It is a virtual machine running in a private cloud. Could it be something like swapping that caused problem? On Mon, Oct 25, 2010 at 8:51 PM, Y. Srinivas Ramakrishna wrote: > On 10/25/2010 5:49 PM, Y. Srinivas Ramakrishna wrote: >> >> On 10/25/2010 5:32 PM, Hi Guava wrote: >>> >>> The third young generation GC took 439.2720750 secs but the user and >>> real time are only 0.08 seconds. What does it mean? >> >> The machine may be using NTP, and the time may have been changed? > > Seems a rather large jump, so may not be NTP (which i am told uses > adjtime() to slowly accelerate the time forward or decelerate it backward), > but rather an abrupt perhaps manual change in TOD. > > Over to the experts.... > >> JVM timestamps on Linux seem still to be based on TOD rather than >> on TSC. Someone in the runtime team (cc'd) may have more detail on >> why that might still be so. >> >> -- ramki >> >> >>> >>> 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 secs] >>> 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 sys=1.10, >>> real=1.25 secs] >>> 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 secs] >>> 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 sys=0.03, >>> real=0.29 secs] >>> 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 >>> secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 >>> sys=0.00, real=0.08 secs] >>> >>> Environment: >>> Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02 >>> Linux Version 2.6.18-128.1.1.el5 on amd64 >>> -Xms6400m >>> -Xmx6400m >>> -Xss256k >>> -XX:+UseConcMarkSweepGC >>> -XX:+PrintGCDetails >>> -XX:+PrintGCTimeStamps >>> -XX:+UseCompressedOops >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > > From joe.darcy at oracle.com Tue Oct 26 10:40:09 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 26 Oct 2010 10:40:09 -0700 Subject: Updated ARM Spec In-Reply-To: <4C730FB0.6030100@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> Message-ID: <4CC71279.1060102@oracle.com> David Holmes wrote: > Joe Darcy said the following on 08/24/10 05:45: >> To recap, Throwable objects have several pieces of mutable state: >> >> * the cause; this is a write-at-most-once value that can be set set >> via a constructor, like Throwable(Throwable cause) or >> Throwable(String message, Throwable cause), or set after construction >> via the Throwable.initCause method. (Setting the cause to null >> prevents future assignment.) >> >> * the stack trace; set by fillInStackTrace() or >> setStackTrace(StackTraceElement[] stackTrace) -- there doesn't seem >> to be any API prohibition against setting the stack trace multiple times > > But note that the VM implements fillInStackTrace and can ignore the > request, while setStackTrace is pure Java. > >> * suppressed exceptions : new functionality added to support >> try-with-resources statements/ARM blocks. Modified via calling >> addSuppressedException >> >> Focusing just on suppressed exceptions, to support the JVM reusing >> exception objects, the Throwable API should have some idiom to >> indicate suppressed exception information should *not* be recorded. >> Logically this amount to having the list of exceptions be a >> zero-length list which just discards adds. >> >> I'm hesitant to overload a null cause with discarding suppressed >> exceptions too. Instead, I propose the following: >> >> * a null value of the suppressedException field indicates >> addSuppressedException is a no-op. >> >> * the suppressedException field is initialized to point to a sentinel >> list in Throwable, something non-null that can be used for == >> checks. With this protocol, the "raw" Throwable objects created by >> the JVM get the addSuppressedException is a no-op behavior for free. >> >> * if the first call to addSuppressedException has this as an >> argument, the suppressedException field is null-ed; otherwise, a list >> is appended to as usual. >> >> Comments? > > It seems to me, inline with what has been written, that Throwable > should adopt the overall approach that for each of the cause, > stacktrace and suppressedExceptions fields: > > - null indicates that these fields can not be modified (and is the > default we get from the instances pre-allocated in the VM) > - the default initialization, via the constructor, is always a > non-NULL sentinel value > > This requires several changes to the existing method specifications. > The needed library changes to Throwable are being worked on under bug 6991528 "Support immutable Throwable objects" and the changes will be sent out for review to core-libs-dev once they're ready. -Joe From y.s.ramakrishna at oracle.com Tue Oct 26 10:58:44 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 26 Oct 2010 10:58:44 -0700 Subject: Long young generation GC? In-Reply-To: References: <4CC6259D.5050303@oracle.com> <4CC6262D.6050608@oracle.com> <4CC70320.4080207@oracle.com> Message-ID: <4CC716D4.2030005@oracle.com> "real" is elapsed time too, obtained from the OS via times(2). So if it's reported so small when users see much more time elapse physically, it must be the case that it's a bug in times(2) in a virtual setting. Perhaps if you can boil this down to a small and reproducible test case you can file a bug with the VM provider and with the JVM as well, the latter perhaps a shadow of the former. Over to the runtime team. -- ramki On 10/26/10 10:49, Hi Guava wrote: > I now believe that this phenomenon is caused by the virtual machine. > It has nothing to do with the garbage collector or JVM. I searched in > the old logs and found this in all 3 old logs that I have. There are > multiple virtual machines configured the same way. This problem only > shows up in one of the virtual machines. > By the way, the 639 seconds GC is not a perception problem. It is > real. The users reported stuck process and they found the CPUs of the > virtual machine was racing during that period. > Can I understand this discrepancy this way? the user, sys and real > times are measured in cpu cycles. They are short as they are supposed > to be. The 439.2720750 time is the elapsed time. Since the virtual > machine is doing something else or not functioning correctly, GC took > 439 seconds even though there was only 0.08 seconds of cpu time. > > 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 > secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: > user=0.08 sys=0.00, real=0.08 secs] > > > On Tue, Oct 26, 2010 at 12:34 PM, Y. S. Ramakrishna > wrote: >> >> On 10/26/10 07:07, Hi Guava wrote: >>> Here is additional information about the machine running the JVM. It >>> is a virtual machine running in a private cloud. Could it be something >>> like swapping that caused problem? >> Not swapping, but perhaps the management of "time" perhaps in a virtualized >> setting (by that i mean that there may be interactions between the >> host/hypervisor and the guest OS that could cause the JVM to observe >> time jumps of this sort)? I'd suggest gathering more data on its >> reproducibility (or otherwise) in both a VM and non-VM setting. >> >> Over to the time experts in the runtime team who may have encountered >> issues in VM settings previously. (I have heard of occasional such reports >> in >> virtual settings before but don't know if any of these were definitively >> chased >> down.) You might also want to check with the VM provider to see if they >> might know of such issues. >> >> -- ramki >> >> >>> On Mon, Oct 25, 2010 at 8:51 PM, Y. Srinivas Ramakrishna >>> wrote: >>>> On 10/25/2010 5:49 PM, Y. Srinivas Ramakrishna wrote: >>>>> On 10/25/2010 5:32 PM, Hi Guava wrote: >>>>>> The third young generation GC took 439.2720750 secs but the user and >>>>>> real time are only 0.08 seconds. What does it mean? >>>>> The machine may be using NTP, and the time may have been changed? >>>> Seems a rather large jump, so may not be NTP (which i am told uses >>>> adjtime() to slowly accelerate the time forward or decelerate it >>>> backward), >>>> but rather an abrupt perhaps manual change in TOD. >>>> >>>> Over to the experts.... >>>> >>>>> JVM timestamps on Linux seem still to be based on TOD rather than >>>>> on TSC. Someone in the runtime team (cc'd) may have more detail on >>>>> why that might still be so. >>>>> >>>>> -- ramki >>>>> >>>>> >>>>>> 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 >>>>>> secs] >>>>>> 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 >>>>>> sys=1.10, >>>>>> real=1.25 secs] >>>>>> 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 >>>>>> secs] >>>>>> 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 >>>>>> sys=0.03, >>>>>> real=0.29 secs] >>>>>> 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 >>>>>> secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 >>>>>> sys=0.00, real=0.08 secs] >>>>>> >>>>>> Environment: >>>>>> Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02 >>>>>> Linux Version 2.6.18-128.1.1.el5 on amd64 >>>>>> -Xms6400m >>>>>> -Xmx6400m >>>>>> -Xss256k >>>>>> -XX:+UseConcMarkSweepGC >>>>>> -XX:+PrintGCDetails >>>>>> -XX:+PrintGCTimeStamps >>>>>> -XX:+UseCompressedOops >>>>>> _______________________________________________ >>>>>> hotspot-gc-use mailing list >>>>>> hotspot-gc-use at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From higuava at gmail.com Tue Oct 26 10:49:53 2010 From: higuava at gmail.com (Hi Guava) Date: Tue, 26 Oct 2010 13:49:53 -0400 Subject: Long young generation GC? In-Reply-To: <4CC70320.4080207@oracle.com> References: <4CC6259D.5050303@oracle.com> <4CC6262D.6050608@oracle.com> <4CC70320.4080207@oracle.com> Message-ID: I now believe that this phenomenon is caused by the virtual machine. It has nothing to do with the garbage collector or JVM. I searched in the old logs and found this in all 3 old logs that I have. There are multiple virtual machines configured the same way. This problem only shows up in one of the virtual machines. By the way, the 639 seconds GC is not a perception problem. It is real. The users reported stuck process and they found the CPUs of the virtual machine was racing during that period. Can I understand this discrepancy this way? the user, sys and real times are measured in cpu cycles. They are short as they are supposed to be. The 439.2720750 time is the elapsed time. Since the virtual machine is doing something else or not functioning correctly, GC took 439 seconds even though there was only 0.08 seconds of cpu time. 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] On Tue, Oct 26, 2010 at 12:34 PM, Y. S. Ramakrishna wrote: > > > On 10/26/10 07:07, Hi Guava wrote: >> >> Here is additional information about the machine running the JVM. It >> is a virtual machine running in a private cloud. Could it be something >> like swapping that caused problem? > > Not swapping, but perhaps the management of "time" perhaps in a virtualized > setting (by that i mean that there may be interactions between the > host/hypervisor and the guest OS that could cause the JVM to observe > time jumps of this sort)? I'd suggest gathering more data on its > reproducibility (or otherwise) in both a VM and non-VM setting. > > Over to the time experts in the runtime team who may have encountered > issues in VM settings previously. (I have heard of occasional such reports > in > virtual settings before but don't know if any of these were definitively > chased > down.) You might also want to check with the VM provider to see if they > might know of such issues. > > -- ramki > > >> >> On Mon, Oct 25, 2010 at 8:51 PM, Y. Srinivas Ramakrishna >> wrote: >>> >>> On 10/25/2010 5:49 PM, Y. Srinivas Ramakrishna wrote: >>>> >>>> On 10/25/2010 5:32 PM, Hi Guava wrote: >>>>> >>>>> The third young generation GC took 439.2720750 secs but the user and >>>>> real time are only 0.08 seconds. What does it mean? >>>> >>>> The machine may be using NTP, and the time may have been changed? >>> >>> Seems a rather large jump, so may not be NTP (which i am told uses >>> adjtime() to slowly accelerate the time forward or decelerate it >>> backward), >>> but rather an abrupt perhaps manual change in TOD. >>> >>> Over to the experts.... >>> >>>> JVM timestamps on Linux seem still to be based on TOD rather than >>>> on TSC. Someone in the runtime team (cc'd) may have more detail on >>>> why that might still be so. >>>> >>>> -- ramki >>>> >>>> >>>>> 72667.213: [GC 72667.213: [ParNew: 38336K->4224K(38336K), 1.2473840 >>>>> secs] >>>>> 3443948K->3420569K(6549376K), 1.2474290 secs] [Times: user=0.64 >>>>> sys=1.10, >>>>> real=1.25 secs] >>>>> 72680.531: [GC 72680.532: [ParNew: 38336K->4221K(38336K), 0.2916570 >>>>> secs] >>>>> 3008948K->2979033K(6549376K), 0.2916710 secs] [Times: user=0.26 >>>>> sys=0.03, >>>>> real=0.29 secs] >>>>> 72681.425: [GC 72681.426: [ParNew: 38325K->4224K(38336K), 439.2720750 >>>>> secs] 3013053K->2979055K(6549376K), 439.2720750 secs] [Times: user=0.08 >>>>> sys=0.00, real=0.08 secs] >>>>> >>>>> Environment: >>>>> Java HotSpot(TM) 64-Bit Server VM Version 1.6.0_20-b02 >>>>> Linux Version 2.6.18-128.1.1.el5 on amd64 >>>>> -Xms6400m >>>>> -Xmx6400m >>>>> -Xss256k >>>>> -XX:+UseConcMarkSweepGC >>>>> -XX:+PrintGCDetails >>>>> -XX:+PrintGCTimeStamps >>>>> -XX:+UseCompressedOops >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>> > From karen.kinnear at oracle.com Tue Oct 26 15:44:29 2010 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 26 Oct 2010 22:44:29 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 8 new changesets Message-ID: <20101026224443.5A2AB47458@hg.openjdk.java.net> Changeset: 4e22405d98d6 Author: iveresov Date: 2010-10-19 11:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/4e22405d98d6 6989669: Coops: -Xshare:dump causes crash Summary: Temporarily fix to disable compressed oops with CDS Reviewed-by: dholmes, twisti, kvn, never ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 68d6141ea19d Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/68d6141ea19d Added tag jdk7-b113 for changeset beef35b96b81 ! .hgtags Changeset: 52f19c724d96 Author: trims Date: 2010-10-14 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/52f19c724d96 Merge ! .hgtags Changeset: 570870354f86 Author: trims Date: 2010-10-14 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/570870354f86 6992267: Bump the HS20 build number to 02 Summary: Update the HS20 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 477faa484f91 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/477faa484f91 Added tag jdk7-b114 for changeset 68d6141ea19d ! .hgtags Changeset: bdbc48857210 Author: trims Date: 2010-10-20 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bdbc48857210 Merge ! .hgtags Changeset: 9eaf8ba53f3d Author: trims Date: 2010-10-20 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/9eaf8ba53f3d Merge Changeset: 60ce9dade348 Author: acorn Date: 2010-10-26 14:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/60ce9dade348 Merge From keith.mcguigan at oracle.com Tue Oct 26 19:14:36 2010 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 27 Oct 2010 02:14:36 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 2 new changesets Message-ID: <20101027021440.98B2D47463@hg.openjdk.java.net> Changeset: 6412b3805cd6 Author: kamg Date: 2010-10-26 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/6412b3805cd6 6891959: HotSpot should not throw ClassFormatError if a class has a field with '>' and/or '<' in its name Summary: Class file parser needs to look for and disallow '[' in names. Reviewed-by: coleenp, never ! src/share/vm/classfile/classFileParser.cpp Changeset: ee0d26abaad3 Author: kamg Date: 2010-10-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ee0d26abaad3 Merge From keith.mcguigan at oracle.com Wed Oct 27 14:21:54 2010 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 27 Oct 2010 21:21:54 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 6865028: Illegal instructions passing verification prior to 'invokespecial Object.' Message-ID: <20101027212156.4D2D54748B@hg.openjdk.java.net> Changeset: 1070423b51f3 Author: kamg Date: 2010-10-27 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/1070423b51f3 6865028: Illegal instructions passing verification prior to 'invokespecial Object.' Summary: Update verifier to conform to spec re: reference vs. 'Object' types Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp From wagaarachchi at gmail.com Thu Oct 28 11:43:47 2010 From: wagaarachchi at gmail.com (Jayanga Wagaarachchi) Date: Fri, 29 Oct 2010 00:13:47 +0530 Subject: Help to provide byte code level parallelism Message-ID: Hi, I am an undergraduate at University of Moratuwa, SriLanka. We are doing a research project on providing CPU/GPU hybrid parallelism at run time by modifying byte code. We are still looking for a way to plug the system which we are going to develop to the java runtime environment. Can this be done through hotspot?. If so can you provide few guide lines about it. It will be a great help if you could respond to this. Thank you. Jayanga. -- Jayanga Wagaarachchi Computer Science and Engineering University of Moratuwa. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20101029/6d43aee1/attachment.html