[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-java
Subject:    Netscape's Electric Fire (JAVA VM ) works on FreeBSD
From:       Amancio Hasty <hasty () rah ! star-gate ! com>
Date:       1999-02-27 8:32:27
[Download RAW message or body]

For build instructions and downloading see:

http://www.mozilla.org/projects/ef/unixbuild.html

For technical background on EF see:
http://www.mozilla.org/projects/ef/techdocs/index.html

Make sure that you use egcs from the ports distribution for compiling EF and 
nsprpub.

EF so far only works with jdk 2 java classes. to compile java programs I use 
"jikes" with
the jdk 2 classes.

EF native method implementation is incomplete and Scott Furmant the Netscape 
EF champion had this to say:

fur@netscape.com said:
> Amancio Hasty wrote:  If anyone has any clues as to how to tackle
> implementing the  unimplemented native methods  please let me know. EF
> has an implementation of *some* native methods - most of java.lang,
> java.lang.reflect and java.io, for example.  However, my expectation
> is that we will throw out a large part of the existing native methods
> in favor of a 3rd-party unified runtime library that includes its own
> versions of both native and Java methods.  The two most obvious
> suppliers for EF's runtime are the GNU Classpath effort and Sun's JDK
> 1.2 (under the new community licensing policy). To the extent
> possible, EF should support both libraries, but the legal requirement
> to avoid tainting Classpath and ElectricalFire with Sun code may cause
> problems, e.g. if a developer looks at the Sun runtime library sources
> then they can't contribute to the Classpath effort.  I know that Aaron
> Renn of Classpath expressed some interest on integrating their code
> with EF, so you might contact him: arenn@urbanophile.com  -Scott 

jikes Test.java          
time ./sajava -nosys -classpath $CLASSPATH Test  
0.311u 0.062s 0:00.39 94.8%     43+1191k 0+0io 0pf+0w

jdk1.7
time java Test     
7.590u 0.043s 0:07.88 96.8%     6+758k 0+0io 0pf+0w

The benchmark is a  little misleading because EF did not compile all the 
java classes .

./sajava -classpath $CLASSPATH Test
linker_path = /maxtor/gcsns/ef/x/mozilla/ef/dist/FreeBSD_DBG.OBJ/bin/../lib:/ho
me/hasty:/usr/local/netscape/lib/freebsd

*** NOTE: Throwing verify error: Error in reading class file: file not found, 
or has errors

*** NOTE: Throwing verify error: Error in reading class file: file not found, 
or has errors
Netscape_Java_java_lang_Thread_registerNatives not implemented
Netscape_Java_java_security_AccessController_getStackAccessControlContext not 
implemented
3.176u 0.739s 0:05.54 70.3%     26+15786k 133+0io 24pf+0w     

The warning messages are just that which only are printed when EF is compiled 
with -DDEBUG.

EF is not twice as fast the jdk for there is a fixed cost for the 
compilation/linking of java
classes after that it really takes off and it is quite evident per my first 
sajava run.

In playing around with EF I found that a thread gets fired to compile/run a 
program and that
that the system keeps the compiled classes in memory so that a second run 
enjoys the
speed of unoptimized C code. In essence  EF compiles the java program into 
memory
and it then executes it . You can actually see the code which EF generates by 
including
the "-html" in your run : sajava -html .

The code for outputting x86 diassembled code comes straight from the FreeBSD 
kernel . Scott did the integration I merely gave him the code .


The  netscape.public.mozilla.java newsgroup is open to discussions on EF.

Last but not least EF is at an early stage so it is not for the faint of heart.

	Enjoy,
	Amancio







To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message


[prev in list] [next in list] [prev in thread] [next in thread]