Having RTFA, I need to state the the guy does sound reasonable in this affair... from which we learn: never trust Slashdot headlines to convey the content of a link...
About the issue in question: Sun hasn't had the best trackrecord of making their goals and motifs known... and despite the fact that they have donated considerable amounts of source code (OpenOffice, NFS, Netbeans, var. Java projects,...) they're still seen as big evil company. This thing about their patents will hopefully soon be cleared up by some of the PR over at Sun.
Hmm... maybe he's pissed because the OpenSolaris name is so unspecific... it should be: BSD/OpenSolaris (because the tools and toolchain came from there) No... wait... didn't Sun move to SysV... so it should be called: SysV/OpenSolaris No wait... didn't Sun also port lots of GNU tools to Solaris... hm... I suppose this only leaves us with: GNU/OpenSolaris. Now... if Sun would only get rid of their on compiler and go with only GCC and if it would dump all of it's IDEs (Sun Studio, Netbeans,...) and would ship only with Emacs (sorry: GNU Emacs)... then we'd have a happy, smiling RMS again. No wait... RMS is never happy nor does he smile... so we'll probably just have an RMS who is yelling at something else again...
> I've heard the book is reason enough never to
> bother with a Crichton novel ever again.
Oh... you've heard that, did you? That's good then, that you've heard that. You know what else I heard? There's this guy who sells the Brooklyn Bridge, it seems like he needs money badly and he'll sell it to you for 20 $ and a FiletOFish... that's what I heard...
On a serious note: I actually bothered to read the book, and I found it very interesting. About the style: if it wasn't a Chrichton novel, I'd discard it as political propaganda against the idea of global warming...
But it *is* a Chrichton novel, which means it's very well researched, and comes with a page long bibliography. He also, in the course of the story, reminds you that scientists are humans too, that computer simulations are *simulations* and they do not show the truth but the result of a long series of calculations. If you think that's nitpicking, you might keep in mind that there are loads of computers out there, that do nothing but churn through meteorological data and they try to predict the weather; In case you didn't know: they are rarely accurate in the very short term, and they certainly don't work for any period longer than a couple of days. It's also mentioned that, for instance, phenomena like El Nino cannot be predicted by computers (yet?). Now see that result of the slashdot story again: do you really believe that these calculations or predictions spanning *decades* or *centuries* can be more correct?
If you read the book with an open mind (which means: you don't *immediately* discard anthing that goes against the global warming theory), you're likely to be reminded of a couple of things about science that you should always keep in mind. Like the fact that scientific models are just models, and everything calculated with them, are only approximations (in the very best case). The fact that the Newton Model of Gravity works rather well, and that Einsteins GR works even better, doesn't mean that climate models work just as well.
That should be rephrased as "I, jeif1k, think, that 'open' means...". The term "open" means something else to everyone, there's no specific definition. The JVM and Java lang spec are open for people to read, and to implement. People have done so for years (I mentioned the JVMs, and there are countless extensions of the Java language, like AspectJ, GJ,...). BTW, C# as an ECMA standard is nice, but a language is useless without it's libs, and those aren't in the ECMA standard.
>They guarantee that Microsoft can't play the kinds >of legal games that Sun has been playing with the >Java specification
What legal games? MS licensed the "Java" platform from Sun, which involved a number of rules. They broke one of the rules (they published a "Java" version that wasn't compatible with the compatibility test suite, ie. they left out RMI and JNI). Sun sued to preserve the compatibility of the "Java" platform (ie. if it's called "Java", it's supposed to contain a full "Java" implementation; MS failed to comply, and got sued). If you agree to a contract, and then break on of the items in that contract, you'll be sued, it's as simple as that.
>Yes, and that has achieved exactly what it should: >creating a choice of a large variety of compilers >from many different vendors.
Yes, the choice for many vendors to lock in their customers by providing an incompatible C++ version. BTW, there are several implementations of Java compilers, just as there are implemenations of Java JVMs (IBM, Bea,...), so customers have a choice even without any offical standard. Oh... and customers can be certain about something: if it says "Java" on the box, it actually contains "Java", Suns legal department make sure they can rely on that.
The point about taste: well, it's a matter of me growing tired of this discussion, having witnessed too many language wars already. I wish you success with developing C# (or whatever you earn money with), and I will continue earning my dough with Java development.
PS: on the Java Grande people: they are mostly complaining about some details in Javas IEEE754 FP handling, and maybe some other things too (I read their presentations years ago, can't remember; they probably want Complex,... types as well). Anyway, they're one group of users; there are many other folks out there, who also have specific wishes for the Java platform. They want pointers, direct memory access, access to hardware ports, operator overloading, real closures, real continuations, C++ like templates, more libraries in the Java package, less libraries in the Java package, better Swing, no Swing, SWT, everything but SWT, binary compatibility, ignore binary compatibility,........ Sun, or the JVM and language designers choose what Java looks like, and they have to consider, but also ignore many of these requests (you might have noticed that some are contradictive). If the Java they create is not right for you: don't use it. Right Tool for the Right problem.
OK... and now, and a good night to you (at least it's night here).
OK... let's say this: I like Javas design, you like C# design; it's futile to discuss taste issues, so I won't.
You're wrong about Javas openness. The JVM spec is open: http://java.sun.com/docs/books/vmspec/2nd-e dition/ html/VMSpecTOC.doc.html The Java language spec is open as well: http://java.sun.com/docs/books/jls/second_e dition/ html/jTOC.doc.html Yes, I agree, they don't have a big "ECMA" or "ISO" badge, but well... since when were those worth a penny. C++ has been ISO certified for years or decades, but try finding a ISO compliant C++ compiler (Visual C++, gcc,... aren't, and on purpose; they don't implement the "export" keyword). So... how potent is the ISO C++ standard now? Anyone can claim to implement it, but no one cares whether that's actually true.
About Open Source Implementations... well, you've read the benchmark article; you've seen that a large part of the VMs in there were Open Source versions (Kaffe, Jikes RVM, gcj (yeah, not a VM),...). Jikes RVM actually had pretty good results, considering it is only a research VM, that is actually written in Java. And for extensive libraries: Sun bundles libraries for just about anything. For everything else, you get a huge amount of open source libraries. Yes, the Open Source implementations have one problem: they can't use Suns Standard Library classes because of license matters. But, well, Mono has the same problem. And like Mono, Java also has people re-implementing the standard libs, and they are continously getting closer to being complete (GNU CLASSPATH project).
> Yes, the Sun Java implementation is more mature >than.NET and Mono, we know that. What's your > point?
My point? You complained about Sun (claiming that Sun claims to have GC options, but that they have implementation problems).
>The semantics of value classes are supposed to be >different. Giving everything reference semantics >would be the wrong thing to do even if the >compiler managed to perform every possible >optimization.
And what would the advantage of that be? Having only one way of accessing data is simpler. Having to decide (in C or C++) between Stack or Heap allocation takes up time and the difference can introduce subtle bugs.
>There was no reason to create such a poor >implementation back then; generational GCs, >incremental GCs, dynamic compilation, and most of >the other features used in Sun's JDK were already >well-known at the time. Sun simply didn't use >them.
Er... so... Suns implementation, dynamic compilers, GC options were known, when.NET came out. Why does a huge company with huge research resources create such a poor implementation of the CLR? Mind you, Sun starting out with an interpreter had other reasons (Javas bytecode *can* be interpreted, thus making it easy to create JVMs even for constrained environments, which can be seen in the Java enabled phones, which cannot use JITs due to limited memory; this also allows hardware acceleration through ARMs Jazelle, for instance..NET always has to JIT, it's IL has been designed for that, and their designers actually try to sell this as an advantage.). BTW the initial Java team was tiny, compared to the resources available to MS, and at the time it was developed, no one knew that it would grow into the success it is today, so no one was too prepared to throw resources at it. MS, on the other hand, has been telling people for the past 4 years, that it bets the farm on.NET...
@GCs: Great statement... so, what actually hasn't been impressive?.NET still only has only the Generational GC, without any options for large heaps or support for SMP. Mono actually uses the Boehm GC, which is conservative, thus doesn't have the benefits of Generational GCs (cheap allocation, no cost for deallocating dead objects), and might actually leak memory (a common property of conservative GCs, as they basically guess which integers are pointers and which are not; don't know if the Mono guys did anything about that).
@ObjectOverhead: HotSpot, the Sun JVM, has had 8 byte object headers for years (at least since version 1.3).
@EscapeAnalysis: Which system has this? (Besides any kind of research projects).
On value types: I prefer Suns approach..NET/C# value types make the language semantics more difficult; Sun has made the right decision to keep the reference-type-only system. Value types on.NET still have to be Boxed/Unboxed if they are to be accessible by reference (for every Value type, an equivalent Reference type is created at compile time, to facilitate this). The only advantage of Value types comes in when having huge arrays of them, where the 8 byte overhead could cause problems. There's research for having more packed object headers, or for ways to even get rid of them (allocation in special pools,...). All of this can be implemented without adding special semantics, and this are areas for future JVMs. Sure... it's not available today, but 10 years back, Java was a simple bytecode interpreter with a mark-sweep GC.
>When Java came out, garbage collection already was >a mature field (Java's GC is still not >state-of-the-art).
WTF? Sun JVMs have had state of the art GCs for years. Actually, there's not just one GC, but a lot of them in the JVM. The default version is a Generational GC. You can choose options like incrementality (to avoid GC pauses, or at least to minimize them). You can choose a Parallel GC (which exploits several CPUs for marking and collections). There is a GC option for large heaps (Scavenger algorithm). In 5.0 they also added GC ergonomics, where you can specify certain constraints (ie. max pause time,...) and the GC auto-tunes itself to reach those goals (if they are feasible, otherwise they're approximated).
Now... I don't know about you, but that's state of the art for me. Sure, there's a lot of research into alternative GC algorithms, but they don't really offer huge improvements. The only thing that remains is stuff like Escape Analysis, which supposedly will make it into the next Java version (in short: this will improve the speed of very short lived object by using a stack to allocate them, without cluttering the young generation space).
Depends on what you want to do with it; if you can manage to have the whole code statically compiled (with no dynamic class loading), that would not be a problem.
Here's the link to the LinuxJournal text talking about getting gcj to compile Eclipse:
http://www.linuxjournal.com/article.php?sid=7413.h tml
Maybe that can help you with your decision.
So... instead of RTFM you ask here?
Oh sorry... I forgot, this is Slashdot.
They aren't seconds, they are some kind of score on the respective benchmarks, the higher the score the better;
The big advantage of VMs and dynamic compilers is that they can take advantage of the CPU that they are running on. Ie. if you use gcj to compile software, you have to compile optimize it for a specific CPU (instruction order is important and makes a difference, as different OutOfOrder engines on different CPUs (think Intel vs. AMD) act differently). It also means more complicated deployment, for instance: if your code uses SSE2, your program only runs on Pentium4 and other CPUs that have SSE2. If you don't want that, you have to factor out the functions that make use of SSE2 and provide replacements that don't use it (which also means having to check the CPU at startup and choosing the libs appropiately). This doesn't matter for a compiler working at runtime, as it knows about the capabilities of the CPU and just uses them if possible (I know that the JVM uses SSE when available, though I haven't found out what exactly it is used for). A JIT/DynamicCompiler also knows everything about your CPU, for instance Cache sizes,... and can exploit that knowledge to further optimize the code or data layout.
Also: you have to keep in mind, that Java (like.NET) is a dynamic environment, ie. you can load classes at runtime. This proves to be a bit of a problem with static compilation, or I should say: with optimization. Hotspot (Suns Dynamic Compiler or VM and also other JVMs) do some optimizations that improve OOP code, like devirtualization (which removes the vtable lookup overhead for virtual method calls) and even virtual method inlining. Now: these optimizations have one problem: they may be accurate when the code is generated... but what happens when a new class is loaded? For instance, the compiler devirtualizes a method in class A, because Class Hierarchy Analysis tells him, that this method is never overridden. So... 10 minutes later, a class is loaded, that is derived from class A, and overrides the aforementioned method... so... the code is suddenly incorrect. In this case, the dynamic compiler, takes back the old optimization, and everything is OK again. This kind of scenario makes it necessary for many optimizations to have a system (compiler) working at runtime.
Mind you: Runtime code loading or generation is a point where gcj gets really slow, because then it has to run that code with gij (the interpreter). There are people that got Eclipse compiled with gcj, but they ran into that problem too (the Plugins in Eclipse are loaded at runtime; they worked around that by compiling the plugins as shared libraries).
Sigh... for the last time: Java code executed with Sun or IBM JVMs is not interpreted, but compiled to native and heavily optimized code.
Before anybody complains: yes, the Sun VM uses mixed-mode execution, which means that code is interpreted first until it has been used for a certain amount of times, then it's compiled. It might seem like a contradiction, but that's mostly a performance improvement (turning byte code into native code with optimizations costs time... often more time than it would take to simply interpret the code; not to mention the memory overhead of creating native code for every one-off method). IBMs VMs always JIT compile their code, but they have different levels of JIT Compilers; the first time code is used, a baseline compiler simply transforms byte code into native code. If that code is heavily used, it is optimized and the old code is replaced with the faster version.
Again: No Bytecode interpretation, Dynamic compilation!
Next week: Why Java != JavaScript
Slashdot Mirror
Having RTFA, I need to state the the guy does sound reasonable in this affair... from which we learn: never trust Slashdot headlines to convey the content of a link...
About the issue in question: Sun hasn't had the best trackrecord of making their goals and motifs known... and despite the fact that they have donated considerable amounts of source code (OpenOffice, NFS, Netbeans, var. Java projects,...) they're still seen as big evil company.
This thing about their patents will hopefully soon be cleared up by some of the PR over at Sun.
Hmm... maybe he's pissed because the OpenSolaris name is so unspecific... it should be: ... so it should be called: ... then we'd have a happy, smiling RMS again.
BSD/OpenSolaris (because the tools and toolchain came from there)
No... wait... didn't Sun move to SysV
SysV/OpenSolaris
No wait... didn't Sun also port lots of GNU tools to Solaris... hm... I suppose this only leaves us with:
GNU/OpenSolaris.
Now... if Sun would only get rid of their on compiler and go with only GCC and if it would dump all of it's IDEs (Sun Studio, Netbeans,...) and would ship only with Emacs (sorry: GNU Emacs)
No wait... RMS is never happy nor does he smile... so we'll probably just have an RMS who is yelling at something else again...
Oh well...
> I've heard the book is reason enough never to > bother with a Crichton novel ever again. Oh... you've heard that, did you? That's good then, that you've heard that. You know what else I heard? There's this guy who sells the Brooklyn Bridge, it seems like he needs money badly and he'll sell it to you for 20 $ and a FiletOFish... that's what I heard... On a serious note: I actually bothered to read the book, and I found it very interesting. About the style: if it wasn't a Chrichton novel, I'd discard it as political propaganda against the idea of global warming... But it *is* a Chrichton novel, which means it's very well researched, and comes with a page long bibliography. He also, in the course of the story, reminds you that scientists are humans too, that computer simulations are *simulations* and they do not show the truth but the result of a long series of calculations. If you think that's nitpicking, you might keep in mind that there are loads of computers out there, that do nothing but churn through meteorological data and they try to predict the weather; In case you didn't know: they are rarely accurate in the very short term, and they certainly don't work for any period longer than a couple of days. It's also mentioned that, for instance, phenomena like El Nino cannot be predicted by computers (yet?). Now see that result of the slashdot story again: do you really believe that these calculations or predictions spanning *decades* or *centuries* can be more correct? If you read the book with an open mind (which means: you don't *immediately* discard anthing that goes against the global warming theory), you're likely to be reminded of a couple of things about science that you should always keep in mind. Like the fact that scientific models are just models, and everything calculated with them, are only approximations (in the very best case). The fact that the Newton Model of Gravity works rather well, and that Einsteins GR works even better, doesn't mean that climate models work just as well.
OK... I refute this articles rather silly ideas in this blog entry: http://jroller.com/page/murphee/20050113#xml_futur e_of_source_files
> "Open" means
...). BTW, C# as an ECMA standard is nice, but a language is useless without it's libs, and those aren't in the ECMA standard.
That should be rephrased as "I, jeif1k, think, that 'open' means...". The term "open" means something else to everyone, there's no specific definition. The JVM and Java lang spec are open for people to read, and to implement. People have done so for years (I mentioned the JVMs, and there are countless extensions of the Java language, like AspectJ, GJ,
>They guarantee that Microsoft can't play the kinds
>of legal games that Sun has been playing with the
>Java specification
What legal games? MS licensed the "Java" platform from Sun, which involved a number of rules. They broke one of the rules (they published a "Java" version that wasn't compatible with the compatibility test suite, ie. they left out RMI and JNI). Sun sued to preserve the compatibility of the "Java" platform (ie. if it's called "Java", it's supposed to contain a full "Java" implementation; MS failed to comply, and got sued). If you agree to a contract, and then break on of the items in that contract, you'll be sued, it's as simple as that.
>Yes, and that has achieved exactly what it should:
>creating a choice of a large variety of compilers
>from many different vendors.
Yes, the choice for many vendors to lock in their customers by providing an incompatible C++ version.
BTW, there are several implementations of Java compilers, just as there are implemenations of Java JVMs (IBM, Bea,...), so customers have a choice even without any offical standard. Oh... and customers can be certain about something: if it says "Java" on the box, it actually contains "Java", Suns legal department make sure they can rely on that.
The point about taste: well, it's a matter of me growing tired of this discussion, having witnessed too many language wars already. I wish you success with developing C# (or whatever you earn money with), and I will continue earning my dough with Java development.
PS: on the Java Grande people: they are mostly complaining about some details in Javas IEEE754 FP handling, and maybe some other things too (I read their presentations years ago, can't remember; they probably want Complex,... types as well). Anyway, they're one group of users; there are many other folks out there, who also have specific wishes for the Java platform. They want pointers, direct memory access, access to hardware ports, operator overloading, real closures, real continuations, C++ like templates, more libraries in the Java package, less libraries in the Java package, better Swing, no Swing, SWT, everything but SWT, binary compatibility, ignore binary compatibility,........
Sun, or the JVM and language designers choose what Java looks like, and they have to consider, but also ignore many of these requests (you might have noticed that some are contradictive). If the Java they create is not right for you: don't use it. Right Tool for the Right problem.
OK... and now, and a good night to you (at least it's night here).
OK... let's say this: I like Javas design, you like C# design; it's futile to discuss taste issues, so I won't.
e dition/ html/VMSpecTOC.doc.htmle dition/ html/jTOC.doc.html
,...). Jikes RVM actually had pretty good results, considering it is only a research VM, that is actually written in Java.
You're wrong about Javas openness. The JVM spec is open:
http://java.sun.com/docs/books/vmspec/2nd-
The Java language spec is open as well:
http://java.sun.com/docs/books/jls/second_
Yes, I agree, they don't have a big "ECMA" or "ISO" badge, but well... since when were those worth a penny. C++ has been ISO certified for years or decades, but try finding a ISO compliant C++ compiler (Visual C++, gcc,... aren't, and on purpose; they don't implement the "export" keyword). So... how potent is the ISO C++ standard now? Anyone can claim to implement it, but no one cares whether that's actually true.
About Open Source Implementations... well, you've read the benchmark article; you've seen that a large part of the VMs in there were Open Source versions (Kaffe, Jikes RVM, gcj (yeah, not a VM)
And for extensive libraries: Sun bundles libraries for just about anything. For everything else, you get a huge amount of open source libraries.
Yes, the Open Source implementations have one problem: they can't use Suns Standard Library classes because of license matters. But, well, Mono has the same problem. And like Mono, Java also has people re-implementing the standard libs, and they are continously getting closer to being complete (GNU CLASSPATH project).
> Yes, the Sun Java implementation is more mature .NET and Mono, we know that. What's your
.NET came out. Why does a huge company with huge research resources create such a poor implementation of the CLR? Mind you, Sun starting out with an interpreter had other reasons (Javas bytecode *can* be interpreted, thus making it easy to create JVMs even for constrained environments, which can be seen in the Java enabled phones, which cannot use JITs due to limited memory; this also allows hardware acceleration through ARMs Jazelle, for instance. .NET always has to JIT, it's IL has been designed for that, and their designers actually try to sell this as an advantage.). BTW the initial Java team was tiny, compared to the resources available to MS, and at the time it was developed, no one knew that it would grow into the success it is today, so no one was too prepared to throw resources at it. .NET...
>than
> point?
My point? You complained about Sun (claiming that Sun claims to have GC options, but that they have implementation problems).
>The semantics of value classes are supposed to be
>different. Giving everything reference semantics
>would be the wrong thing to do even if the
>compiler managed to perform every possible
>optimization.
And what would the advantage of that be? Having only one way of accessing data is simpler. Having to decide (in C or C++) between Stack or Heap allocation takes up time and the difference can introduce subtle bugs.
>There was no reason to create such a poor
>implementation back then; generational GCs,
>incremental GCs, dynamic compilation, and most of
>the other features used in Sun's JDK were already
>well-known at the time. Sun simply didn't use
>them.
Er... so... Suns implementation, dynamic compilers, GC options were known, when
MS, on the other hand, has been telling people for the past 4 years, that it bets the farm on
@GCs: .NET still only has only the Generational GC, without any options for large heaps or support for SMP. Mono actually uses the Boehm GC, which is conservative, thus doesn't have the benefits of Generational GCs (cheap allocation, no cost for deallocating dead objects), and might actually leak memory (a common property of conservative GCs, as they basically guess which integers are pointers and which are not; don't know if the Mono guys did anything about that).
.NET/C# value types make the language semantics more difficult; Sun has made the right decision to keep the reference-type-only system. Value types on .NET still have to be Boxed/Unboxed if they are to be accessible by reference (for every Value type, an equivalent Reference type is created at compile time, to facilitate this). The only advantage of Value types comes in when having huge arrays of them, where the 8 byte overhead could cause problems. There's research for having more packed object headers, or for ways to even get rid of them (allocation in special pools,...). All of this can be implemented without adding special semantics, and this are areas for future JVMs. Sure... it's not available today, but 10 years back, Java was a simple bytecode interpreter with a mark-sweep GC.
Great statement... so, what actually hasn't been impressive?
@ObjectOverhead:
HotSpot, the Sun JVM, has had 8 byte object headers for years (at least since version 1.3).
@EscapeAnalysis:
Which system has this? (Besides any kind of research projects).
On value types: I prefer Suns approach.
>When Java came out, garbage collection already was
>a mature field (Java's GC is still not
>state-of-the-art).
WTF? Sun JVMs have had state of the art GCs for years. Actually, there's not just one GC, but a lot of them in the JVM. The default version is a Generational GC. You can choose options like incrementality (to avoid GC pauses, or at least to minimize them). You can choose a Parallel GC (which exploits several CPUs for marking and collections).
There is a GC option for large heaps (Scavenger algorithm).
In 5.0 they also added GC ergonomics, where you can specify certain constraints (ie. max pause time,...) and the GC auto-tunes itself to reach those goals (if they are feasible, otherwise they're approximated).
Now... I don't know about you, but that's state of the art for me. Sure, there's a lot of research into alternative GC algorithms, but they don't really offer huge improvements. The only thing that remains is stuff like Escape Analysis, which supposedly will make it into the next Java version (in short: this will improve the speed of very short lived object by using a stack to allocate them, without cluttering the young generation space).
Depends on what you want to do with it; if you can manage to have the whole code statically compiled (with no dynamic class loading), that would not be a problem.h tml
Maybe that can help you with your decision.
Here's the link to the LinuxJournal text talking about getting gcj to compile Eclipse: http://www.linuxjournal.com/article.php?sid=7413.
So... instead of RTFM you ask here? Oh sorry... I forgot, this is Slashdot. They aren't seconds, they are some kind of score on the respective benchmarks, the higher the score the better;
The big advantage of VMs and dynamic compilers is that they can take advantage of the CPU that they are running on. Ie. if you use gcj to compile software, you have to compile optimize it for a specific CPU (instruction order is important and makes a difference, as different OutOfOrder engines on different CPUs (think Intel vs. AMD) act differently). It also means more complicated deployment, for instance: if your code uses SSE2, your program only runs on Pentium4 and other CPUs that have SSE2. If you don't want that, you have to factor out the functions that make use of SSE2 and provide replacements that don't use it (which also means having to check the CPU at startup and choosing the libs appropiately).
.NET) is a dynamic environment, ie. you can load classes at runtime. This proves to be a bit of a problem with static compilation, or I should say: with optimization. Hotspot (Suns Dynamic Compiler or VM and also other JVMs) do some optimizations that improve OOP code, like devirtualization (which removes the vtable lookup overhead for virtual method calls) and even virtual method inlining.
This doesn't matter for a compiler working at runtime, as it knows about the capabilities of the CPU and just uses them if possible (I know that the JVM uses SSE when available, though I haven't found out what exactly it is used for).
A JIT/DynamicCompiler also knows everything about your CPU, for instance Cache sizes,... and can exploit that knowledge to further optimize the code or data layout.
Also: you have to keep in mind, that Java (like
Now: these optimizations have one problem: they may be accurate when the code is generated... but what happens when a new class is loaded? For instance, the compiler devirtualizes a method in class A, because Class Hierarchy Analysis tells him, that this method is never overridden. So... 10 minutes later, a class is loaded, that is derived from class A, and overrides the aforementioned method... so... the code is suddenly incorrect. In this case, the dynamic compiler, takes back the old optimization, and everything is OK again.
This kind of scenario makes it necessary for many optimizations to have a system (compiler) working at runtime.
Mind you: Runtime code loading or generation is a point where gcj gets really slow, because then it has to run that code with gij (the interpreter). There are people that got Eclipse compiled with gcj, but they ran into that problem too (the Plugins in Eclipse are loaded at runtime; they worked around that by compiling the plugins as shared libraries).
Sigh... for the last time: Java code executed with Sun or IBM JVMs is not interpreted, but compiled to native and heavily optimized code. Before anybody complains: yes, the Sun VM uses mixed-mode execution, which means that code is interpreted first until it has been used for a certain amount of times, then it's compiled. It might seem like a contradiction, but that's mostly a performance improvement (turning byte code into native code with optimizations costs time... often more time than it would take to simply interpret the code; not to mention the memory overhead of creating native code for every one-off method). IBMs VMs always JIT compile their code, but they have different levels of JIT Compilers; the first time code is used, a baseline compiler simply transforms byte code into native code. If that code is heavily used, it is optimized and the old code is replaced with the faster version. Again: No Bytecode interpretation, Dynamic compilation! Next week: Why Java != JavaScript