Merging BSDPort into HotSpot mainline

[David Holmes]

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".

>> src/share/vm/interpreter/bytecodeTracer.cpp:
>>
>> Should this just be converted to INTPTR_FORMAT and intptr_t?
> 
> That would work ok on OpenBSD, FreeBSD and OS/X where pthread_t is defined as a pointer. 

We really should not make assumptions about what the underlying type of 
thread_t and pthread_t are :(


Aside: changes of this form

@@ -1110,7 +1113,7 @@
      }
      nmethod* nm = method->code();
      if (WizardMode && nm != NULL) {
-      sprintf(buf + (int)strlen(buf), "(nmethod " PTR_FORMAT ")", 
(intptr_t)nm);
+      sprintf(buf + (int)strlen(buf), "(nmethod " INTPTR_FORMAT ")", 
(intptr_t)nm);
      }
    }

are actually changing the wrong thing. The lack of properly defined 
portable format-specifiers for pointer types means that our current set 
of macros are always being subject to various proposals to "fix" them. 
What we are actually printing is a pointer and PTR_FORMAT is logically 
the right thing to use, but the actual definition (as an int type) 
causes compiler warnings which lead to the cast to intptr_t. Which in 
turn leads to the suggestion that the format specifier should actually 
be INTPTR_FORMAT. See CR 6990479 - PTR_FORMAT needs to be a pointer format.

Cheers,
David Holmes