Merging BSDPort into HotSpot mainline

[Tom Rodriguez]

That's fine with me.

tom

On Sep 14, 2011, at 12:04 PM, Vladimir Kozlov wrote:

> I think we should remove sparc related changes since they are not complete and useless.
> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> On Sep 14, 2011, at 11:05 AM, Vladimir Kozlov wrote:
>>> Tom Rodriguez wrote:
>>>> On Sep 14, 2011, at 10:47 AM, Vladimir Kozlov wrote:
>>>>> I looked only on changes in our current sources.
>>>>> 
>>>>> Why change globals_sparc.hpp and not other files (as on ther platforms)?
>>>> I'm not sure that you mean.  globals_x86.hpp and globals_zero.hpp have the same change.
>>> You changed globals_sparc.hpp but not, for example, copy_sparc.hpp as on other platforms. I don't understand why we even need change anything for sparc there are no bsd code (no new files) for sparc.
>> Oh, you mean the changes aren't complete for sparc.  I thought you were complaining about the actual contents of globals_sparc.hpp.  There are BSD ports to most architectures, including sparc, so I suspect the changes were just forward thinking on the part of whoever originally did them.  We can either leave them out or extend them.  I'm fine either way.
>> tom
>>> Vladimir
>>> 
>>>>> java_md.c typo? I think it sould be __linux__:
>>>>> 
>>>>> ! #ifdef __linux
>>>>> ! #if defined(__linux)
>>>> Yes that looks like a preexisting bug.  I'll fix it.
>>>>> Remove last change in javaClasses.cpp, it is fixed.
>>>> Yes I'll remove that.
>>>>> In typeArrayOop.hpp only orderAccess_bsd_x86.inline.hpp and orderAccess_bsd_zero.inline.hpp are exit. Otherwise include other platforms also into bytecodeInterpreter.cpp, javaFrameAnchor.hpp, taskqueue.hpp and also in places where *_bsd_x86.hpp and *_bsd_zero.hpp are included.
>>>> Some files have includes for all and other don't.  I'll update it so all have the same set.  This whole thing has convinced me that we should be using dispatch files.  Some of the include lists are getting as long as my arm.
>>>>> Christian already pointed double inclusion jvm_bsd.h in os.hpp.
>>>> Yes.
>>>> Thanks.
>>>> tom
>>>>> Vladimir
>>>>> 
>>>>> 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