1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
|
[[!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
### 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
I have submitted
[preliminary patches](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00182.html)
for global signal dispositions,
which I'm currently testing.
I have since fixed a few things and implemented `SA_SIGINFO`
(which is required by OpenJDK.)
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_7` so far).
The ultimate symbol version to be used will depend on
the time at which the patches get integrated upstream,
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
I will submit revised series for review later this week,
as well as matching Debian patches.
I expect only the last patch (implement global dispositions) will change,
and new ones will be added on top of it.
##### Open Items
* Test patches: in progress, [[jkoenig]], Svante. More volunteers welcome,
of course.
> Current status: 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.
> My current
> [patch](http://github.com/jeremie-koenig/glibc/commit/3ecb990e9d08d5f75adc40b738b35a1802cc0943)
> makes the system unstable.
> --[[jkoenig]] 2011-06-22
* 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
* Get patches reviewed (Roland?), and integrated into official sources: [!]
[[tschwinge]].
* Documentations bits (from [[proposal]] and elsewhere) should probably be
moved either into the appropriate glibc or Hurd documentation
files/reference manuals, or to [[glibc/signal]].
* `SA_SIGINFO` patche is based on [[Samuel|samuelthibault]]'s earlier work.
Thus, have him review the new patch?
* Perhaps have a look at `SA_NOCLDWAIT`.
* Which numeric values to use for `SA_SIGINFO` (and `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_HURD]])
have so far prevented me from testing it.
##### 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.
* [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]:
[[toolchain/ELFOSABI_HURD]].
* 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?
* 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
#### 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.
|
