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 [email protected] and [email protected] 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
