diff options
Diffstat (limited to 'user/jkoenig/java.mdwn')
| -rw-r--r-- | user/jkoenig/java.mdwn | 321 |
1 files changed, 321 insertions, 0 deletions
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn new file mode 100644 index 00000000..700f9c4e --- /dev/null +++ b/user/jkoenig/java.mdwn @@ -0,0 +1,321 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# Improve Java on Hurd (GSoC 2011) + + +## Description + +The project consists in improving Java support on Hurd. +This includes porting OpenJDK, +creating low-level Java bindings for Mach and Hurd, +as well as creating Java libraries to help with translator development. + +For details, see my original [[proposal]]. + + +## Current status + +Feeling slightly behind schedule; but project is very ambitious, which has been +known from the beginning, and there is great progress, so there is no problem. +--[[tschwinge]], 2011-06-29. + +[[tschwinge]] will be on vacations in China starting July 26th, will have +Internet access intermittently, but not regularely. We'll have to figure out +some scheme. + + +### Apt repository + +Modified Debian packages are available in this repository: + + deb http://jk.fr.eu.org/debian experimental/ + deb-src http://jk.fr.eu.org/debian experimental/ + + +### Glibc signal code improvements + +2011-06-29: +Patches were submitted to `libc-alpha` +which implement global signal dispositions and `SA_SIGINFO`. +My latest code is available on +[github](http://github.com/jeremie-koenig/glibc/commits/master-beware-rebase), +and modified Debian packages +are available in my apt repository. + +One question is how the new symbols introduced by my patches +should be handled. +Weak symbols turned out to be impractical, +so I'm currently considering using a Debian-specific +symbol version in the interim period (`GLIBC_2.13_DEBIAN_8` so far). +The ultimate symbol version to be used will depend on +the time at which the patches get integrated upstream +(most likely `GLIBC_2.15`), +at which point we will alias the interim version +to the new one in debian packages. + +I have modified libc0.3 to include a `deb-symbols(5)` file +(alternatively see <http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps>) +so that we get an accurate libc dependency in `hurd` and other packages +when the symbols in question are pulled in. + +[[hurd/libthreads]] (cthreads library) will not be changed. There's no reason +why its behavior should change, whereas for [[libpthread]] it's needed for +conformance. Patches posted on 2011-05-25, but there's a more recent one in +the modified hurd package (adds `_hurd_sigstate_delete` and removes the weak +symbols). + +Another issue which came up with OpenJDK is the expansion +by the dynamic linker of `$ORIGIN` in the `RPATH` header, +see below. + +#### Plans + +The patches are pending review and inclusion upstream. +As soon as we reach an agreement wrt. the new interfaces +(in particular wrt. the value of `SA_SIGINFO`), +the patches will be applied to the Debian libc packages +for broader testing. + + +##### Open Items + + * Test patches: in progress, [[jkoenig]], Svante. More volunteers welcome, + of course. + + > There's an issue with gdb, + > namely signals lose their "untracedness" when they go + > through the global sigstate's pending mask, + > so gdb spins intercepting a signal and trying to deliver it. + > [Patch](http://github.com/jeremie-koenig/glibc/commit/3ecb990e9d08d5f75adc40b738b35a1802cc0943). + + * If [[jkoenig]] thinks it's mature enough: should ask + [[Samuel|samuelthibault]] to test these patches on the buildds. + + > There's a risk that a dependency on my patched libc + > might be pulled in while building packages + > (in particular hurd) + > --[[jkoenig]] 2011-06-22 + + * Waiting on ABI finalization ([!] Roland). + + * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)? + + > Staying in sync with BSD seems the most logical approach, + > so I have defined it to 0x40. --[[jkoenig]] 2011-06-29 + + * Get patches reviewed (Roland?), and integrated into official sources: [!] + [[tschwinge]]. + + > [[samuelthibault]] reviewed the patches and pointed out a couple of + > issues which I'm currently working on: + > + > * Slight behaviour change with respect to forgetting blocked ignored + > signals. POSIX is flexible in this regard but I guess we could retain + > them instead of the current behaviour. + > * Sigstate accessors could be made extern inline functions. + > I suggest we postpone this. + > * Incorrect changes for `msg_{get,set}_init_int(INIT_SIGMASK)` + > * Some comments which can be improved. + > + > Once these are fixed we can probably test the patches in Debian. + > + > --[[jk]] 2011-07-06 + + * Documentations bits (from here, the initial [[proposal]], and elsewhere) + should probably be + moved either into the appropriate glibc or Hurd documentation + files/reference manuals, or to [[glibc/signal]]. + + * `SA_SIGINFO` patch is based on [[Samuel|samuelthibault]]'s earlier work. + Thus, have him review the new patch? + + * `SA_SIGINFO` patch has a few TODOs w.r.t. protocol changes for missing + information, and for FPU state. Providing even incomplete information is + an improvement on the current status. The question is, whether + applications rely on this information in any hard way if `SA_SIGINFO` is + available? + + * We could possibly rename certain fields in `struct siginfo`, say + `si_pid_not_implemented`, to ensure compilation failures for programs + which use them. Or perhaps a linker warning is possible. + + * The FPU state is not included in the `ucontext_t` passed to the signal + handler. On the other hand, `ucontext_t` is actually being somewhat + deprecated: the functions to restore it are no longer in POSIX. + `thread_get_state`() should return this information, in case we decide + to fill the gap, and there might be existing glibc wrappers, too. + + * Perhaps have a look at `SA_NOCLDWAIT`. + + +### Port OpenJDK + +As suggested by [[tschwinge]], I have targeted OpenJDK 7 at first. +I don't expect it will be too hard to backport my patches to OpenJDK 6. +I have succeeded in building a working JIT-less ("zero") version, +although the dynamic linker issue must be worked around. +Porting Hotspot (the original just-in-time compiler of OpenJDK) +should not be too hard. +If that fails we can fall back on Shark +(a portable alternative JIT which uses LLVM). + +Complexity of porting HotSpot: probably low. The complex things should be +arch- rather than OS-specific. Not many Linux-specific interfaces used. +Garbage collection/memory management, etc. and/or most of other Linux-specific +interfaces are already dealt with for the zero build. + +The dynamic linker issue is as follows. +An executable-specific search path can be provided in the ELF RPATH header. +RPATH directories can include the special string `$ORIGIN`, +which is to be expanded to the directory the executable was loaded from. +OpenJDK's `java` command uses this feature to locate +the right `libjli.so` at runtime. +However, +on Hurd this information is not available to the dynamic linker +and as a consequence RPATH components which include `$ORIGIN` +are silently discarded. + +This can be worked around by defining +the `LD_ORIGIN_PATH` environment variable. +(which have I used to build and test OpenJDK so far.) + +#### Plans + +I intend to fix the RPATH issue +by building on [[pochu]]'s `file_exec_file_name()` +[patches](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00023.html). + +I have succeeded in building a Hotspot-enabled `libjvm.so`, +although the current toolchain issues +([[toolchain/ELFOSABI_GNU]]; 2011-07-03: fix committed in binutils) +have so far prevented me from testing it. + +> It turns out the build fails later on in `hotspot/agent` +> because Hurd lack a `libthread_db.so`. +> Also, a Shark version builds, but the result does not work so far. +> +> In other news, Damien Raude-Morvan is +> [working on a kFreeBSD version](http://lists.debian.org/debian-java/2011/06/msg00124.html), +> so I intend to merge my current patches with his. +> +> --[[jkoenig]] 2011-06-29 + +##### Upstream Submission + +On 2011-07-15, *gnu_andrew* talked to us in the #hurd channel (freenode IRC), +who is a maintainer of IcedTea. He's supportive of the porting approach, and +is willing to review and integrate small patches for individual issues (rather +than some huge patchset). Send patches to <distro-pkg-dev@openjdk.java.net>. + +##### Open Items + + * [!] [[tschwinge]] to have a look at [[pochu]]'s `file_exec_file_name()` + patches, whether it's generally the right idea. + + * Assuming it is, continue with getting `$ORIGIN` working. + + * `libthread_db.so` issue. Likely, the Serviceability Agent is used by jdb + and the like only, so for now the goal should be to lose some functionality + by removing/avoiding this dependency. + + * [[java-access-bridge]] (not critical; JVM appears to work without) + + * They seem to have a rather heavy-weight process for such projects: confer + <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>, + for example. Do we need this, too? + + > Probably not. + > My current approach (and Damien's wrt. the kFreeBSD patches) + > is to add preprocessor directives in the Linux code + > to make it more portable. + > --[[jkoenig]] 2011-06-29 + + * Eclipse + + OK for testing -- but I'd very much hope that it *just works* as soon as we + provide the required Java platform. But it may perhaps have some + Linux-specifics (needlessly?) in its basement. Is it available for Debian + GNU/kFreeBSD already? + + +### Java bindings for Mach + +The code is at <http://github.com/jeremie-koenig/hurd-java>. + +[[tschwinge]]'s notes for building with... + + * GCJ installed (due to the current Debian multilib confusion): + + $ tmp1=/usr/lib/gcc/i486-gnu/4.6 tmp2=/usr/lib/i386-gnu/gcc/i486-gnu/4.6 LIBRARY_PATH=$tmp2 COMPILER_PATH=$tmp1:$tmp2 C_INCLUDE_PATH=$tmp1/include make + + * OpenJDK installed (to have it find the shared library, and the jni.h header + file): + + $ jdk=/usr/lib/jvm/java-7-openjdk LD_LIBRARY_PATH=$jdk/jre/lib/i386/jli C_INCLUDE_PATH=$jdk/include make + +Doxygen-generated documentation is available at +<http://jk.fr.eu.org/hurd-java/doc/html/>; or run `make doc` yourself. + + +#### Plans + +(just started.) + + +##### Open Items + + * [[tschwinge]] has to read about RMI and CORBA. + + * MIG + + * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult. + + * (Unless you want to make MIG's own code (that is, not the generated + code, but MIG itself) look a bit more nice, too.) ;-) + + * There are also alternatives to MIG. If there is interest, the following + could be considered: + + * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if + there would be any benefits over MIG, like better modularity (for the + backends)? If we feel like it, we could spend a little bit of time on + this. + + * For [[microkernel/Viengoos]], Neal has written a RPC stub generator + entirely in C Preprocessor macros. While this is obviously not + directly applicable, perhaps we can get some ideas from it. + + * Anything else that would be worth having a look at? (What are other + microkernels using?) + + * `mach_msg` + + * Seems like the right approach to [[tschwinge]], but he hasn't digested + all the pecularities yet. Will definitely need more time. + + +## Postponed + +Might get back to these as time/interest permits. + + +### GCJ + + * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly + dead? (True?) + + * Thus perhaps not too much effort should be spent with it. + + If the POSIX threads signal semantics makes it going, then great, otherwise + we should get a feeling what else is missing. + + +### Joe-E. |