ElectricalFire Compiler

Frequently Asked Questions

Author: Scott Furman
Last Modified:

What is ElectricalFire ?

ElectricalFire (EF) is a Java Virtual Machine (JVM) - an engine that executes Java programs. Like many other JVM's, EF compiles Java class files into native machine code for faster performance. (A Java source-code compiler is first used to compile Java into the intermediate bytecode language that is stored in Java class files.) EF's compiler is a JIT (Just-In-Time) compiler because it does not compile code until it is executed for the first time.

What's a JIT ?

JIT is short for "Just-In-Time compiler". Here's how a Java JIT works: When Java code calls a Java method and that method hasn't been previously called, the caller is suspended while the compiler loads the Java class file from the network or file system and compiles it to machine code. After compilation completes, execution resumes in the newly compiled method. The compilation process is completely transparent to the Java program (except for any delay when a method is first invoked.)

JIT compilation is superior to traditional batch compilation because:

It allows on-demand compilation of methods. Unused methods are never compiled.
It enables distribution of platform-independent Java classfiles rather than platform-dependent executables.
In the case of network-loaded classes, a Java program can start before its been fully loaded.

On the other hand, JIT'ing code has its disadvantages:

It causes suspension of program execution while the compiler runs. These short delays often aggregate into a perceptible startup delay for a Java program or they might cause a program to run "choppily".
JIT'ing requires that the compiler be distributed and run as part of the JVM and also consumes more memory in order to perform the compilation.
JIT compilation might not produce code that's as fast as that produced by batch compilers. This is both because the optimization techniques used by batch compilers are too slow to use in a JIT and because insufficient global information is available to make optimizing decisions, e.g. inlining, when compilation proceeds incrementally.

For these reasons, some attention may be given to a batch compilation mode for ElectricalFire.

Is ElectricalFire a port of Sun's JDK ?

No source code from Sun's JDK is used anywhere in ElectricalFire, nor will any be allowed in the future.

What platforms does ElectricalFire support ?

Short answer:

For now, only x86 Linux and Windows 95/98/NT are supported.

Long answer:

Really, the first question to ask is, "What processor architectures does ElectricalFire (EF) support ?". EF was designed to be relatively easy to port to any architecture by creating a compiler "back-end" and writing some assembly support code. The EF source code release contains a relatively complete x86 back-end and very incomplete back-ends for the Power-PC, HP PA-RISC, and SPARC processors.
Second, you have to ask whether your OS is supported by the Java runtime libraries. Since the state of ElectricalFire's runtime libraries is highly incomplete right now, this is still an academic question.

What's the current state of ElectricalFire ?

The project is just starting to get interesting. On x86 machines, more than 90% of the Java Compatibility Kit (JCK) instruction tests now pass and we are able to run javac, the Java compiler that is itself written in Java.

Support for the java.lang and java.lang.reflect packages is substantial, but far from complete. Basic support is available for java.io. Virtually all other classes, e.g. AWT, do not work at all because they require integration with the VM's native code. (When EF was a commercial product, we were relying on being able to use Sun's JDK1.2 classes and native code to implement virtually all high-level library functionality.) We will work with one of the groups working on free Java class libraries, such as the Classpath project, to add Java standard class libraries. Late-breaking news: Sun's new Java licensing scheme might allow the use of the JDK 1.2 libraries with ElectricalFire. Stay tuned for further updates.

Does ElectricalFire support JDK version 1.1 or 1.2 ?

It doesn't really support either yet. See "What's the current state of ElectricalFire ?"

What programming language does ElectricalFire use ?

Most ElectricalFire code is written in C++. A small amount is written in platform-specific assembly code.

Does ElectricalFire contain both an interpreter and a compiler ?

Electrical fire does not contain a Java bytecode interpreter. All Java bytecodes are compiled before executing them. Hence, there is no opportunity to introduce bugs in which Java program behavior differs depending on whether or not bytecode are compiled or interpreted. It might be desirable to add an interpreter to eliminate compilation delay for rarely-executed methods, such as static initializers.

How fast does Java code run using ElectricalFire ?

The truth is, we don't know yet. No large Java programs have been benchmarked yet using ElectricalFire. We would expect EF to be at least as fast as existing JITs. The goal of the project is to produce code that has performance that is roughly on par with C/C++.

I'm a programmer, but I don't write compilers. Can I help ?

Definitely! For ElectricalFire to be successful, we will need a strong conformance and functional test suite.

Another good place to contribute your time would be the Classpath Project, which seeks to create an LGPL'ed replacement for the standard Java class libraries. Without Java class libraries, ElectricalFire would be virtually useless.

How do I use ElectricalFire for running my Java programs ?

It's a little premature for end-users to run ElectricalFire. For one thing, there is only limited implementation of Java classes. You can't use it with Java programs that use AWT, for example. Also, EF is still immature, with many known bugs. Finally, there's no debugging support.

When will ElectricalFire be released as a commercial product of Netscape ?

There are no plans to make ElectricalFire into a commercial product, by Netscape or anyone else that we know of. There are no employees paid by Netscape to work on ElectricalFire.

If Netscape isn't paying anyone to work on ElectricalFire, who's going to do the development ?

You are; This is an open-source project, after all. Four people in the original development team have volunteered to act as developers and/or module owners, including the original compiler architect, Waldemar Horwat. So, we have the seeds of a really good team, but lots more people will be needed to make the project a success. If you're interested in contributing, check out the developer roadmap.

Will ElectricalFire be the official or default JVM for the Netscape browser ?

Netscape's OJI Project is an attempt to allow any JVM to run inside of the browser. Netscape's commercial version of the Mozilla browser could conceivably be distributed with a default JVM. However, ElectricalFire will certainly not have that honor, because there are no plans for it to be released as a commercial product. There is no default JVM for the open-source browser and no plans to nominate ElectricalFire for that position.

What are the origins of ElectricalFire ?

ElectricalFire began as an in-house commercial compiler project at Netscape in early 1997. The compiler, which was never publicly announced, was scheduled for release in June 1998. It was cancelled in January, 1998 when the company made a strategic shift away from Java. The source was made publicly available on mozilla.org using volunteer effort in January of 1999. Click here for a more detailed history of the project.

How did the project get its name ?

Scott Silver, one of the first EF developers, originally wanted to codename the project "Sexual Chocolate". (I'm not making this up.) That name was rejected, presumably because it would confuse Netscape's managers: "So, this Sexual Chocolate project actually has nothing to do with chocolate ?" Instead, Silver proposed "Electrical Fire" (two separate words). For the open-source release, Scott Furman coalesced the two words into one: "ElectricalFire", to make it apparent that the project was not to be confused with a safety hazard. A word of advice for the wise: if you end up working on a project with Scott Silver, do not allow him to handle the project codename.

Under what terms is the source code licensed ?

ElectricalFire is provided under the Netscape Public License. See the NPL FAQ for details.