Red Hat’s Eclipse Engineering team has freed the popular integrated development environment from its ties to a proprietary Java Virtual Machine.
Eclipse Goes Native
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Has a native binary been built for the 3.0 release?
It’s nice to see that a proper native compiler for Java has reached such a milestone of maturity. To tell the truth, I have never really seen why everyone is so enamoured with bytecode these days. I can see the use for limited problem domains such as web applets, but for more general applications, I don’t really understand why “write once, compile and debug everywhere” is really so much easier than “write once and debug everywhere.” This is especially true when you have languages that don’t let you foolishly take into account things such as pointer size, and thus prevent cross-platform compilation.
Now, one might argue that even if we forgo runtime JIT’ing, we can still distribute binaries as abstract bytecodes that get compiled at install-time. While this is indeed a good point, it must be noted that Java bytecode is really a poor intermediate representation for an install-time compiler, because it is too low-level for aggressive optimization. If platform-independent binaries are desired, a higher-level, virtual-register oriented intermediate form (like LLVM) seems much more suitable.
[…] I don’t really understand why “write once, compile and debug everywhere” is really so much easier than “write once and debug everywhere.” This is especially true when you have languages that don’t let you foolishly take into account things such as pointer size, and thus prevent cross-platform compilation.
Well, it saves a lot of work to not have to worry about pointer sizes, or memory management at all. For apps that are largely idling (i.e., GUI apps), the performance penalty is minimal if the widgets are native. Java had the right idea, but it seems that they are being passed by CLR-based frameworks.
Now, one might argue that even if we forgo runtime JIT’ing, we can still distribute binaries as abstract bytecodes that get compiled at install-time. While this is indeed a good point, it must be noted that Java bytecode is really a poor intermediate representation for an install-time compiler, because it is too low-level for aggressive optimization. If platform-independent binaries are desired, a higher-level, virtual-register oriented intermediate form (like LLVM) seems much more suitable.
That’s a good point — algorithmic optimizations can be precompiled, and platform-specific optimizations can be in the JIT compiler, to the extent that they are orthogonal.
Well, it saves a lot of work to not have to worry about pointer sizes, or memory management at all… Java had the right idea, but it seems that they are being passed by CLR-based frameworks.
I still don’t get it. What does using a VM have to do with not having to worry about pointer sizes or memory management? The CLR is still usually JIT’ed. I’m suggesting getting rid of the JIT compiler entirely, like GCJ, and compiling directly to native code. I just don’t see what the JIT VM buys you.
That’s a good point — algorithmic optimizations can be precompiled, and platform-specific optimizations can be in the JIT compiler, to the extent that they are orthogonal.
Again, why the JIT? Why not distribute the “binary” as a high-level representation and compile it at install time? You could use a Java or CLR bytecode as that representation, but stack-oriented bytecode makes implicit a lot of information that register-oriented optimizers would rather make explicit. Hence my suggestion of something like LLVM, which was designed for optimizing compilers rather than interpreters.
From the article …
Another problem we had was performance. Eclipse worked well on Microsoft Windows but the version available at the time was pretty slow on Linux. We found that startup alone took well over a minute, and early user testing found that the interface was a little too sluggish for comfortable use.
It seems to me that the real problem is with either a sluggish implementation of a JVM for Linux or Linux itself. Nuff said!
> It seems to me that the real problem is with either a sluggish implementation of a JVM for Linux or Linux itself. Nuff said!
I dont know too much about this, but my impression is that a lot of the perceived sluggishness comes from the startup of the JVM itself. My own experience with webpages that implement stupid tickers & such using java usually start with the hard disk making some noise, and an icon appearing in the system tray that says “java console” or something. In most cases, the CPU utilization goes up only as this thing starts up, after which things seem to run smoothly most of the time. So if the issue is mostly with the startup, why hasnt we implemented it as a system service and have it handle any calls to the JVM itself? Could anyone please explain?
——offtopic part——
On a slightly different topic, most people I have spoken to have recommended that I invoke the JVM with the “-server” argument, but it has never worked on my machine, quitting by saying “Error: no `server’ JVM at `C:Program FilesJavaj2re1.5.0inserverjvm.dll’.” Does anyone know what am I missing here? Thanks!
It’s such a shame that the only people to use hotspot optimization on x86 instructions is the Virtual PC crowd (now owned by Microsoft). If you precompile your Java and then JIT the resulting machine code you can have dynamic and static optimization. If decoding machine code is too hard for ya, just get your static compiler to generate the mnemonic of the instructions in another section of the binary that you can use to look it up (probably be faster too).
I’m not sure about the 1.4.x JREs, but in the current 1.5 betas, the file jre1.5.0inserverjvm.dll isn’t included in the regular JRE distribution. They are however, in the 1.5 sdk package
I copied “…inserver*.*” over from the JDK to the JRE, & the “-server” option works now.
Microsoft apparently has a dynamic optimizer for windows 2000. This paper:
http://www.cs.washington.edu/homes/lerns/mojo.pdf
Describes it. The results are promising but at the time that this paper was written the system was not useful for real world applications (like Word: half as slow as normal, and FoxPro: 40% slower) but one would hope that some serious engineering has gone into it and we can look forward to transparent dynamic optimization on x86 platforms in the near future.
and all they got was one second less on start up time? I mean, it seems nice and all, but, also seems like a pain, and not something I would want to do w/ my programs, just to get a minor performance boost. Maybe they should have just looked into optimizing eclipse a bit more.
The RedHat dude spoke of Eclipse being slow? I don’t know, I use Eclipse 3.0 RC3 on a P3 – 800 with 386 MB on WinXP with a very memory eating Perfoce plugin and I am not complaning. At home I work on a P4 – 2.4 with 1 GB of memory on Linux (Fedora) and it runs very smooth.
I completely agree with you. These guys should spend their time on fixing the (very, very slow) SWT/GTK2 port. If SWT/GTK2 was as fast as SWT/Win32 no one would be complaining about Eclipse being slow. Too bad there are still licensing problems with TT regarding Qt, else we would have a public SWT/Qt port right now (yes, that thing exist, but it isn’t publicly available ATM).
If I understand you correctly, you want to distribute programs as LLVM, and then have that representation optimized and compiled upon install (not execution) at the client.
That makes perfect sense; developers would still have JIT for rapid development.
Two questions:
* Would the extra steps of compiling to LLVM, then to machine code, be justified for a dynamically type language, e.g. Python?
* How good would the optimization be in your scheme, with the machine specific optimization separated from anything done in producing LLVM code?
The article mentions “Red Hat’s Eclipse Engineering team”. Huh? Eclipse is an IBM project…
It also mentions “Red Hat Developer Suite”. What is that anyway?
Also, anon wrote:
all that work … and all they got was one second less on start up time?
For a first attempt, that sounds pretty good to me. Not to mention, it probably uses less memory (since there’s no JVM running), and may even execute faster.
Now personally, I’m looking forward to when Classpath’s Swing is complete enough that we can have a natively compiled jEdit.
Whoops. Sorry. http://www.redhat.com/software/rha/developer/
Yeah, right. 15 seconds to startup. Windows bootup is faster than this.
Yeah, right. 15 seconds to startup. Windows bootup is faster than this.
I suppose you reffer to Win95 on a P4 3.0Ghz and 1G Ram,isn’t it?
Agree…
but… i think the limit of memory for win95 is 512… if i recall correctly…
Anyway, unless you have some sort controlers that keep device info, only the POST can surpass 15 seconds (as it happens in my computer with the raid controller).
Cheers…
First, someone mentioned that RedHat should have worked on optimizing SWT/GTk+. Well, gtk+ has redraw issues of its own but I’ve heard that it’s not the real problem. The real problem appears to be either the Linux JVM or Linux itself. The slowness of Eclipse on linux has been discussed on the eclipse news groups and mailing lists quite a bit. Some theories are linux’s threading model is the culprit, but who knows.
The GCJ compiled Eclipse might start up faster, but most likely it actually runs either a little bit slower or a lot slower. This is pretty well known. JVM 1.5 should be quite a bit faster too.
I never understood the appeal of WORA. Personally, I prefer Write Once Compile Everywhere. Making people install a JVM is just a pain and if you have a decent installer you have to package it up into native installers anyway. Microsoft has the advantage that most windows users XP and up will eventually have .NET runtime, but many people just don’t have JVMs on linux.
No matter how well a program performs most people will still complain about it being too slow. Go! Go! Go!
I agree that Java on Linux need some optimization (already progressing, look at the Blackdown project), but I think the real problem of Eclipse is the SWT/GTK2 port. Have you ever tried to run Eclipse/Motif instead of Eclipse/GTK2? The speed difference is _huge_, and that’s not only caused by the prettier fonts/themes of GTK2. SWT/Fox (http://swtfox.sourceforge.net/) is also a _lot_ faster. IMHO the RH developers should really spend their time at fixing GTK2 and SWT/GTK2, user-visible this will make a much bigger (speed) difference than these GCJ efforts.
SWT-FOX is very fast. And it doesn’t look all that bad, either
Just check out this screenshot: http://swtfox.sourceforge.net/gallery/snapshot1.png
And it makes FOX feels native, even using the JVM! The only issues left are startup time, and excessive memory usage.
There’s no real point in trying to make it run fast on a sub 500MHz machine. It’s a waste of time, imo. It’s fast enough on any > 1GHz machine. Except when using SWT-GTK ofcourse. Then you’ll need at least 2GHz
I agree that GTK has some serious speed issues. Firefox under Linux runs extremely slow for me (redraw speed), but under Windows it’s okay.
We have to get our display system/toolkits working decently. Come on XOrg and Freedesktop.org!!
“I agree that GTK has some serious speed issues. Firefox under Linux runs extremely slow for me (redraw speed), but under Windows it’s okay.”
I run Firefox both at work on Windows (2000 & XP) and at home I run the GTK2 version of Firefox on a 2.4 kernel and the redraw speed is pretty much the same as with Windows for equivalent processors. It could be a window manager problem as I am running XFwm4, maybe its slower with Metacity or KDE I’ll have to try that.
I have not yet run Eclipse under Linux (I have only been trying it at work) and it takes about 20 seconds to load Eclipse 3.0RC2 on a 1.8 MHz P4 256Mb running Win 2000 which seems slow enough which is why I am not running it at home untill I upgrade my system JEdit will have to do for now..
There’s no real point in trying to make it run fast on a sub 500MHz machine. It’s a waste of time, imo. It’s fast enough on any > 1GHz machine. Except when using SWT-GTK ofcourse. Then you’ll need at least 2GHz
I used Eclipse with SWT-GTK on my old Duron 650 MHz with 192 MB SDRAM and FreeBSD 5.0 early last year. Agreed, it didn’t run superfast, but it never felt slow, even when working with large files and several workspaces.
i use eclipse on windows and mac and it’s just fine speed-wise….why not just find (or make) a quicker jvm to run on linux? if it works on os x and windows, then the code shouldn’t be an issue. Sounds like they fixed the effect and not the cause.
Imagine how lighting fast a native win32 version would be! What will we do then? It’s just like Jeffs said; we’re not fixing the cause.
But, the latest Sun JRE’s seem to have gotten faster. JBuilder X and MagicDraw UML feel pretty fast here.
Actually eclipse-gtk2 is slow, and not because linux is slow, or gtk or java is slow.
It is slow because of the way eclipse/swt makes use of GTK.
And since motif is relativily ugly, I’d recommend swt-fox too, it’s fast and looks nice.
One thing Sun never realized was that you can have all the benefits of a VM with native compilation. Their negative dogmatism earned Java a lot of people who hated it for clunkiness and slowness.
There should have been a native compilation path for Java from day one.
The maturity of the gcj project will be really there when they can take the aproach of compiling eclipse directly from source to binary and not from bytecode to binary. That will tell how good the compiler have become concerning standar compliance. Another thing I keep an eye on is the gcjx project from one of the gcj developers, cleaning baseline code after some years of experience is always a good thing to me.
i use eclipse on windows and mac and it’s just fine speed-wise….why not just find (or make) a quicker jvm to run on linux? if it works on os x and windows, then the code shouldn’t be an issue. Sounds like they fixed the effect and not the cause.
This was addressed in the article, which you did not read. They want it to run on x86-64.
There are many people here who state their experiences that the linux version starts slower than on windows. I have a different impression. At the computer lab I have access to, there are dual-boot workstations (Windows 2000 and, I think, Red Hat). On these, eclipse starts up significantly faster on GNU/linux than with windows. So I am sure it depends on the used JVM. (I should note that on my home PC, which is about the same speed class as the lab PCs, even much smaller java applications than eclipse take longer to start than eclipse in the computer lab).
> There should have been a native compilation path for Java from day one.
Maybe, but in the end, we’ve now got something better than Sun would’ve ever offered: a *Free* implementation in GCJ/Classpath.
insdr, thanks for mentioning gcjx:
http://sourceforge.net/projects/gcjx/
That looks like an awesome idea. Tom Tromey’s blog is here:
http://www.peakpeak.com/~tromey/blog/
where he ocassionally mentions his work on it.
The main problem with Eclipse is the sluggish performance of GTK2 compared to Windows or Qt…
If you really wanna speedup eclipse, optimize GTK2!
GTk+ requires some changes in xorg codebase which is getting done now besides redhat wanted eclipse to be based on gcj instead of sun jdk for various reasons and they have achivied that albiet with some inelegant hacks. so thats what this is all about
Maybe all of this just shows that Java is nothing more than Unix VB. Nobody uses VB to make large applications, nor Python nor Perl. Java, while a better language than VB, is not suited for those large GUI desktop appliations such as office suite, or large/intricate editors as Eclipse or NetBeans, … simply because it is a high level virtual machine language. Some of the applications are “bearable”, but most large scale GUI dekstop Java applications sucks or needs tweaking to work adequately.
Maybe C++ is the better language to be used for this, with cross-platformed GUI toolkit, it is not that bad. There’s also a new language called “D” (successor to C++, created by Walter Bright of Digital Mars) which looks sorta like a native Java (or native C#) that is also good, but it is not popular and lack of support (from big players).
Too bad, just like some people use VB to do the wrong thing (just because it is the only tool they know or because it is popular and a “standard”), Java is used to do the wrong things also.
That makes perfect sense; developers would still have JIT for rapid development.
How does JIT enable rapid development? The most rapid development environment in existance is a live interactor, and native compilers are plenty fast for that. They just have to turn down the optimization level.
* Would the extra steps of compiling to LLVM, then to machine code, be justified for a dynamically type language, e.g. Python?
Sure. Maybe not Python, because Python wasn’t really designed to be compiled efficiently, but for lot’s of dynamically-typed language (Scheme, Smalltalk), a native compiler is an order of magnitude faster than the JIT.
How good would the optimization be in your scheme, with the machine specific optimization separated from anything done in producing LLVM code?
Pretty good. LLVM is high-level enough that it can represent most of the interesting optimizations for something at the C++ level of abstraction. Anything above that is usually language specific (eg: type inference for Lisp, class hierarchy analysis for Java), rather than machine-specific.
>Too bad, just like some people use VB to do the wrong thing (just because it is the only tool they know or because it is popular and a “standard”), Java is used to do the wrong things also.
Yeah… engineers at IBM are stupids and don’t know any other language… please, be serious. Java for big desktop aplications is as good as C++, and Eclipse/Websphere are perfects examples of this… the problem with linux versions isn’t java or the JVM. The problem is the GTK2 bindings.
I’m not saying that IBM engineers are stupid or know just one language. But Java seems to me has become a religion (one-language-for-all-and-everything) since the days the Sun evangelists came out. Even Microsoft got into the rage, except for them it’s .NET managed code for everything.
And you know how religions can make us blind and doing the wrong things in the name of good.
If Eclipse has been written in C++, there would have been no need for any of this tweaking. Even if it has been written using some of the native-compiled languages that are higher level than C++ (if you object to C++), it would have performed better than a Java one running on a VM.
There might be problems with GTK2 bindings, but still, as the report said, the natively-compiled-Java Eclipse performs better than the old one. So doesn’t that mean that using a native-compiled language for Eclipse in this case is better than using Java???
Java has its use, and Python or Perl have theirs. I’m not objecting to Java running on a VM, it has some advantages (dynamic loading, gc, meta-data, error checking, …) but also weaknesses (such as speed, resource-intensive, …) along with that.
Should we use a different tool (along with its own advantages and weaknesses, such as can be said of C++) for this??? I just wonder how many more of these tweakings do we need???
I’m not objecting to Java running on a VM, it has some advantages (dynamic loading, gc, meta-data, error checking, …)
None of these are advantages of running in a VM. Natively-compiled languages that do all these things (and more) are a dime-a-dozen.
I agree. Only it seems to me that those (dynamic loading, gc, meta-data…) are easier to use and implement for VM or interpreted languages than natively-compiled ones. It’s been my experience that for example, intellisense (interfaces) is faster and easier for interpreted languages than natively-compiled ones; garbage collection always seems weird to me in the natively-compiled ones. Once a program is compiled to native codes, a lot of information is lost; while for programs executed in a virtual machine, we have more control and knowledge of the execution processes and data in the programs (and therefore better error catching and cleaning, if the VM is correctly implemented and any good) than for a natively-compiled program running without a “watcher” or “executioner”. Sorry about my rampaging, hope that I am making some sense here.
are easier to use and implement for VM or interpreted languages than natively-compiled ones.
Not in the least.
intellisense (interfaces) is faster and easier for interpreted languages than natively-compiled ones;
That’s generally because most intellisense features use an ad-hoc parser for natively-compiled languages. Java’s syntax is simple enough that an ad-hoc parser works, but C++’s is so complicated that it doesn’t. Using an ad-hoc parser is the wrong idea anyway. The compiler can easily provide more than enough information to feed the IDE.
garbage collection always seems weird to me in the natively-compiled ones.
Again, it’s because most native-code compilers weren’t designed with garbage collection in mind. Lisp, Scheme, ML, and Dylan native-code compilers integrate very naturally with the GC.
Once a program is compiled to native codes, a lot of information is lost;
Only if the compiler throws it away! The reason Java can support stuff like metadata is not because it runs in a VM, but because the java compiler doesn’t throw away all the metadata like C++ compilers do. A compiler language can easily keep metadata in tables, just like java compilers do.
and therefore better error catching and cleaning, if the VM is correctly implemented and any good)
A good native code compiler will insert saftey checks in the code, which are every bit as effective as having a JVM “watch” it.
Thank you for your response, appreciate it. That clears the matters up a lot.
How does JIT enable rapid development? The most rapid development environment in existance is a live interactor, and native compilers are plenty fast for that. They just have to turn down the optimization level.
Hmm — taking C(++) as an example, running raw code through cint is much faster (4-10x) than a compile-link-launch cycle through gcc with -O0. Though, perhaps this is due to gcc cruft than having to write to machine code; what else am I missing?
Sure. Maybe not Python, because Python wasn’t really designed to be compiled efficiently, but for lot’s of dynamically-typed language (Scheme, Smalltalk), a native compiler is an order of magnitude faster than the JIT.
Why is Python weak in this area?