Date: Wed, 22 Mar 2000 10:08:18 +1030 (CST) From: Greg Lewis <glewis@trc.adelaide.edu.au> To: freebsd-java@freebsd.org Subject: Pre-alpha JDK 1.2.2 patches -- issues Message-ID: <200003212338.KAA04014@ares.maths.adelaide.edu.au>
next in thread | raw e-mail | index | archive | help
[I'm posting this to the list too, in the hope that someone who may not
have time to download and play with the patches will have some clues
about fixes for these just from reading this list :]
1. FreeBSD 4.0 support.
I currently have no access to a FreeBSD 4.0 system to test this work on.
However, Victor Salaman has kindly done some testing on his 4.0 system.
Based on his reports there are a few conditional compilation sections,
although these in general only avoid the problematic areas rather than
fixing them. Victor believes that the chief cause of problems is the
ability of 4.0 to support more than 32 signals.
If you're interested in helping out here (I think this is important
now that 4.0 is out) then you'll need to (at least) take a look in
src/freebsd/hpi/green_threads/src/interrupt_md.c
2. FreeBSD 2.2.8 support.
For technical reasons (the ports version of gcc 2.95.x doesn't assign a
number to __FreeBSD__, it just defines it) much of the support for 2.2.8
was taken out (yes, I was impatient at the time) getting to this point.
I am looking to put it back in at the moment in a commented out form
(and lodge a PR about the gcc 2.95.x ports). However, I have no access
to a 2.2.8 system, so things won't get any further than this commented
out status at the moment.
If you're interested in helping out here you'll obviously need a 2.2.8
system. I don't know the state of Linux emulation on 2.2.8 but I'm
guessing that it won't run the Linux JDK, so you'll need another JDK
to bootstrap the compilation. I believe that the minimal JDK 1.2
available on Keith White's web pages
<http://www.site.uottawa.ca/~kwhite/java2/>; is an a.out version and
could be used to bootstrap things.
3. Alpha support.
I have no access to an machine running the FreeBSD alpha port. If someone
wants to test things out on one that would be great, as I'd love to get
alpha support working. I suspect that things won't work unfortunately,
but I could be way wrong about that :).
4. Assembler version of executeJava
As the comments say, "This is the very heart of the interpreter. This
can be re-written in assembly language for speed on a specific platform,
..." (src/share/javavm/runtime/executeJava.c). And indeed, there is a
an assembly version for the x86. Unfortunately, it causes seg faults
when its used so currently the C version is being used.
You probably need to understand some assembler to look at this. And
possibly m4 as well, as things start off as an m4 file. This appears
to be processed to yield assembler code for the Windows assembler, which
is then converted for as using a masm2as converter. The build process
for this is in build/freebsd/java/jvm/GNUmakefile and is currently avoided
by setting QUANTIFY=1 near the top. The build process currently assumes
GNU m4 (I tested it with 1.4), but it may also work with the standard
FreeBSD m4 processor (this is worth testing).
5. Sun JIT compiler.
It appears that the Sun JIT compiler (libsunwjit.so) is supplied as a
precompiled Solaris x86 binary without source code. This leaves us
rather hamstrung in getting this to work. I can only assume that the
Blackdown folk got access to the source code from Sun. It does, however,
mean that one gets a lot of annoying messages about it not being
able to be loaded. Whats needed here, for the moment, is for someone
to look into preventing this attempt to load it as the default JIT (to
avoid those annoying messages :).
6. Font setup.
The font properties set up during the JDK build
(build/freebsd/lib/font.properties) are the default Solaris set up, which
is possibly not what we want for FreeBSD. For example, the Blackdown
JDK uses a set of font properties based on those for Solaris 2.5.1
(build/freebsd/lib/font.properties.5.5.1). This needs looking into, and
probably will mean some Makefile adjustments to load the font.properties
that we want. There also needs to be some discussion of what the correct
set up for FreeBSD is -- should we mimic Blackdown on this one?
7. DPS and postscript fonts.
As part of the build of libfontmanager.so (see
build/freebsd/sun/font/GNUmakefile) one can optionally enable linking
with a Display Postscript library (this is the default for the Solaris
build). I can only assume that this is to enable the use of Postscript
fonts in Java. While this compilation option is turned off in the
current set of patches (HAVE_DPS=no) I've experimentally compiled this
against the Display Ghostscript library (ports/x11/dgs). This will
be in the next set of patches but before then I'd be grateful if someone
could have a go at actually getting some Postscript fonts working to
verifies that dgs is an workable substitute. I will happily provide
additional patches with regards to getting things compiling for anyone
interested in taking this on.
8. Missing shared libraries.
As Thomas said, when releasing his initial set of patches for JDK 1.2,
"I had to leave out a couple of less important subdirectories in the
$(BUILDDIR)/sun subdirectory". Unfortunately this is still pretty much
the case, although some progress has been made (the font subdirectory
is back in at least, albeit currently without postscript font support).
These extra shared libraries all need to be looked into.
a. audio
This is presumably for Java Audio :). Many of the files appear to
compile, but, not surprisingly, get stuck when trying to compile
the Solaris specific sound support. These Solaris specific files
need to be replaced with versions which support the FreeBSD sound
architecture.
b. jdga
I'm not sure what actually uses this, but it appears to be an
interface to the the Solaris libdga, a direct graphics access library
for Sparc frame buffers. While its not hard to get libsunwjdga.so
itself to compile, looking at the code a bit and the Solaris JDK
leads me to believe there needs to be another shared library which
actually provides some of the functional bindings. This could
possibly be modified to work with the XFree86 DGA extensions. The
first step is to find out what uses it though and how important it
is!
c. cmm
Again, I'm not sure what uses this library, but both the Solaris and
Blackdown JDKs include it. Porting this appears to involve supplying
some definitions appropriate for FreeBSD
(look in src/share/native/sun/awt/cmm/kcmsos.h -- I have an initial
attempt at this if you're interested) and also providing some
wrapper functions for threads. The current choices
(src/share/native/sun/awt/cmm/sithread.h and thread.c) are Win32
threads or Solaris native threads. The option for FreeBSD is
probably to introduce pthreads support, so this work mainly needs
someone who knows a bit about pthreads or is ready to learn :).
d. jdbc
This is the JDBC-ODBC bridge code. Although this is disabled in the
current set of patches, I've actually got a compiled version of this
using the unixODBC package (http://www.unixodbc.org -- there is no
FreeBSD port yet, but it compiles fairly easily). Like the Postscript
font support though, this needs to someone to test it out and verify
that its working. If you're interested, contact me for the additional
patches, including a small one to get unixODBC to find the FreeBSD
pthreads implementation in libc_r.
9. Merging from 1.1.8 patches.
Thomas' initial patches came out in June of 1999, prior to the most
recent JDK 1.1.8 releases by the port team. I haven't had the time to
stop and make sure I've merged all the appropriate patches from the
1.1.8 patches. The task here is to get the patches for 1.1.8 from the
FreeBSD java site (http://www.freebsd.org/java) and make sure all the
relevant bits have made it into the current set of patches for 1.2.
10. FIXMEs
Thomas' patches contained some FIXME notes and I've introduced more
myself. Anyone who feels energetic (these are not all difficult) is
welcome to look into one or more of these and generate some fixes,
which will be gratefully received :).
11. Code correctness.
The main focus of things so far has to been to make things work. This
has almost certainly meant that sometimes sub-optimal fixes have been
employed. Eventually the patches need review to make sure they not only
DTRT but do it in the right way.
12. Rounding bug.
Kees Jan Koster has kindly taken the time to run the JDK through
the Mauve test suite (http://sourceware.cygnus.com/mauve/). Apart
from voting Kees Jan many thanks for this, I was pleased to find that
this uncovered only two differences with the Solaris reference
implementation. One of these has since been fixed, but the other
remains. As Kees Jan says:
"There seems to be a well-known rounding error in the string conversions
in type double. The Mauve test suite converts the double -3.5 to a
string and back and expects -4.0 to come out. In the JDK1.2 reference
implementation does also return -4.0, but the current FreeBSD native
port displays the correct -3.5, which is an error. %-)"
This is more a compatibility issue for 1.2 rather than a bug (Kees Jan's
research indicates that 1.3 also returns -3.5) but is important
nonetheless, especially for people developing on multiple platforms.
If you're interested in looking into this, I can pass on some simple
test code from Kees Jan (which I think is from Mauve) that demonstrates
the problem.
13. Debug graphics pane in SwingSet.
My limited testing with the SwingSet demo (build/freebsd/demo/jfc/SwingSet)
has been quite successful. I have, however, noticed that the Debug
Graphics pane will hang things. This definitely needs to be looked into.
14. Other JIT compilers.
Both SHUjit and the TYA jit have both supported the FreeBSD 1.1.8 JDK
releases. It would be great if they also worked with 1.2. I'd be very
grateful if someone could take the time to investigate how well they
work with the current version of the JDK. These two JITs can be found
in ports/java/shujit and ports/java/tya respectively.
15. GCC versions.
Kees Jan is currently having problems running Swing / AWT stuff with
an unresolved reference to "__pure_virtual". He is, however, using a
different version of gcc. This will be less of a problem when there
is a reasonable compiled version to distribute, but even so, people
who want to compile things up and help out need to know which versions
of the necessary tools work (and which have known problems). Naturally
it would also be good if there was a fix for this :).
--
Greg Lewis glewis@trc.adelaide.edu.au
Computing Officer +61 8 8303 5083
Teletraffic Research Centre
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003212338.KAA04014>