Merging BSDPort into HotSpot mainline
glewis at eyesbeyond.com
Tue Aug 2 22:41:01 PDT 2011
On Tue, Aug 02, 2011 at 05:18:17PM -0400, Kurt Miller wrote:
> I am a co-founding member together with Greg Lewis of the bsd-port project. I have been involved with BSD support for the JDKs for about eight years starting with 1.3 support on OpenBSD. At times I have also been heavily involved with FreeBSD support and contracted with the FreeBSD foundation multiple times to do the enginering work on certifying 1.5 and 1.6 on FreeBSD.
> Thank you for the review. I will try to address some of your questions inline below.
> Greg, I've cc'ed you for help with answering some questions on changes I was not familiar with.
Thanks Kurt. Comments inline where appropriate, I've trimmed some of the
> 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.
> 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.
> > globalDefinitions.hpp:
> > INTPTR_FORMAT has been changed to a decimal format when it's supposed to be hexadecimal. I think it should be PRIxPTR instead.
> > These changes might cause compilation problems on earlier releases since for instance Solaris 8 doesn't have PRI*PTR. We might want to add something like:
> > #ifndef PRIxPTR
> > #ifdef _LP64
> > #define PRIxPTR PRIx64
> > #else
> > #define PRIxPTR PRIx32
> > #endif
> Greg added these changes. Greg, can you comment on them?
Previously there were a real mish mash of #defines on how to detect
which format to use for printing what, which seemed to be particularly
troublesome for MacOS X. I brought in the PRI* changes to avoid that,
since that is exactly what they are meant to do in a clean way.
I'm ok with the above since it uses the define if it exists. IIRC this
was in the C99 standard and I see Solaris 8 was released in 2000. So
I can understand it not having it yet. I also see Solaris 8 is due to
be end of lifed in March 2012. One question that raises for me is whether
Java 8 will be out before then or whether this is a moot question?
> > I see a full copy of elf.h in there as well which I doubt we can accept. It seems to be apple specfic but doesn't mac use MachO?
> This was brought in for Apple support. We need an Apple developer to remove it and find the places where the build is missing defines. I don't have an x86 OS/X box at the moment to do this work.
We likely have a similar problem in the agent code then where IIRC we pull
in a file from glibc verbatim.
> > test/Makefile:
> > What's the point of the JTREG_TESTDIRS change?
> Not sure. Greg can you comment on this one?
To be honest, I don't recall why we did this one. Looks like it's been
that way from the start, so I can only suggest that I changed it that way
to run the tests in the compiler directory there and didn't change it
back before committing. It can likely be reverted.
> Thank you for the review.
Greg Lewis Email : glewis at eyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : glewis at FreeBSD.org
More information about the hotspot-dev