Merging BSDPort into HotSpot mainline

[Kurt Miller]

Hi Tom,

Yes, I received two copies in my inbox. One from you directly and
another from the list server. It appears to be working ok from my
perspective.

BTW, thanks for preparing this! I will give them a try hopefully
tomorrow and let you know how it goes.

Regards,
-Kurt

On 09/13/11 22:39, Tom Rodriguez wrote:
> Did anyone else receive this email?  I never received a copy but it shows until the hotspot-dev archives and I suspect that means something went wrong with the oracle mail servers again.
> 
> tom
> 
> On Sep 13, 2011, at 3:32 PM, Tom Rodriguez wrote:
> 
>> I've finally prepared a set of changes against the latest hotspot-comp with the bsd-port changes.  They compile on all our supported platforms with the jdk7 and jdk6 tools and I also built on Snow Leopard and incorporated a few extra changes there to make it all compile.  I've prepared several webrevs to ease reviewing.
>>
>> http://cr.openjdk.java.net/~never/7089790_full
>> http://cr.openjdk.java.net/~never/7089790_headers_only
>> http://cr.openjdk.java.net/~never/7089790_shared
>> http://cr.openjdk.java.net/~never/7089790_bsd_only
>> http://cr.openjdk.java.net/~never/7089790_bsd_vs_linux
>>
>> full is a regular webrev of the full set of changes.  header_only is just include changes in shared code, shared are the actual changes to shared code, bsd_only are the src/os/bsd and src/os_cpu/bsd_* changes and bsd_vs_linux is webrev comparing the bsd sources against the current linux sources.  The shared changed are about 460 lines and the bsd_vs_linux changes are about 2600 so it's really not that large.  The duplication of the linux code in bsd makes it seem quite large and hopefully we can address that once the Mac port gets into full swing.
>>
>> Relative to the original webrev, these are the changes I made:
>>
>> Made the needed changes on solaris and windows to use the PRI* macros for globalDefinitions.  I confirmed that the current definitions are the same as the old definitions so nothing should change printing-wise with existing builds.
>>
>> Fixed a few more printing mismatches.
>>
>> Eliminated the inclusion on elf.h and modified the decoder support on apple to indicate that it doesn't currently support decoding within the JVM.
>>
>> I'm assuming that we'll leave in the UseMembar changes and the hack for $ORIGIN until those issues are fully resolved.
>>
>> Who all should I mark as the contributors for these changes?  Roger, Greg and Kurt?  If you could take a copy of the bits and confirm that I haven't introduced any issues on BSD that would be greatly appreciated.  Thanks for your patience.
>>
>> tom
>>
>> On Aug 31, 2011, at 11:23 AM, Kurt Miller wrote:
>>
>>> On Wednesday 31 August 2011 11:30:45 am Greg Lewis wrote:
>>>> On Wed, Aug 03, 2011 at 11:24:22AM -0400, Kurt Miller wrote:
>>>>> On Wednesday 03 August 2011 01:41:01 am Greg Lewis wrote:
>>>>>> On Tue, Aug 02, 2011 at 05:18:17PM -0400, Kurt Miller wrote:
>>>>>>> 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.
>>>>>>
>>>>>> Do we have a test case that shows this up?  I have a FreeBSD SMP system I
>>>>>> can run it on.
>>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Refreshing my memory by reading the freebsd-java list for this time-frame
>>>>> and I see that it was rather easy to reproduce on SMP hardware. Reports
>>>>> included using tomcat, netbeans and in one case 'java -version'. Here's the
>>>>> search I used:
>>>>>
>>>>> http://markmail.org/search/list:org%2Efreebsd%2Efreebsd-java+sigbus+diablo+1%2E5%2E0_06
>>>>
>>>> I've tried setting UseMemBar to false and ran the resulting JDK on a few
>>>> different things, including code designed to produce I/O and CPU load
>>>> across a thread pool and I haven't been able to produce any problems.
>>>>
>>>> I didn't try with Tomcat and I tried Eclipse rather than Netbeans, but it
>>>> does look like we can get off of the UseMemBar setting.
>>>
>>> That's great. OpenBSD will work with it set to false too. Perhaps we should get
>>> some testing on Mac OS/X MP to confirm there's no problem there too.
>>>
>>> Thanks,
>>> -Kurt
>>
>