path: root/user/jkoenig/java.mdwn

[[!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]]."]]"""]]

[[!tag stable_URL]]


# 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.

2011-07-20:
The patches were reviewed by Samuel Thibault.
Samuel pointed out a couple of issues
and I beleive I have addressed all of them (fixes posted).
I'm in the process of publishing updated libc and hurd packages;
provided those work as expected,
the next step would be to get these changes into Debian.

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.