Merging BSDPort into HotSpot mainline

Kurt Miller kurt at intricatesoftware.com
Wed Aug 3 08:57:52 PDT 2011


On Wednesday 03 August 2011 02:26:52 am David Holmes wrote:
> Kurt Miller said the following on 08/03/11 07:18:
> > On Tuesday 02 August 2011 08:47:39 am Tom Rodriguez wrote:
> >> What are the UseMembar changes about?  They are fine, I'm curious why they are needed.  I believe !UseMembar is more efficient.
> > 
> > In the 1.5 update time-frame Sun was working on changing UseMembar from default true to false. When I intergrated this change into FreeBSD's port we started hitting intermittant segfaults that I debugged and traced back to the UseMembar setting change. Since releasing stable certified binaries quickly was one of the goals, I reverted the UseMembar default back to true instead of taking time to find the root cause. More details can be found in the freebsd-port thread below.
> > 
> > http://markmail.org/message/rigdtb5heiliutec
> > 
> > IIRC, when I worked on porting BSD hotspot support to 1.6 I tried setting UseMembar default to off/false and it still caused intermittant segfaults. Although, I don't recall if I checked this again with OpenJDK7 on FreeBSD SMP systems.
> 
> This likely indicates that BSD page protection operations are not 
> providing the memory serialization affects that hotspot relies upon to 
> perform a "pseudo remote membar".

Thanks for the pointer. I think I see what your getting at; the calls
to os::protect_memory() in ./share/vm/runtime/os.cpp
os::serialize_thread_states()?

What exactly is the behavior that hotspot is relying on? Can you be more
specific about what memory serialization affects that mprotect(2) should
be doing? It is more elaborate than adding OrderAccess::fence(); to
bsd_mprotect()?

Thanks,
-Kurt


More information about the hotspot-dev mailing list