Merging BSDPort into HotSpot mainline
Christian Thalinger
christian.thalinger at oracle.com
Wed Sep 14 06:28:59 PDT 2011
On Sep 14, 2011, at 12:32 AM, 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.
I did builds on Lion and everything looks good.
>
> http://cr.openjdk.java.net/~never/7089790_full
That's too huge to review. The only thing I needed on my Mac OS X was this change:
75 # amd64
76 ifneq (,$(findstring $(ARCH), amd64 x86_64))
taken from:
http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/file/a00aa3dd9244/make/bsd/makefiles/defs.make
> http://cr.openjdk.java.net/~never/7089790_headers_only
src/share/vm/runtime/os.hpp:
+ #ifdef TARGET_OS_FAMILY_bsd
+ # include "jvm_bsd.h"
+ #endif
This is included twice.
>
> http://cr.openjdk.java.net/~never/7089790_shared
Looks good.
> http://cr.openjdk.java.net/~never/7089790_bsd_only
This one is empty(?).
> http://cr.openjdk.java.net/~never/7089790_bsd_vs_linux
src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp:
! // HACK: si_code does not work on linux 2.2.12-20!!!
! // HACK: si_code does not work on bsd 2.2.12-20!!!
I doubt there is a bsd 2.2.12 kernel :-) Seriously, I suppose si_code does work on BSD?
src/os_cpu/bsd_x86/vm/bsd_x86_32.s:
src/os_cpu/bsd_x86/vm/bsd_x86_64.s:
+ #ifdef __APPLE__
+ .align 4
+ #else
.align 16
+ #endif
Maybe we should use a ALIGN macro instead.
src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp
+ #ifndef _ALLBSD_SOURCE
#include <byteswap.h>
+ #endif
+ #ifdef __APPLE__
+ #include <libkern/OSByteOrder.h>
+ #endif
+
+ #if defined(AMD64)
+ # if defined(__APPLE__)
+ # define bswap_16(x) OSSwapInt16(x)
+ # define bswap_32(x) OSSwapInt32(x)
+ # define bswap_64(x) OSSwapInt64(x)
+ # elif defined(__OpenBSD__)
+ # define bswap_16(x) swap16(x)
+ # define bswap_32(x) swap32(x)
+ # define bswap_64(x) swap64(x)
+ # elif defined(__NetBSD__)
+ # define bswap_16(x) bswap16(x)
+ # define bswap_32(x) bswap32(x)
+ # define bswap_64(x) bswap64(x)
+ # else
+ # define bswap_16(x) __bswap16(x)
+ # define bswap_32(x) __bswap32(x)
+ # define bswap_64(x) __bswap64(x)
+ # endif
+ #endif
src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp:
- #include <byteswap.h>
+ #ifdef __APPLE__
+ #include <libkern/OSByteOrder.h>
+ #define bswap16(x) OSSwapInt16(x)
+ #define bswap32(x) OSSwapInt32(x)
+ #define bswap64(x) OSSwapInt64(x)
+ #else
+ # include <sys/endian.h>
+ #endif
Why is byteswap.h removed from bytes_bsd_zero but sys/endian.h is used for !APPLE? bytes_bsd_x86 does something different.
src/os/bsd/vm/os_bsd.cpp:
! julong os::Bsd::available_memory() {
+ #ifdef _ALLBSD_SOURCE
+ // XXXBSD: this is just a stopgap implementation
+ return physical_memory() >> 2;
+ #else
Is this going to be fixed anytime soon?
+ // This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes
+ // on caught fatal signals.
Should we check the Mac OS X version here and not do the workaround if >= 10.5?
Generally there are a couple of linux -> bsd renames like:
! // thread has a unique thread_id (LinuxThreads or NPTL). It can be used
! // thread has a unique thread_id (BsdThreads or NPTL). It can be used
which are wrong but I think it doesn't matter. But someone will have to deal with that when merging linux/bsd/solaris to posix.
-- Christian
>
> 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
>
More information about the hotspot-dev
mailing list