Fast Native Eclipse with GTK+ Looks

Mark Wielaard writes "The gcj team created a natively compiled build of the Eclipse IDE. The resulting binary starts up faster then with any traditional JVM since there is no virtual machine to initialize or slow byte code interpreter or just in time compiler involved. This means that gcj got a lot better since the last Slashdot story in December about gcj and Eclipse. Red Hat provides RPMs for easy installation. Footnotes has screenshots by Havoc Pennington of the Eclipse IDE with GTK+ widgets."

Comments

Startup sure, but how fast does it run?

[iamacat]

From what I heard so far, gcj has problems with garbage collection and doesn't generate very good code. Did I miss any dramatic improvements recently? Also, how complete is the class library?

Re:Startup sure, but how fast does it run?

[millenium]

GCJ uses the same backend as GCC (C/C++). Its code should therefore be as good or as bad as for that one.

The class library is certainly complete enough to write nice, crisp, fast and beautiful native GUIs with SWT.

The true question is: What can you do with GCJ?

The answer is: everything you can't do with the JDK, because the JDK starts up too slowly, because Swing suffers from obesity, and because both memory and disk footprints of the JRE are a disaster.

Re:Startup sure, but how fast does it run?

[Call Me Black Cloud]

From your comments it's apparent you're not a Java programmer then, because you merely repeat old complaints that are no longer valid. Ok, sure, the JRE takes up a bit of space but compared to the size of hard drives today the amount is trivial. Having the JRE on disk is like installing the MS or Borland libraries (or Linux counterparts) that some applications use - once it's there other applications don't have to include the code as part of the executable.

Swing suffers from obesity - what does that mean?

I've been developing Java applications for years (including a stint as project lead on a weather satellite imagery analysis program) and I know firsthand how much Java has improved. Spend some time writing applications in Java, using Swing (I use Netbeans for my IDE)...you'll see how sporty applications can be. Also check out Sun's Java Games community for some links to games that really exhibit excellent performance.

Re:Startup sure, but how fast does it run?

[Binary Gibbon]

I think you miss the point; Java is not designed for the sort of speed and efficiency necessary for, say, startup scripts. So, in the context of Java's purpose, those features are not really important. Java is designed for portability and the ease-of-use (from a programmer's standpoint) that comes with the very large amount of memory management that the virtual machine takes care of. Does this result in a larger footprint, and slower operating times? Undoubtedly. But if those things are mission critical, do not program in Java.

Re:Startup sure, but how fast does it run?

[red_gnom]

Of course, I don't see myself as a "Java programmer" or a "carpenter" or a "brick layer". I wouldn't take any pride in that. I have a degree in computer science...

...Because of the size and footprint issues, you can't do embedded with Java.

To further extend your knowledge in computer science, look into the Internet tool called "Google". Using it can save you from ridiculing yourself by publicly posting uneducated statements:

Embedded Java

Re:Startup sure, but how fast does it run?

[iapetus]

I have a degree in computer science. The day you will get a college degree, or at least some formal qualification, you won't need to go around saying: I am a "Java programmer".

What utter garbage. I'd describe myself primarily as a Java programmer, and I've got a college degree, a masters degree and a bucketful of professional qualifications.

Who are you that you can say what can be important in someone else situation?

I don't know. Who are you that you can say the same? There are plenty of cases where Java can be used in shell scripts, or where the same functionality can be achieved using a tool such as Ant (which is very widely used these days). Startup time isn't always the be all and end all of what people need from their programs. If it is, then obviously there are better tools than Java. I'd have hoped that at some point they'd have taught you in your college degree that there are plenty of tools out there and that there's such a thing as picking the right tool for a given job. That tool may be Java, it may be perl, it may be lovingly hand-crafted assembly code.

The fact that you seem to ignore that means that you also ignore the things that you can do with the JDK that you can't do with gcj, and ignore the requirements people may have that your preferred way of working doesn't address. And also, it seems, the fact that some people don't agree with your blanket generalisations.

Re:Startup sure, but how fast does it run?

[krumms]

Gee whiz, you're a raving spastic.

I have a degree in computer science. The day you will get a college degree, or at least some formal qualification, you won't need to go around saying: I am a "Java programmer".

Right, and the day you get around to pulling your head out of your own ass - or at least do something to stop you talking so much shit all the time - you won't need to go around pompously saying, "I have a degree in computer science."

Who are you that you can say what can be important in someone else situation?

Has it ever occurred to you that not everybody needs the speed? Anyway, it's you yourself who is trying to say what's important for everyone else.

Because of the startup time issues you can't use Java programs in shell scripts.

Think Bash, think Perl, think Python, think Ruby. You'd use any of the former before you'd think about using Java OR C++. At least, being a CS grad, I hope you would - unless you had good reason to do otherwise.

And just to be picky, it's only the larger Java applications that will noticibly kill your startup times (Tomcat springs to mind).

Because of the size and footprint issues, you can't do embedded with Java. Now you're probably going to say that embedded applications are not important ...

GOOGLE FFS

Re:Startup sure, but how fast does it run?

[be-fan]

Interestingly, Python is a much higher level (as a language, not necessarily libraries) language than Java, yet the Python VM takes no time at all to start up.

Re:Startup sure, but how fast does it run?

[be-fan]

Python is totally dynamic. Python functions can be completely generic. For example:

class bar(object):
def foo(self, obj):
obj.register(self)

bar::foo() is completely generic. It can register itself with any object, as long as that object supports the register() method. In Java, you'd have to define an interface and have all possible objects you're interested in registering with implement that interface.

Object oriented languages have similar capabilities, but they do *not* all offer the same abstraction capabilities. Java is a lowest-common-denomenator OO language. Its got classes, single inheritence, single-parameter polymorphism, and that's about it. It certainly doesn't have the abstractive capabilities of C++ (with templates) much less something even higher level like Python.

Re:Startup sure, but how fast does it run?

[__Reason__]

It runs very nicely! The native-compiled eclipse is noticably more snappy and responsive than it is on the JRE 1.4.2 on my (XP 1800) machine. It also seems quite stable - I stress-tested it for about half an hour last night and couldn't produce any bugs or crashes.

Re:Startup sure, but how fast does it run?

[gidds]

In Java, you'd have to define an interface...

Not necessarily; reflection could do this with any old Object. Admittedly, the interface solution is normally neater, but it's also a better solution for maintenance purposes - too much dynamism makes code easier to write, but can make it much harder to maintain and introduce subtle bugs unless you're very disciplined (and, more importantly, so are every one of your predecessors and colleagues...)

Re:Startup sure, but how fast does it run?

[nathanh]

I wouldn't take any pride in that. I have a degree in computer science.

So do perhaps 90% of the people reading Slashdot. IMO it's not much to be proud of.

The day you will get a college degree, or at least some formal qualification, you won't need to go around saying: I am a "Java programmer".

You're a pompous ass. He probably has better qualifications than you do.

Re:Startup sure, but how fast does it run?

[Simon Brooke]

There are lots of things you can't do with Java. Little CLI apps like 'ls', 'cd', etc, would be painful to use if they were written in Java, because of the startup costs of the VM. It takes GCC 0.004 seconds (ie: within measurement error) to startup and give me the usage message. It takes javac 0.330 seconds to do the same.

two responses to that.

1. People have no problem with little perl scripts run from the command line, but perl has exactly the same startup overheads as Java.
2. Running commands under bash is running them in, effectively, a C language environment. The basic C language shared libraries are already loaded. If you had a Java shell already running in its own JVM it could invoke instances of Java classes at the same order of cost as a conventional shell starting an ELF executable.

I write 95% of my work in Java. It's just as performant as anything else doing the same job. Most of my stuff (web applications) typically service small requests - very much like ls, albeit in a different environment. But the trick is, you don't start a new JVM for each invocation; you have a JVM running all the time and service the requests you receive within it. In this sense, the webapp is analogous ot a shell.

I'm not saying Java doesn't have problems - it does have a significant problem which is Sun's attitude to 'intellectual property' and their continued restrictive licensing. But speed and efficiency are no longer problems Java has.

increases the credibility of GCJ

[millenium]

GCJ aka "native Java" now really seems to be ready for its day under the spotlights.

load times

[khuber]

I still don't understand why load times are such a big deal. Do people sit there and start and exit applications continuously?

I leave stuff like mozilla, eclipse, and xemacs running for weeks on end.

Re:load times

[aled]

Yes! I love so much all those modal splash windows, in fact I'm recompiling all my apps to exit inmediately after showing them...

Re:load times

[iabervon]

It's not such a big deal for Eclipse, but it matter a whole lot for command-line programs like jar and javadoc, where the amount of time spend running the program is less than the amount of time spend starting the program; this makes correspondingly more of a difference to programs using the traditional UNIX philosophy.

Of course, java tends toward handling this differently, where java programs invoke each other inside the same runtime, but it makes mixing java and non-java tools annoying.

Re:load times

[khuber]

Java was never designed to start up quickly, though they did a lot of work on startup in 1.4.x. Startup time is slow due primarily to what is executed, not the JVM speed.

I wrote a simple JVMPI method tracer. It's mind-blowing what all happens before your code is actually run. Here's a method trace I just ran with 1.4.2 for a simple program.

-Kevin

Modified GCJ Required (for now)

[SilentMajority]

I found this info at http://gcc.gnu.org/java/

"A team of hackers from Red Hat has released RPMS for a version of Eclipse, a free software IDE written in Java, that has been compiled with a modified gcj. You can find more information here. We'll be integrating the required gcj patches into cvs in the near future."

ps

Slashdot preview is buggy today...can't do HTML format preview and links one or more spaces get embedded in URLs (like the one below).

---
My most underrated Slashdot post is http://slashdot.org/comments.pl?sid=68610&cid=6276 748

What is yours?

Another FOSS IDE.

[Black Parrot]

There is another FOSS IDE called gps. They call the unsupported version the "academic edition", but you can download the source, and a peak at a few files shows that it's GPL'd. (Their economic model is to give it away for free and sell support for those who need it.)

It's a cross-platform IDE, with binaries available for Linux, Solaris, and various versions of Windows, and in principle you should be able to build it on any *n*x system where you can get GTK2 to run.

The bad news is that language support is still limited. It has full support for Ada and partial support for C and C++, which are lower priorities for the authors. It comes with instructions for setting up support for your language, but that looks like a non-trivial task.

I've just started playing with it so I can't give a good review, but so far it has been very helpful. The features listed at their Web site are:

• Language-sensitive editor
  
• Automatic generation of body files
  
• Source code reformatting
  
• Intelligent source code navigation
  
• Context-sensitive search and replace
  
• Application builder
  
• Automatic code fixing
  
• Version control (CVS, ClearCase, etc.)
  
• Visual file comparison
  
• Graphical source-level debugger
  
• Project and program entities explorer
  
• Project wizard
  
• Types and program entities graphs
  
• Call graphs
  
• File dependency graphs
  
• Project dependency graphs

You can use the built-in editor or make it pop up your favorite editor. If you use the gnuclient Emacs interface you get the same kind of language-sensitive pop-up menus you get with the built-in editor.

Screenshots are available at the link above.

Plugins?

[connsmythe96]

The eclipse IDE is supposed to be extremely pluggable. How does natively compiling it affect that? Do you have to compile the plugins with the IDE? Or can you still just drop the .class files somewhere?

Re:Plugins?

[Anonymous Coward]

I believe run-time loading works. GCJ also includes a bytecode interpreter, so it will use that (it'll be slower than a normal JVM, but if you know you'll be loading it, you can compile the plugin natively, I think).

That was the case last time I looked at GCJ about a year ago. I ended up being unable to use it because of lack of windowing toolkit support. Anyone know the status on all that?

Re:Plugins?

[Per Bothner]

That was the case last time I looked at GCJ about a year ago. I ended up being unable to use it because of lack of windowing toolkit support. Anyone know the status on all that?

Eclipse uses its own SWT toolkit, which works well under GCJ. SWT is a combination of native code and Java, and is said to both be fast and integrate well with other window systems, as it uses native widgets when available.

The implementation of AWT (including applets) is coming along very quickly, but it isn't complete yet.

Total GCJ performance

[jfengel]

The intriguing idea behind JIT compilers is that the result can be optimized for your exact configuration (AMD vs Intel, particular kinds of RAM, etc.) It can even (conceptually) optimize the same program differently at different times depending on usage. At, of course, a startup penalty and runtime compilation overhead.

I don't know how much of this potential is actually realized in JITs (it's insanely hard to do) and how much of a difference it makes in the end. How substantial would the difference between a specialized AMD vs Intel optimziation be, for example (which would presumably depend on the task)?

I suppose the best possible world would be to have the optimization run exactly once, the first time you install a program. (Yeah, you could conceptually move the same installation to a different CPU, or add more RAM, or some such, but let's not make an already messy issue even messier.)

I doubt such things are easy to benchmark, and the best test may well be something like this (gcj'd Eclipse), where the end result to the user is "which one feels faster?" and "which one actually runs faster?"

Re:Total GCJ performance

[Anonymous Coward]

The intriguing idea behind JIT compilers is that the result can be optimized for your exact configuration (AMD vs Intel, particular kinds of RAM, etc.) It can even (conceptually) optimize the same program differently at different times depending on usage. At, of course, a startup penalty and runtime compilation overhead.

That's not nearly as interesting as using runtime feedback to further optimize code. Static optimizing compilers need to make guesses about things, like how often loops are expected to run and which branches to to be taken more often. I don't expect to see a dramatic difference in Pentium IV vs. Athlon optimizations.

I don't know how much of this potential is actually realized in JITs (it's insanely hard to do) and how much of a difference it makes in the end. How substantial would the difference between a specialized AMD vs Intel optimziation be, for example (which would presumably depend on the task)?

I can tell you that it's not insanely difficult to do. Conceptually, compilers are compilers and optimization isn't that tough to do. JIT is just a tradeoff task, you set hard limits on how long optimizations can take and that changes the set of optimizations you can do. Pretty simple really, if you know how to build an optimizer you can probably build a JIT compiler and then you just tune the sets of optimizations to fit your task, ie run really fast. Bigger problem is we know a ton more about static optimization and compiling than dynamic so there are far more sophisticated static optimizations. We're just now doing things like exploring lowpower optimization, building research compilers to select instruction sequences that result in lower power consumption and stuff like that; I think that people also need to understand that optimization isn't a panacea. There is only so much that you can really expect no amount of optimization is going to make java code perform like C++ code right now, you need to make it take a lot less memory first, make it fit in to caches, etc... the -O20 flag isn't going to do that. Then there is marketing. I wouldn't expect a huge difference between 2 classes of x86 processors, x86 optimization is kind of a joke, there could be dramatic difference on PowerPC and other registery RISCy architectures but 90% of the market runs x86.

Re:Total GCJ performance

[Iffy Bonzoolie]

GCJ, as far as I know, is not a JIT compiler, but a AOT compiler (Ahead of Time) - basically a normal compiler. So there is no greater opporunity to optimise per platform at runtime here. JITs are found tightly integrated in JVM implementations, such as Sun's HotSpot VM.

That's what makes GCJ so interesting: it's a Java compiler that, unlike most other Java compilers, compiles directly to native code without the VM in between. Thus, you potentially lose some of the advantages that the VM can provide you (and I don't know if it restricts language runtime features like dynamic class loading or not) and, in theory, you gain a good deal of performance.

-If

Re:Total GCJ performance

[Anonymous Coward]

The intriguing idea behind JIT compilers is that the result can be optimized for your exact configuration (AMD vs Intel, particular kinds of RAM, etc.) It can even (conceptually) optimize the same program differently at different times depending on usage. At, of course, a startup penalty and runtime compilation overhead.

Oh, but there are a few fallacies associated with that.

The first and bigggest one, a pet peeve of mine, is that people claim that they can reoptimize the application repeatedly on the fly to make it run faster (your It can even (conceptually) optimize the same program differently at different times depending on usage). yes, while this is theoretically possible, the end result will be slower than a normal compilation. Why? Because since you want to check that the usage hasn't changed, you basically have to be running a profiled version all the time. Yes light-weight profiling exists, but it'll be slower than a fairly generic optimized version with no profiling.

Second, You don't need JIT to optimize for your specific setup. Think Gentoo. You can use all of the GCC optimization flags with GCJ and optimize for whatever flavor of processor you have. Of course, that makes hardware upgrades a pain, as you have to recompile everything, but whatever.

Third, I doubt any JIT compilers nowadays do anything different for different processor families, simply to keep complexity down. Heck, I'd be surprised if they used any streaming instructions or anything like that.

Fourth, how much time are you willing to give the JIT compiler to do its thing? With a compile-once system, you can let the compiler crunch on your large a pplication for hours if you want, and then distribute the binary to your clients. That is just not feasible in a JIT context, so the optimizations that can be done are limited (unless you do it in parallel with the app, which introduces profiling (see 1), and adds complexity to the JIT compiler (see 3).

Fifth, the only two situations where you care about speed are
- Batch programs, where theprogram runs continuously and you want it to finish quickly, so you don't want to waste any time on profiling and/or reoptimizing anyway.
- GUI responsiveness, where optimization is not as important as the desing of the GUI toolkit (For some reason every java app I've ever touched seems more sluggish than a similar (or any) windows app).
The third place where speed is important is games, but we're talking java here :-)

Sixth, if you're interested in optimizing towards your personal usage style (which loops will be executed more often depends of which features you use, and how, etc) you still don't need JIT. Look up information on profiled-directed optimization. Basically you build a version of the app with -fprofiler-arcs and use it for a while (it'll be slow) then recompile by feeding those profiles to the compiler (I forget the flag) and voila. The compiler knows the real probabilities of each branch being taken and can optimize accordingly. This works on gcc and g++, but I'm not sure whether gcj can do it yet (last time I tried using -fprofile-arcs with gcj it crashed because internally the profiling code in the back end tried to add a function with a variable parameter list (...), which java doesn't have, so the front end crashed).

There are more objections I had to the whole "JIT is the best ever" mentality, but this rant has grown too long, and I forgot the rest already.

(oh, yeah. Seventh, every program has bugs, and some only show up under certain very specific circumstances (using system.identityHashCode() will make the program depend on the memory layout to the point that some bugs will appear only some times. also race conditions and resource leaks). If you have a different version of your executables, you will hve bugs appearing only under certain configurations of processor, memory, etc. and dissapear suddently as the program reoptimizes, which makes it hell to track down or even come up w

Re:Total GCJ performance

[CustomDesigned]

IBM's AS/400 JVM does exactly this. Java byte code is compiled the first time it is run and optimized for the exact processor and OS version. The binary is managed transparently by the JVM and updated when the bytecode changes. On AS400, this is all integrated with the filesystem (i.e., you can't screw it up by touching with a funny date).

You get all the advantages of Native compilation, and system specific JIT compilation combined - at the expense of more complexity and lots more disk space.

As others have mentioned, M$ is attempting to do a similar thing with .NET. Whether they can do as good a job without charging AS/400 prices remains to be seen.

As wonderful as all this is, I still like direct bytecode execution because it minimizes memory use and startup - which is more important than CPU for many applications (business logic and embedded). Native compiled code is quite a bit bigger than bytecode, uses more memory, and takes longer to load (though not as long as JITing the bytecode).

Re:Total GCJ performance

[psykocrime]

Okay, off topic, but are they *any* downsides to AS400s?

Probably the biggest downside is that OS/400 simply isn't particularly user friendly. Leaving aside for a moment the existence of Client Access, OS/400 is completely command line and/or menu driven. Everything is "green screens" and dumb terminals (or terminal emulators running on a PC ). There really isn't any GUI, except the "psuedo-GUI" you get by running Client Access on a PC.

I spent about 4 years working primarily with AS/400's, and I can say from experience that OS/400 just feels kinda clunky compared to *Nix or even Windoze.

In theory, I suppose none of that matters for servers, though. I think maybe the reason they aren't used as servers more, is really a marketing thing. AS/400's were traditionally positioned as being mainly for running financial apps / ERP software / accounting / etc. And while they can act as general purpose file / web / app servers, they just weren't ever marketed as being primarily for that.

Also, keep in mind that, to some degree, the different platforms IBM puts out compete with each other. There is always internal politics within IBM, debating whether or not the AS/400 is cannabilizing sales from the RS/6000, and whether the RS/6000 is cannibalizing sales from the S/390 or AS/400, etc, blah, blah. That can lead to confusing marketing message from IBM to the world, about the intended use of each platform.

Re:Troll...Troll...Troll...

[gumpish]

And [Java] continues to be hyped, and is being used less and less, as the speed continues to hamper it.

Java is still some 40 times faster than Python. As hardware speed continues to obey Moore's law, performance per clock cycle becomes less important. (For many areas of computing anyway.)

Microsoft's IDEs? You have GOT to be kidding

[MichaelCrawford]

Using Microsoft's IDEs - I have VC++ both 6 and 7 - is like pounding nails with my fists.

Have you used Metrowerks Codewarrior? Now there's an IDE. It's a joy to use. Runs on Mac and Windows. I think there is a Linux version that uses gcc, but I haven't tried it.

(I admit I haven't tried Eclipse yet, but I would be very surprised if it were better than CodeWarrior.)

Everything Just Works in CodeWarrior. I've even got my wife, a web designer who prefers to hand-code her HTML, to use it to write her web pages.

CodeWarrior supports C, C++, Java and inline assembly. If you prefer makefiles, there are command line tools that provide the same compiler. Old versions of CodeWarrior also supported Pascal, but I don't think they do anymore.

The ISO compliance of CodeWarrior's C++ is far superior to Visual C++'s, and has been quite compliant for a very long time. I've been happily using the Standard Template Library in very complex ways, as well as writing my own fancy templates, for several years.

Alexei Alexandrescu used CodeWarrior to develop the heavily templated source code for Modern C++ Design. Visual C++ can't compile it because of its poor compliance to the standard.

It is also available for many embedded systems. Metrowerks was acquired by Motorola a while back, who makes the ColdFire and PowerPC processors that are important in the embedded world.

Good for QNX

[Animats]

This will be useful for QNX, for which Java support is weak.

Isn't that how .NET languages like C# work?

[MichaelCrawford]

My understanding (I may be wrong) is that the way that Microsoft's "managed code" works is that the installer creates a native compile of your application on your computer right when it installs.

I don't know how well it works but I can see the potential.

Re:Isn't that how .NET languages like C# work?

[Coward the Anonymous]

"I think .NET is just in time compiled, similar to Java."

.NET is JITed by default. But the SDK comes ngen.exe, a tool that will create a native image. You can setup an installer to compile the MSIL to native code on install also.

"If what you said is true, we wouldn't be able to copy an executeable from one computer to another. It would have to be installed."

The native image is cached, it doesn't overwrite the .exe that of MSIL that someone gives you. So if someone has "installed" an app and it was compiled on install, you could still use the .exe. The runtime would recompile the code for your machine.

obligatory pun

[1nv4d3r]

Thanks to the expected slashdotting, this is just one more eclipse I can't look directly at.

Re:Looks great!

[Timesprout]

I was actually talking about VS.NET :-). I agree its a huge improvement over its predecessor, especially when it comes to larger projects. VS was almost unusable on the last VC++ project I worked on if the whole workspace was loaded. Both IntelliJ and Eclipse offer far more in terms of editor power and ease of refactoring code than VS.NET though.

Unfortunately one of the reasons IntelliJ has got more expensive is because of its success. Its about 100$ more expensive now than when I purchased it. If you are doing a lot of Java development and dont have a compelling requirement for a GUI builder then I strongly recommend IntelliJ.

Re:Looks great!

[Anonymous Coward]

Top four reasons VC++ is better than any open source IDE:

1) Lead developer has a cool name, like "Anders Heljborg".

2) Lead developer earns a cool salary, like $1,000,000+ a year.

3) Lead developer has legion of microsoft's code monkeys implementing and testing features out the yang, and they still can't burn up all the money they extort from, err, i mean charge, their customers.

4) Anders Heljsborg rewite and maintainence has been going on for four or five years. Give eclipse a chance to ketchup.

Optimizing JITs are very common

[Anonymous Coward]

> The intriguing idea behind JIT compilers is that the result
> can be optimized for your exact configuration (AMD vs
> Intel, particular kinds of RAM, etc.) It can even
> (conceptually) optimize the same program differently at
> different times depending on usage. At, of course, a
> startup penalty and runtime compilation overhead.

True, the optimization for hardware platforms are less significant than the overall optimizations.

> I don't know how much of this potential is actually
> realized in JITs (it's insanely hard to do) and how much of
> a difference it makes in the end. How substantial would
> the difference between a specialized AMD vs Intel
> optimziation be, for example (which would presumably
> depend on the task)?

Its huge, Java is already faster than C++ is some benchmarks (very slightly) but the problem is that this feature doesn't benchmark well.
Technically optimizing JIT's aren't all that hard to write since this subject is far from new and has been studied in smalltalk for ages (IBM was strong in smalltalk and Sun just hired everyone else).

As an example these two opimizations are a part of both the Sun and IBM JDKs:

1. Virtual method inlining - where a call to a virtual method can be made inline since at runtime we know for sure the instance we perform invocations upon.

2. Runtime loop unroling - loop unroling is mostly useless in C++ since you need to know the size of the iteration in advance. Even if it never changes.

In Java there are many language restrictions (no pointer arithmetics, bound arrays etc...) that allow the JIT to assume things that a C++ compiler can't assume. Java has in that sense the potential to be much faster then Fortran and simpler than C/C++.

> I suppose the best possible world would be to have the
> optimization run exactly once, the first time you install a
> program. (Yeah, you could conceptually move the same
> installation to a different CPU, or add more RAM, or some
> such, but let's not make an already messy issue even
> messier.)

This level of opimization produces some but relatively little benefit. You can do this with open source applications written in C, the advantage in JIT is allowing the application to be profiled according to your specific use case and adapted to it. After all we only use 10% of a programs functionality. When a programmer profiles a C/C++ application he only profiles the way he used it not the way his user will.

Re:You sir are a troll....

[millenium]

Why is it that people like to abuse Moore's law as a lame excuse for lousy engineering?

Re:Annoyed with the post

[roystgnr]

But seriously, would it kill the poster to include the tiny little fact that gcj stands for "Gnu Compiler for Java?"

Probably not. Nor would it have kill him to explain that a compiler turns source code into a binary executable for a particular architecture, or that IDE stands for Integrated Development Environment, or that a JVM is a Java Virtual Machine, or that RPM stands for Redhat Package Manager, or that GTK+ stands for GIMP ToolKit, or that now it is now used for far more than just GIMP, or that GIMP stands for GNU Image Manipulation Program, or that the included acronym stands for Gnu's Not Unix, or that GNU is a project to write free implementations of operating system components derived around the POSIX model, or that POSIX is a collection of operating system standards based around tradional Unix interfaces.

Doing all of these at once, however, would probably piss everyone off. Explaining just the particular missing piece of information that a specific reader is going to need would be better, but would require Slashdot readers to be more homogenous and Slashdot posters to be more psychic than they are.

The compromise, wherein the word "gcj" is linked to a web page entitled "The GNU compiler for Java", seems to be hard to improve upon.

Branch prediction and OO languages

[Earlybird]

• On modern processors, the performance of a program is affected greatly by the success of the branch-prediction system, which gets hints from the compiler.

There's an interesting claim I have seen made: Apparently the late binding feature of object-oriented languages -- virtual methods in C++, any non-static method in Java -- works against branch prediction, effectively resetting the prediction state whenever such a call is made, because the target jump address must be resolved -- read from a memory location -- only at the time of the jump. If this claim is accurate, this means typical OO code is inherently slower to execute than non-OO code on modern processors. Of course, the problem will equally apply to any language that supports function pointers, and in particular to C programs "emulating" OO with structs and function-pointer tables.

Couple of hits, couple of misses.

[0x0d0a]

Because of the size and footprint issues, you can't do embedded with Java

Well...no. I believe that embedded environments are a rather stripped down form of Java, but Java isn't all that uncommon in embedded systems. Take a look at Javacard -- you'd use it in environments where you typically have less than 64KB of memory.

That being said, I *still* think Java is a terrible language for most people to be using. There's something to the argument that there's "not much better out there".

Problem: C sucks for general application development. A lot of people know it really well, but the whole point of C is that you get a lot of control over exactly what's going on [Disclaimer: I like C, and use it for my application development. :-)].
Problem: C++ is a *huge* language. I thought I knew it once, after a while using it, and then bought Stroustrop's book, and discovered all sorts of things, like autopointers, that I'd never heard of. C++ has a lot of syntactic overhead.
Problem: C# is made by Microsoft.
Problem: Pascal has vanished into obscurity.
Problem: Perl/Python/Ruby aren't as fast as their traditionally compiled equivalents.
Problem: Nobody uses eiffel.
Problem: Nobody wants to use functional languages, so ocaml and friends are out of the question.

So Java gets used.

I'm firmly of the opinion that Java has a good use -- distributed development.

The problem is that Java was built to make Sun (a hardware company whose primary claim to fame is easy "scalability" by buying higher end machines or more machines) money. Sun's big problem is that most people don't use their SPARC architecture. Java works for Sun by doing two very simple things. It's hideously resource-intensive, from a CPU and memory standpoint. It also is an easy language to easily speed up by throwing more machines into the mix. It doesn't make life a pain if you're using x86 clients with a SPARC server, like rpc can.

Oh, and finally, it has a lot of sexy features to draw people in. It's also a bit easier to learn and work with than C++.

So despite the fact that Java is incredibly slow and RAM-hungry, people bill it as the next big language, the replacement for C++. Frankly, I think Java should stay precisely where its strengths are -- it makes a hella nice language for doing distributed work (especially if you have a client with a front end), and lightweight networking. It's a lousy general purpose language, though.

Emperor has no clothes

[Latent Heat]

A genuine troll is where a person puts out a post for the purpose of the controversy it generates. There are a few of us out there who are genuinely confused by Eclipse, and if the Slashdot community wants to dismiss us as trolls, morons, or other unworthies of the programming fraternity, I guess the Eclipse people can have their own little private society. It also seems that Eclipse proponents on Slashdot are a bit thin-skinned regarding any criticism of their beloved product.

Just getting a program to run under Eclipse is a major undertaking. Visual Studio has a "project file" that identifies the void main() (or Java or C# equivalent) for you, so if somebody gives you a VS project as a bundle, you simply load the project file and build and run. I think there is something going on with Eclipse that not only to you have to put files into the project manager, you have to identify the source module containing the program entry point for Run to be able to do something, and it is confusing because Run has a lot of options that a person keeps trying out, but the problem was back in the project manager.

I am sure that once you get the hang of how to use Eclipse it is the Swiss Army Knife of software development, but Eclipse is different, and the state of the examples, docs, and help files is such that it is going to turn away of people who try it out for a casual inspection. So be it. If Eclipse gains mindshare, those of us on the fringes will buckle down and try to learn it, and if Eclipse fades into the background, we will kind of know why it had failed.

Re:Microsoft's IDEs? You have GOT to be kidding

[WhoDaresWins]

Using Microsoft's IDEs - I have VC++ both 6 and 7 - is like pounding nails with my fists. Have you used Metrowerks Codewarrior? Now there's an IDE. It's a joy to use.

While IDEs can be quite a personal preference thing, you don't quite mention anything specifically about what is so good about the Metrowerks IDE other than it being cross platform and easy to author web pages in(!). I mean come on neither of those are core IDE functionality. I would have given you more credit if you had any pointed things to say about how the Metrowerks IDE is better but as it stands now you aren't very convincing.

If you prefer makefiles, there are command line tools that provide the same compiler.

Huh? This is not a big deal. Almost every compiler in the world can do this including VC++.

Visual C++ can't compile it because of its poor compliance to the standard.

Its quite obvious that you haven't tried VC++ 7.1 (Visual Studio.Net 2003). Its has close to 95% plus ISO C++ compliance. The only major feature missing is "export" which has now been almost officially labelled as a misfeature by the C++ gurus on the standards comittee and no major compiler will implement it. You mentioned having VC++ 6 and 7 and yet you being totally unaware of the fact the most VC++ programmers were long aware that VC++ 7.1 would have close to full compliance, leads me to think that you aren't much a VC++ user and perhaps only use it because you have to.

Why JVM?

[be-fan]

I never really understood the whole point of the JVM. Why load this big program at every application launch? JIT still has more overhead than AOT compilation, in the real world, and most importantly, the huge memory footprint of the VM wreaks havoc on your caches.

What's the purpose of the JVM?

Dynamicity? No. Java is a aggressively static language. Meanwhile, highly dynamic languages like Lisp, Dylan, and Scheme (among others) can be efficiently compiled to native code.

Speed? While in theory a JIT can be faster, its not the case in practice. In the "Great Computer Language Shootout" (which isn't bad, as far as these things go) Java has an average CPU rank of 14, behind other static languages like C, C++, Ocaml, and SML, and behind dynamic languages like Scheme and CL as well! In reality, Java can only get within 90% of the speed of C for inner-loop numeric-type stuff (which lends itself to JIT optimization).

Flexibility? Java is highly inflexible. Its almost as as inflexible as C. It requires you to manually specify pretty much everything. You even have to do manual boxing/unboxing! Java is so highly structured, it should be compilable to native code that hits 90% the speed of C, without a very smart optimizer at all.

Safety? Given Java's lack of pointer types, it shouldn't need a JVM monitoring it to be safe. Again, there are lots of safe languages (Haskell, Clean, and the aforementioned dynamic languages) that don't require a runtime monitor.

Actually, I don't see much of a point in Java at all. Its got statically typed, but can't use that advantage to be as fast as C++. It runs in a VM, but can't use that advantage to be as dynamic as Python. Its syntax isn't any easier to use than something like Dylan (kinda like Lisp with a Pascal syntax) or Python. It doesn't have the development environment advantages of Smalltalk. Heck, its not even a very good compromise language ---- Dylan is as easy, often faster, and more powerful, Python is much easier (and thanks to Psyco) often as fast, C++ is much more powerful, as well as much faster, etc.

Re:Why JVM?

[the eric conspiracy]

Dynamicity? No. Java is a aggressively static language.

Static types perhaps, but very dynamic when it comes to linking. Java has a lot of support for things like dynamic class loaders that lead to a very nice plug-in architecture, and extreme flexibility when it comes to deployment of code updates to a running application. Not to mention fun with diddling bytecodes on the fly.

Re:Why JVM?

[be-fan]

I hate you slashdot. Now, let's try this with the code samples in place?

I don't think 'Dynamicity' is a word. But hey, enlighten me?
>>>>>>>>
It's not a word. But I'm referring to how dynamic the language is. In Java, dynamic method invocation is very limited --- just basic single argument polymorphism. Other languages have much greater dynamic capabilities: For example, in Dylan (chosen because its syntax is easier for most people to follow), I can do the following:

let vec = make(<vector>, size: 100);
// ...fill vector...
for(i from 0 below 100)
do-foo(vec[i]);
end;

Now, this will go through the vector, and call the appropriate version of do-foo for each time in the vector. The cool thing is that it doesn't matter what the types in the vector are, or how they're related. If they have a do-foo() defined for their class, the runtime will do the right thing automatically. In Java, to get the same effect, you'd have to use check to type of each variable, cast it to the right type, then call do-foo() for each type that could be in the vector.

Nup, not even. See 'instanceof' - which, although considered hackish among OOP elites, gives volumes compared to using void pointers in C. Then there's the whole polymorphism thing, but hey - C is procedural.
>>>>>>>>>
I said "almost" as inflexible as C. Certainly, its not any more flexible than C++. But either way, its not what I mean by flexible. Now, let's continue the previous example. The last Dylan example would run rather slowly, about at the speed the "giant switch on types" Java version would run. Now, if you don't need to store multiple types in the same vector, you can simply use a limited type. Just change one line to:

let vec = make(limited(<vector>, of: <integer>));

Now, as long as there is a do-foo() method defined for integers, the compiler will automatically specialize <vector> (think templates in C++) for the type, detect it can now statically dispatch the do-foo() method (because the argument will always be an <integer>) and most likely inline the do-foo() method into the loop. As a result, the loop will benchmark within spitting distance of C++ using the vector<int> template.

Someone correct me if I'm wrong, but AFAIK the JVM acts as a sandbox for Java applications/applets, stopping those which don't have the necessary permissions for privileged operations. This adds volumes to safety.
>>>>>>>>>
It only needs to do security checks because it is a platform as well as a language. In a natively compiled language, those security checks would be handled by the underlying OS. The main thing the underlying OS can't do is memory checking, which is why the JVM does bounds checks and whatnot. But compiler technology has advanced so far that you don't need something like the JVM to look at each memory access before allowing or disallowing it. Lots of safe languages (again, Lisp, Dylan, even C in the case of the SAFEcode project) are compiled to native code, with the compiler emiting only a few bounds checks here and there.

You also forgot the biggie: portability. C and C++ are portable to a degree, but require recompilation.
>>>>>>>
Lots of languages are natively compiled and fully portable at the same time. The requirement for portability isn't running on a JVM, but preventing platform-specific pointer manipulation, as well as specifying sizes for various objects. Again, there are lots of other languages that do this! Heck, even C++ is pretty good at this, as long as you avoid "implementation specific" operations (which are clearly marked as such). The only reason that Java seems more portable is the giant standard class library. You can get largely the same result by using Qt and some well chosen libraries like ACE.

If you want speed, get Linux and gcj it (never actually tried gcj trolls - sue me if it sucks

Re:Why JVM?

[Bodrius]

If you're looking for the strengths of Java, I think you should ask what was Java created for in the first place?

If I understand the myth/history correctly, it was made to run arbitrary code from an arbitrary source in an arbitrary environment, in a safe manner.

Sun needed something to load up additional code within a program which the original programmer didn't know anything about, get it from somewhere in the network at runtime, then run it in anything from a toaster to a cable-box to a PC to a cell-phone to a refrigerator.

And then somehow control the risk in that situation.

Dynamicity? Depends on what you mean with that word. Java is very strict about its static typing. When people talk about Java being "dynamic", I think they usually talk about dynamic class-loading.

Speed? I don't think speed has ever been a case for Java, except in the web-development community where it competes with Perl and PHP, and even then it lags behind other features.

Flexibility? Once more, it's not about the type-system. It's about loading arbitrary code into your application server without shutting it down, or worrying too much that the code will crash your system. It's about then taking that code and running it somewhere else, in other hardware, without making any changes.

Safety? The JVM is not there to check you're not messing up your pointers. It's there to check your bytecode is valid, has permission to do what it's supposed to do, and doesn't mess with anything it shouldn't.

It's there so that class you downloaded from an unknown source in Ukraine doesn't steal your credit info and reformats your hard drive because hey, it doesn't have permissions to do so!

Java is a language for a hostile (network) environment, where your code cannot trust other code any more than it has to. The main role of the JVM is not to be a portable interpreter for a friendly programmer language, it's to be a protective paranoid Big Brother for a bureaucratic programming language.

Re:Why JVM?

[khuber]

Java has a set of tradeoffs just like any other language. In particular it's reasonably fast, has decent libraries, and has static type checking and a syntax familiar to developers used to procedural languages.

Of course it's not The Ultimate Computer Language, but it's good enough for a lot of applications. OCaml, SML, Haskell, Clean, Dylan, and Scheme are largely academic/research languages with little real world use because their programming models are too hard to deal with, among other reasons.

Smalltalk is one of my favorite languages, and I admire its offshoot Self, but it was in the wrong place at the wrong time, was too expensive, and has problems with nonstandard libraries. Python is nice, but slow, and has an uneven library. C++ is a syntax nightmare. I don't know what to think about Dylan, I still think of it in its prefix form.

I'm sure you understand that programming languages don't gain widespread use due to their theoretical elegance, or Cobol must be brilliant and ML must lack expressive power. I often call Java the Cobol of the 21st century, because I think that is a good analogy for its place in software development.

Please Read Parent!!!

[0x0d0a]

It is extremely important that *all* developers read the parent post. This IDE may have the most groundshaking features *ever*!

Let's take a look:

Automatic generation of body files

Hot *damn*! It writes my code for me!

Source code reformatting

Then it reformats it to fit whatever standard I need!

Automatic code fixing

Then it *debugs* the code!

Application builder

Finally, it *builds* the program I'm working on!

All this, from a piece of software that the ignorant layman might consider no more than a wrapper for an editor and a compiler.

Truly, a groundbreaking achievement. :-)

load times *do* matter in the real world (tm)

[mccrew]

Do people sit there and start and exit applications continuously?

For those who start up their IDE in the morning and close it down in the evening (or at the end of the week, whatever), then long startup times are just a minor cost of doing business.

For someone like me, however, who is ambivalent about this IDE or that IDE, and whose fingers are too hard-wired for one particular editor to use the brain-damaged editors foisted by most IDEs, startup time IS a big issue. When you are going in and out of tools all day long, it becomes a major annoyance to have to wait for the darned thing to start up.

Re:load times *do* matter in the real world (tm)

[ChannelX]

I still dont get why you need to restart Eclipse to go into another editor. Run them both at the same time. IIRC the Eclipse editor will detect the new file changes.

GCJ performance is a myth. Benchmarks inside.

[lokedhs]

In general, GCJ compiled code is slower than the smae code running in the JVM. The only speed advantage comes from the startup times.

Often the JVM will out-perform GCJ with a factor of 3. Check out the numbers on this page.

I fail to see why people want to run a GCJ compiled evrsion of a development tool and run at at one third of the speed of the JVM, just in order to save a few seconds of startup time.

Re:GCJ performance is a myth. Benchmarks inside.

[Tom7]

I checked out the numbers, but GCJ seems to be just barely edged out by Hotspot in most cases. Considering that GCJ is free and allows you to distribute native binaries, that's pretty good.

They don't have figures for memory usage, installation profile, etc., and I bet in those areas GCJ beats Hotspot for end-users. And you can't beat an install with no library dependencies.

Re:GCJ performance is a myth. Benchmarks inside.

[lokedhs]

Because pretty much the main drawback of Java is that it severly limits which platforms you can distribute to, ironically.

Let's assume for a second that you are correct, and Java limits the platforms you can distribute to. Tell me again exactly how GCJ improves on that?

The only other option is distributing a 50 meg JVM with every app

The JRE is 13 MB last I looked. And you only have to download it once and it works for all your Java apps. Most Java applications are offered in a package both with and without a JRE. For example DbVisualizer (I wholeheartly recommend this database tool, very good and supports pretty much all databases) and IntelliJ IDEA (the best development environment ever).

and increasing support costs by having to walk people through tedious installation procedures, for the JVM and your app.

The apps I showed as examples are one-click installable. Most others are too. Your statement was completely wrong and should have had a huge FUD warning sign all over it.

If you can compile a native binary, you can distribute it to any binary compatible platform, regardless of what other software they have installed.

GCJ requires the GCJ runtime libs last I messed with it. Exactly how is this different from installing JRE?

You don't have to explain CLASSPATH to your users.

Read the documentation on the Java site. Use of the CLASSPATH environment variable has been stringly discouraged ever since the 1.2 days. I hardly ever use it myself, although it's nice to have if I need it (mainly when developing and trying out different libraries).

You don't have to explain why they can't type "java filename.class", but instead must type "java filename".

I have a better solution: Just double-click on the app! Yes, can you believe it? Ever since 1.2 there has been support for executable JAR's. When you install Windows .jar files are automatically associated with the Java runtime so that you can double-clik on the app to start it. If you have the stupid "hide extensions" feature enabled it looks just a normal app. I believe MacOSX does the same (although I haven't tried). Enabling the same in Nautilus is just a couple of mouse clicks away. From the command like you do have to type "java -jar the_application.jar".

GCJ is the only hope Java has of actually being more than an acedemic curiosity, and "something that Sun used for a few apps".

Maybe you should leave the academic environment for a while and realise that Java is heavily used for developing very real and existing applications in Java. Also check out the statistic on programming language usage with PostgreSQL. I'm not so sure I should believe your asstertion that Java isn't used oustide of academic institutions.

Are you even aware of the number of web sites exist whose server code is completely written in Java? Most likely you visitied a couple before you came here today.

Re:GCJ performance is a myth. Benchmarks inside.

[DavidNWelton]

(1) "Because pretty much the main drawback of Java is that it severly limits which platforms you can distribute to, ironically."

(2) "Let's assume for a second that you are correct, and Java limits the platforms you can distribute to. Tell me again exactly how GCJ improves on that?"

Because GCJ runs on all the platforms gcc does, which is pretty much everything out there. Java officially doesn't run on all kinds of platforms. Linux is only supported on x86 and ppc, IIRC, not to mention the various BSD's...

Also, GCJ is free software, so that means that it if there's the will, people can and will port it.

Re:Memory Usage vs Eclipse Running in JVM

[thimo]

A quick test (using an Eclipse 2.1.1 from eclipse.org):

Eclipse 2.1.1 with JVM
- Second start: 13 seconds
- Memory Eclipse: 80 MB
- Memory JVM: 65 MB

Eclipse 2.0.1 without JVM
- Second start: 9 seconds
- Memory: 96 MB

The download page seems to indicate you're downloading an Eclipse 2.1.0 version, but the about dialog says 2.0.1. Which one is it?

Cheers,

Thimo (back to coding in Eclipse 2.1.1 :)

Re:GCJ slower than IBM JDK

[__Reason__]

I could show you plenty of examples of benchmarks that run significantly faster with GCJ than on the IBM JDK. Its true that there are still some occasions where GCJ will run slower - due to bottlenecks in the runtime or missed optimizations in the compiler. But if you have a simple application that runs significantly slower with GCJ, please write to java@gcc.gnu.org and tell us about it. We can't fix performance problems we don't know about.

Fast. Was:Startup sure, but how fast does it run?

[atgreen]

Eclipse contains a java compiler which you can also compile as a standalone app with with gcj (see http://sources.redhat.com/rhug). The gcj-compiled compiler is almost three times faster than the latest IBM JRE run version.

BitTorrent url

[PourYourselfSomeTea]

Get your torrent here

Umm... no

[iamacat]

You can have a JVM that can save JIT output to the executable format for a given platform. Like GCJ :-) Then, after a bootstrap, the JVM can be in fact written in Java.

jit is not a slowdown...

[Kynde]

Just so you all know. A good jit/hotspot compiler can make things quite a bit faster than any static build compiler. This is because at runtime certain optimizations are possible that simply cannot be done at build. These optimizations are typically very aggressive, to that extent that later on in execution it may turn out so that those snippets have to be thrown away and recompiled. And thus they usually target only the hotspots, i.e. portions of code that are being executed inside tight loops, which is usually where compile time savings occur anyway. The speed of the rest of the code is pretty much governed by the programmer anyway along with his choice of algorithms and data structures.

A good example of such snippets would be the inlining of a virtual method, turning a virtual method recursion into a loop along with some unrolling, inlining function pointer call (which is basically the same as virtual method call).

Mind you, ofcourse a hotspot compiler could also be implemented to a C/C++ runtime environments, but I haven't heard of anyone actually taking that path.

(for the record, I'm a C programmer and rarerly write much with java)