From Stephen.Bohne at Sun.COM Tue Mar 4 08:07:51 2008 From: Stephen.Bohne at Sun.COM (Steve Bohne) Date: Tue, 04 Mar 2008 11:07:51 -0500 Subject: Review request (6204603 new Solaris mmap semantics for class data archive file) Message-ID: <47CD73D7.6030701@sun.com> Thanks for any reviews. Fixed 6204603: Modify hotspot to use new Solaris mmap semantics for class data archive file http://web-east.east/~sbohne/webrev/6204603 Modify Solaris os::attempt_reserve_memory_at() to pass an address hint to mmap when reserving memory for the shared archive. Previously we used successive anonymous mmap calls to "zero in" on the correct region. Since snv_84 (see 5003415) Solaris will attempt to honor the address hint. If the new call fails, we simply fall back to the old method. Reviewed by: Fix verified (y/n): y Verification testing: java -client -Xshare:on -XX:+PrintMiscellaneous -XX:+Verbose -version (fastdebug, Solaris SPARC + x86) Other testing: NSK vm.quick -client Solaris SPARC + x86 JPRT Thanks, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 6204603.diff.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20080304/c89979e7/attachment.txt From Stephen.Bohne at Sun.COM Mon Mar 10 07:41:52 2008 From: Stephen.Bohne at Sun.COM (Steve Bohne) Date: Mon, 10 Mar 2008 10:41:52 -0400 Subject: Resend: Review request (6204603 new Solaris mmap semantics for class data archive file) Message-ID: <47D548B0.6080701@sun.com> I need one more review for this please. Thanks, Steve -------- Original Message -------- Subject: Review request (6204603 new Solaris mmap semantics for class data archive file) Date: Tue, 04 Mar 2008 11:07:51 -0500 From: Steve Bohne To: hotspot-runtime-dev at openjdk.java.net Thanks for any reviews. Fixed 6204603: Modify hotspot to use new Solaris mmap semantics for class data archive file http://web-east.east/~sbohne/webrev/6204603 Modify Solaris os::attempt_reserve_memory_at() to pass an address hint to mmap when reserving memory for the shared archive. Previously we used successive anonymous mmap calls to "zero in" on the correct region. Since snv_84 (see 5003415) Solaris will attempt to honor the address hint. If the new call fails, we simply fall back to the old method. Reviewed by: Fix verified (y/n): y Verification testing: java -client -Xshare:on -XX:+PrintMiscellaneous -XX:+Verbose -version (fastdebug, Solaris SPARC + x86) Other testing: NSK vm.quick -client Solaris SPARC + x86 JPRT Thanks, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 6204603.diff.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20080310/0ed7a72c/attachment.txt From Stephen.Bohne at Sun.COM Mon Mar 10 08:26:23 2008 From: Stephen.Bohne at Sun.COM (Steve Bohne) Date: Mon, 10 Mar 2008 11:26:23 -0400 Subject: Resend: Review request (6204603 new Solaris mmap semantics for class data archive file) In-Reply-To: <47D548B0.6080701@sun.com> References: <47D548B0.6080701@sun.com> Message-ID: <47D5531F.8040905@sun.com> All set now, thanks! Steve Steve Bohne wrote: > I need one more review for this please. > > Thanks, > Steve > > -------- Original Message -------- > Subject: Review request (6204603 new Solaris mmap semantics for class > data archive file) > Date: Tue, 04 Mar 2008 11:07:51 -0500 > From: Steve Bohne > To: hotspot-runtime-dev at openjdk.java.net > > Thanks for any reviews. > > Fixed 6204603: Modify hotspot to use new Solaris mmap semantics for > class data archive file From Thomas.Rodriguez at Sun.COM Tue Mar 25 10:34:27 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 25 Mar 2008 10:34:27 -0700 Subject: review (XS) for 6679708 Message-ID: <47E937A3.9050903@sun.com> 6679708: No_Safepoint_Verifier and BacktraceBuilder have uninitialized fields Summary: fix or remove uninitialized fields Reviewed-by: While doing some testing with valgrind I tripped across a couple uninitialized fields. BacktraceBuilder has an extra field which is uninitialized and is benignly useless. No_Safepoint_Verifier doesn't properly initialize the _activated field. Normally it should be true and garbage on the stack is more likely to be non-zero so mostly I think this doesn't matter either. The fix is simply remove the extra field from BacktraceBuilder and initialize the field in No_Safepoint_Verifier. http://webrev.invokedynamic.info/never/6679708 From Keith.McGuigan at Sun.COM Mon Mar 31 12:56:56 2008 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Mon, 31 Mar 2008 15:56:56 -0400 Subject: question about linux stack checks Message-ID: <47F14208.5030302@sun.com> Hello, Someone posted this to the message board, can any suggest any help for him? > > > or > > > For your convenience, the new message is included below: > -------------------------------------------------------------- > Hi. > I see the code in os::Linux::capture_initial_stack() checks the __libc_stack_end symbol to try to discern where the initial stack section is for the VM. I have a case where an executable (over which I have no control) loads a shared library I've written, but does so in a "stack sandbox". My shared library creates a VM through a JNI call. The VM gets the stack section for the main program, but is running in this sandbox and a crash occurs pretty quickly. Specifically in the guarantee(get_thread() == thread) assertion. > > Are there any mechanisms for helping in this situation? From my reading of the code, my only option is to recompile the VM with a modified capture_initial_stack(), which is a little daunting (the recompile process -- not the code modification). > > Is this even the right forum to be asking this question? > > Thanks. > nall. > -------------------------------------------------------------- > > To respond to this post, please click the following link: >