Currently Sun can't release some pieces
Currently Sun can't release some pieces
Posted Nov 16, 2006 16:18 UTC (Thu) by dwheeler (guest, #1216)Parent article: Some notes on free Java
The FAQ on Sun's release of Java notes that there are some 3rd-party software components that Sun can't release; these affect 2D graphics in particular. If that can't be worked out, then pieces of Classpath will be needed to fill in Sun's own Java implementation.
That said, it's a lot easier to fill in small pieces, given that there's another implementation with a compatible license, than to implement the entire Java class library. In the end there will be at least one FLOSS Java class library (and likely two) and at least two FLOSS Java implementations (gjc for speed, and Sun's for broad functionality). This is really great!
I think we'll see at least a small uptick in Java usage because of this. The real question is whether there will be a large uptick. It's definitely possible; Java has been held back for years due to Sun's inept licensing policies, and though they've lost many years, perhaps they'll manage to regain it.
Posted Nov 16, 2006 17:57 UTC (Thu)
by mikov (guest, #33179)
[Link] (6 responses)
Posted Nov 16, 2006 21:13 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (5 responses)
Posted Nov 16, 2006 21:24 UTC (Thu)
by PaulMcKenney (✭ supporter ✭, #9624)
[Link] (2 responses)
Posted Nov 18, 2006 13:07 UTC (Sat)
by job (guest, #670)
[Link] (1 responses)
To be fair, a native compiler could use dynamic optimizing techniques as well. It's just that they're not mature enough yet.
Posted Nov 18, 2006 18:10 UTC (Sat)
by mikov (guest, #33179)
[Link]
Hate to burst your bubble, but a static compiler cannot make dynamic
optimizations. Perhaps only in some trivial cases, with the cost of
extreme code duplication.
The notion that a JIT can universally outperform a static compiler for
languages like C or Fortran is certainly hype. However it is _not_ hype
for Java. In all my tests HotSpot and IBM's JVM outperform GCJ for typical
Java code with a significant margin - often 2x.
Note that typical Java code has lots of allocations, lots of pointer
chasing, lots of non-reducible virtual method calls, etc. Look at this
completely trivial Java code:
It is completely unoptimizable statically. The difference between a
Java-oriented JIT and GCJ will be overwhelmingly in favor of the JIT.
Posted Nov 16, 2006 21:35 UTC (Thu)
by mikov (guest, #33179)
[Link] (1 responses)
Posted Nov 23, 2006 13:03 UTC (Thu)
by irios (guest, #19838)
[Link]
But then I thought that the 3X acceleration was obtained simply by choosing Sun's jvm to execute *the same Eclipse code*, so it has downed on me that I must have never run Eclipse compiled to native with gcj, but *interpreted* java code ran with the gcj interpreter, which nobody in his right mind has said is fast.
Are you sure that you have tried *native* Eclipse?
I am nitpicking really. You mentioned that gcj is useful for speed. In Currently Sun can't release some pieces
fact gcj compiled code is slower than code running under Sun
JVM. Due to the nature of the Java language, I suspect that a static
compiler can never outrun a HotSpot-like JIT.
It has to be said though that Java applications compiled with gcj start a
lot faster, have less dependencies, have much more predictable execution
speed and are much easier to integrate with C. So, gcj will remain very
useful, only not for the speed of the code it produces.
Why should code "compiled" with a good JIT JVM run inherently faster than a code built with a good optimized static compiler that had much more time for various optimizations?Currently Sun can't release some pieces
Because the JIT can take dynamic conditions into account, producing code that is optimal for the specific workload in question -- and regenerating the code if the workload should change, even during a single run of the program.How JITs can outperform static compilation
That's the hype, anyway. I've never seen it actually run faster, except in rigged benchmarks.How JITs can outperform static compilation
How JITs can outperform static compilation
int sum ( Collection<Integer> c )
{
int res = 0;
for ( Integer x : c ) res += x;
return res;
}
This is a complicated question and I don't remember all the details, but Currently Sun can't release some pieces
basically the very nature of Java doesn't allow good static optimization.
For example too many method calls are virtual and the exact object type
cannot be deduced at compile time. A JIT, on the other hand, can
conditionally inline a virtual method, it can generate several specialized
versions of the code, etc. When you inline a method, many optimizations
cascade from that.
Recently it is becoming increasingly popular in Java to generate
executable code at runtime. It is a very powerful technique. A static
compiler can't deal with it well without incorporating a JIT in its
runtime library.
Lastly, even though GCC has a decent backend, in my tests Eclipse compiled
with GCJ is too slow to be usable (well, at least on an Athlon XP 2000).
GCJ has still has room for improvement though. I am not sure whether they
have already implemented Java-specific optimizations like removing
redundant range checks, moving interface lookups out of loops, etc. That
should give it a nice boost. More improvement can come from heavy
profile-guided-optimization and whole-program-optimization, but it is a
very complicated area (and whole-program-optimization isn't really
possible for Java anyway).
I was also going to point out that, in my Ubuntu installation, Eclipse launches more than three times slower with gcj than with Sun Java, and then it feels a lot *more* sluggish.Currently Sun can't release some pieces