--- Begin Message ---
|
Subject: |
GCJ support is on the way |
|
Date: |
Thu, 20 Oct 2005 09:24:28 -0400 |
|
User-agent: |
Mutt/1.5.9i |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks to mjw's prodding, I pulled the latest (4.0.2) gcj last night
and tried my hand at getting I2P up and running under it. End
result is that overnight, I've had my test network pushing gigs upon
gigs of data with half of the network running under sun's JVM, and
the other half GCJ'ed :)
There were three issues of varying degrees of complexity to get
there though:
* 1) Calendar problems
The first is a bug in GCJ (or maybe GNU Classpath, haven't tested
on Jam or Kaffe yet) - when working with a java.util.Calendar, not
all of the fields were being set correctly when they should be:
import java.util.*;
public class t {
public static void main(String args[]) {
Calendar cal = new GregorianCalendar();
cal.setTime(new Date());
cal.set(Calendar.HOUR_OF_DAY, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
long midnight = cal.getTimeInMillis();
System.out.println("Midnight: " + midnight);
cal = new GregorianCalendar();
cal.setTime(new Date());
// workaround for fields not set
cal.set(Calendar.YEAR, cal.get(Calendar.YEAR));
cal.set(Calendar.DAY_OF_YEAR, cal.get(Calendar.DAY_OF_YEAR));
// continue as normal
cal.set(Calendar.HOUR_OF_DAY, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
midnight = cal.getTimeInMillis();
System.out.println("Workaround: " + midnight);
}
}
Both JVMs (Sun and GCJ) display the workaround properly, and Sun's
displays the original Midnight: properly, but GCJ's
cal.getTimeInMillis() returns 0 (the YEAR and DAY_OF_YEAR fields
are not properly computed).
There are a few places in I2P's code where we use Calendar in this
sort of way, but the latest I2P CVS includes workarounds for these
issues.
* 2) xerces problems
The xerces we ship with won't compile cleanly under GCJ - it
complains about missing references to some sun.* functions. We
aren't using the latest xerces though, and since mjw told me that
it should work, I'll grab the latest and give it a go, upgrading
our CVS xercesImpl.jar if it works (and causes no regressions).
In any case, xerces isn't technically necessary for I2P operation
- its only used by Jetty for the router console (a really, really
useful application, but not technically necessary).
* 3) prng problems
We gobble random bits like crazy. To get a functional system, I
had to disable our PRNG pool (which pulls data out of
java.security.SecureRandom) and enable the weak PRNG (which pulls
data out of java.util.Random). This is not necessarily
entirely GCJ's fault, but more of an issue with the OS which GCJ
doesn't hide.
Shipping with the weak PRNG wouldn't be prudent though, so we'll
need to go back and revive the Fortuna integration effort before
shipping GCJ'ed routers.
Overall, this is fantastic news - I'm glad mjw convinced me to give
it another shot. The I2P SDK, the streaming library, and the client
apps all build fine under GCJ, completely compatible with ones
running on Sun's or IBM's JVM. I've had a GCJ'ed version of
i2psnark running overnight, doing swarming file transfer with normal
i2p-bt and azneti2p peers without problem.
One of the really interesting things here is how this affects SAM -
with the I2P SDK and streaming libraries built into libi2p.so (or
even libi2p.a), there is no reason why Python/C/C++ apps couldn't
link against those objects and use
net::i2p::client::streaming::I2PSocket directly! If someone wants
to explore this avenue, it does sound very promising.
A side note regarding GCJ. I realize everyone always complains that
Java uses up tons of memory, and if only we had native apps it'd
magically allocate out of thin air ;) Unfortunately, while the
overnight router test did well - the VM size did not grow during
operation - the virtual size is larger than with Sun's jvm:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23171 i2p 16 0 535m 49m 11m S 0.0 5.7 93:58.80 router
23435 i2p 18 0 263m 80m 11m S 0.0 9.2 55:48.84 java
The GCJ operational speed was sufficient, though as it uses the weak
PRNG, so its not really a reasonable comparison.
In any case, this is quite kickass, as it means we'll be able to
both integrate more cleanly with other languages AND ship whereever
GCJ ships (DFSG friendly!) Thanks go to the GCJ and GNU Classpath
folks for their hard work!
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDV5icWYfZ3rPnHH0RAnn8AJ9MuDJFpzGup+gPpecBMerNg+x13wCdE9Po
0ALZZ2knBGYm5J9+kjCnZlU=
=aSJz
-----END PGP SIGNATURE-----
--- End Message ---
signature.asc