Date: Fri, 30 Mar 2007 21:30:55 -0400 (EDT) From: "David E. Cross" <crossd@cs.rpi.edu> To: "Arne H. Juul" <arnej@pvv.ntnu.no> Cc: java@freebsd.org Subject: Re: i386 jvm on an amd64... Message-ID: <20070330212202.C74265@monica.cs.rpi.edu> In-Reply-To: <Pine.LNX.4.62.0703302338210.29831@decibel.pvv.ntnu.no> References: <20070330112806.S74265@monica.cs.rpi.edu> <Pine.LNX.4.62.0703302338210.29831@decibel.pvv.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Mar 2007, Arne H. Juul wrote: > On Fri, 30 Mar 2007, David E. Cross wrote: >> (this is with ports built jdk1.5.0-p4) > > and FreeBSD 6.x, I'm guessing? > >> I am trying to run an i386 jvm on an amd64 architecture (and installed as >> such machine). I get 2 classes of problems, the first is where it is >> unable (for an unknown reason) to find the libjvm.so file. > > this I think is because when running a 32-bit binary on a 64-bit machine, > it will use /libexec/ld-elf32.so.1 as the runtime linker, and that will > use LD_32_LIBRARY_PATH instead of the normal LD_LIBRARY_PATH that the > java main program. So when java figures out where the libraries are, > it sets LD_LIBRARY_PATH in the environment and exec(2)'s itself, but > that doesn't actually work. I don't know of any good solution to this, > only a couple of workarounds; doing ldconfig -32 -m is probably the > easiest for now. That makes a certain ammount of sense. But it seems completely unnecissary. A process controls its own environment.. and by environment, I don't mean *env, there are other ways to do this, through the dynamic linker calls for example. Also, given the error message I get; a "custom" one from java, its the result of a dlopen() and error checking, not "normal" ld.so demand linking, any of these should be trivially patch-able to get the right thing done.. (and yes, I do intend to put my patches where my mouth is, but the codebase is a bit... intense, for someone who has not delved into it before, so if someone wants to point me at a given file, or set of files... I can take a whack :) > >> I have fixed this via an ldconfig -32 -m .... and the next is libverify.so >> which I also address via a ldconfig -32 -m.. at that point however the java >> process simply segfaults. > > I actually tried this very recently and found that the system calls > that the pthread library use on FreeBSD 6 aren't properly translated > between a 64-bit kernel and 32-bit userland, so it overwrites parts > of the thread library and crashes in spectacular ways. > Yeah, about an hour after I sent this I remembered SOMETHING about KSE on 64bit kernels not playing nicely with 32 bit programs.. I need to look that up and see if there are any easy fixes other then "don't do that". For now I've just downgraded the machines to i386 to get the 32bit jdk going, and we've seen a substantial performance increase. Note, I am NOT knocking the 64bit VM; the specific problem set that is being dealt with is not very nice to 64bit architecytures. > I don't have the know-how to fix the sys/compat/freebsd32 stuff to > include all the various kse_* and thr_* system calls properly, I'll > leave that to the FreeBSD kernel people... So noted. I've gotten my hands into the kernel before, I'll see if I can track down that PR I have vague memories of about KSE and 64/32 bit. SO the only question is how did I get it working last night? I guess I probably switched JVMs arround and wasn't running what I thought I was running :( -- David E. Cross
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070330212202.C74265>