[e-lang] E-on-Java works with recent gcj

[Eric Northup]

On Fri, 2006-08-11 at 03:41, Toby Murray wrote: 
> Hi e-lang,
> 
> A little while ago,  Eric Northup wrote about his experience with gcj to 
> compile a native version of E.
> (see http://www.eros-os.org/pipermail/e-lang/2006-June/011318.html)
> I've recently been trying to reproduce his results and include some 
> findings below.
> 
> Essentially: I could get a "MetaRune" binary built, although it needed 
> access to the built .class files at runtime. I was puzzled by this 
> because I could see the mangled symbols from the offending classes that 
> it was trying to load inside the "MetaRune" binary by using 'nm'. This 
> is vexing. Eric, did you have the same issue? (see below for how I 
> overcame the few stumbling blocks that presented themselves).

I hit the same problem (though, without finding your solution of
changing the CLASSPATH).

> My "MetaRune" binary could run an AWT application, which was nice to 
> see. It was built from E sources of the 0.8.35f version.

That's great news!

> A quick performance test comparing it to Java 1.5_05 JRE running e.jar 
> from 0.8.35f "purej" showed that it performs only marginally better.
> My "MetaRune" binary completed an execution of a "Hello World" program 
> in around 2.74 seconds (although timings varied from about 2.6 to 3.1 secs).
> JRE 1.5.0_05 running e.jar from 0.8.35f completed the same execution in 
> around 2.94 seconds.

I suspect that most of the costs are related to startup.  Now that you
have a recipe for building a working binary, we can try to profile the
costs and get a better understanding of what is going on.

[...]

> Unlike Eric, I didn't need to modify Native.java (although I'm not so 
> sure my build ended up in the same state as his, although all of the 
> elements of his script completed successfully).

That's interesting.  It may have just been that Eclipse underlined the
native method invocations in red which prompted me to change them.

[...]

> First running the binary complained it couldn't find "<some 
> path>/syntax-properties-default.txt" (or something like that. I don't 
> have the results in front of me anymore)
> The file it was looking for was located in the bin/resources/ subdir. 
> Running the MetaRune binary from there overcomes this error.  (As does 
> adding the full path to the bin/resources directory to the CLASSPATH).
> 
> It then reported that it couldn't load the HeadlessRunnerMgr class. (A 
> ClassNotFoundException from memory). This seems strange because the 
> corresponding symbols for the HeadlessRunnerMgr class are definitely 
> within the MetaRune binary. Can anyone enlighten me on how the 
> classloader from libgcj works and whether it can dynamically load 
> classes built into a binary?

I dug into libgcj a bit, but didn't find much enlightenment.  I tried to
replicate the problem on a Solaris box w/a a gcc unpatched by Fedora, but
never really got that working.  Some of the gcc bugs have since been fixed,
so I should try again.

> Eric's script places the built class files into the BUILD/class subdir. 
> Setting the CLASSPATH to the full path to that directory overcomes this 
> particular error.
> 
> At this point, MetaRune complains that it can't find a (forgotten... 
> sorry) class, which is implemented by E code in the esrc/ subdirectory. 
> Adding the full path to the esrc/ subdirectory to the CLASSPATH 
> overcomes this error and allows "MetaRune" to run properly.

Since gcj-built E binaries still seem to need all the .class etc. files,
it might be simplest to build a .jar and stuff everything in there.

> Essentially, I was able to get the 'org.erights.e.elang.interp.MetaRune' 
> binary to run from the source directory by doing something like this (in 
> bash):
> CLASSPATH=$PWD/bin/resource:$PWD/BUILD/class:$PWD/esrc 
> ./org.erights.e.elang.interp.MetaRune --rune

It's great to hear that you got this working!  :-)

> I'd love to hear of anyone else's experience with this. Would be great 
> to see a native rune binary up and running properly.

One thing I've discovered since my previous mail is that it is much
faster to build if you skip the steps of making all the individual
.o files.  On a machine with enough RAM, it's fastest to build them all
at once; 32-bit machines have to chunk them up anyway, and it seemed that
groups of 100 .class files -> single .o was a good balance between speed
and memory use.

--Eric