Merging BSDPort into HotSpot mainline
Christian Thalinger
christian.thalinger at oracle.com
Wed Sep 14 13:38:24 PDT 2011
On Sep 14, 2011, at 10:21 PM, Tom Rodriguez wrote:
>
> On Sep 14, 2011, at 6:28 AM, Christian Thalinger wrote:
>
>>
>> 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.
>
> Thanks.
>
>>
>>>
>>> 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
>
> Added.
>
>>
>>> 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.
>
> Fixed.
>
>>
>>>
>>> http://cr.openjdk.java.net/~never/7089790_shared
>>
>> Looks good.
>>
>>> http://cr.openjdk.java.net/~never/7089790_bsd_only
>>
>> This one is empty(?).
>
> Pilot error. It's there now.
>
>>
>>> 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 don't think I want to fix things like that. They just make the code diverge.
>
>>
>> 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.
>
> Maybe. I'm not sure I even understand the purpose of the change. It seems pretty spurious.
>
>>
>> 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.
>
> Someone else will have to answer that question.
Sure. Actually all the detailed questions were heading to the people who wrote that code. I did not expect an answer from you.
-- Christian
>
>>
>> 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?
>
> I would prefer if these kinds of things were ironed out in a later set of changes. Maybe that's something we should file a bug for, though I'm not quite sure what to use.
>
>>
>> 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.
>
> Yup.
>
> Thanks!
>
> tom
>
>>
>> -- 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