Re: Bug#567992: OpenJDK7 on Debian GNU/kFreeBSD
On Tue, Jun 28, 2011 at 08:52:39PM +0200, Damien Raude-Morvan wrote:
> Hi Andrew,
>
> Thanks for your feedback.
>
> Le mardi 28 juin 2011 02:11:12, Andrew John Hughes a écrit :
> > On Thu, Jun 23, 2011 at 11:27:44PM +0200, Damien Raude-Morvan wrote:
> > > Hi,
> > >
> > > I'm currently trying to port OpenJDK7 (ie. icedtea)
> >
> > These aren't the same thing. IcedTea wraps and expands OpenJDK7.
>
> Yes, I know that's not the same thing, sorry for abusing of "id est"
> abbreviation. BTW, since I've CC people not used to "openjdk" ecosystem, I
> prefer to talk about openjdk than icedtea, is this a problem ?
>
It depends where the problems are really. Referring to patches in IcedTea
as OpenJDK patches, for example, would be very confusing and unhelpful.
OpenJDK is a component of IcedTea. Where there are problems with code in the
OpenJDK tree, then of course refer to it as OpenJDK. But issues with configure
and IcedTea patches should refer to IcedTea for clarity.
> > > My current WiP patch [2] consist mostly in :
> > > - Alter build system to consider GNU/kFreeBSD like mostly linux (ie. add
> > > many ifdef __GLIBC__)
> > >
> > > - Steal BSD network stack impl for bsd-port hg repository
> > > - Use sysctl call instead of sysinfo()
> > > - Disable build of alsa and sctp
> >
> > I'd be very surprised if you don't need more of the bsd work than just the
> > network stack. What exactly have you ported across?
>
> Right now, main backports from bsd-port branch are :
> - jdk/src/solaris/native/java/net/NetworkInterface.c (small changes in structs
> from kernel)
> - jdk/src/solaris/native/sun/nio/ch/FileChannelImpl.c (sendfile from kfreebsd)
> - hotspot/src/os/linux/vm/attachListener_linux.cpp (LOCAL_PEERCRED instead of
> SO_PEERCRED)
>
As we're talking about 7, there is a separate forest for IcedTea which extends
the main (http://hg.openjdk.java.net/jdk7/jdk7) one maintained by Oracle with
extra patches. Through this, we can add stuff we need more easily.
I don't see any reason we couldn't review your additions and add them to the IcedTea
OpenJDK forest as long as they don't break standard GNU/Linux builds.
> > > I'm able to compile a stage1 jdk (openjdk-boot) but first invocation of
> > > this
> >
> > > jdk (with ZeroVM of course) just fail badly :
> > Why ZeroVM? You mention above that the port is to x86 and x86_64, both of
> > which have full HotSpot ports with a JIT.
>
> Because I thought (naively ?) that since Zero doesn't use any
> assembly/linux/gcc specific hacks it should be easier to port to GNU/kFreeBSD
> as a first step.
>
> > > I've attached hs_err_pid96754.log and put a GDB output online [3]
> > >
> > > => Did someone have a clue about this issue ? Or maybe a process to track
> > > down this segv signal ?
> > >
> > > PS: Please keep debian-bsd@l.d.o and 567992@b.d.o in CC.
> >
> > No but given OpenJDK7 doesn't support *BSD, I'm not too surprised this
> > doesn't work, especially when you're also throwing zero into the mix. Why
> > not just build with the bsd-port? There's an option to do that, though
> > it's not really maintained as I don't know of anyone running IcedTea on
> > *BSD.
>
> Could you explain a little bit more why do you think zerovm can add
> complexity/errors to my porting work ? You think that it would be simplier to
> work on porting to Hotspot ?
>
> Right now, building bsd-port give a lot more errors since :
> - it expect a *BSD userland (whereas GNU/kFreeBSD has **GNU tools**)
> - it expect a *BSD libc (various diff from **GNU glibc**)
> - large part of source code is a copy/paste from linux directories (lots of
> duplicated code) so patches from icedtea are not applied...
>
> But maybe you're right, I'll try the other way around : I'll try to adapt bsd-
> port to GNU/kFreeBSD.
>
Sorry, for some reason I had it in my head that you were doing a traditional BSD port,
even though I know what GNU/kFreeBSD is... That's what I get for responding as I'm
about to leave for the evening ;-)
I still think Zero is not the best route though for x86 and x86_64, because, if you're
going to put the effort in to getting something working, it would better for it to be
the heavily-maintained and highly-performant JIT ports than Zero which gets only sporadic
maintenance and is about 30x slower than the JIT version. So even if it is slightly
easier to get working, you'll probably want to move to the JIT version anyway for
any production use.
As GNU/kFreeBSD is the same as GNU/Linux outside the kernel, I think cherry-picking from
the BSD tree, as you have been, may be the right approach. Depending on how much of 'linux'
in the HotSpot tree is the kernel and how much is GNU, we may want to either reuse the
linux directories or create new ones. It may be just a case of conditional application
of some of the linux stuff.
Is there a recommended way of getting access to a GNU/kFreeBSD box e.g. an SSH login or a KVM
image?
I do wonder if building OpenJDK on its own might be easier to begin with, so you don't have
the additional overhead of configure and passing things through to the underlying OpenJDK
make invocation.
> Cheers,
> --
> Damien
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Reply to: