Stewart Stremler wrote:
At one of the early presentations, there was talk about only compiling
code on the *second* invocation -- I don't know if this is what they
finally went with. I should probably go read up on it one of these
days.
Actually, it's more like a continuum. In server mode, they generally
interpret on the first N invocations, where N isn't really a fixed value
but rather a decision point based on profiling data. So, if small bit
set of byte codes represents a large amount of processor time, it
becomes disproportionately likely to be JIT'd. It goes further than that
too, as particular performance hotspots become eligible for
recompilation using more and more aggressive optimizations (including
really crazy stuff like inlining of virtual functions and making
assumptions about exceptions never being thrown, with a fallback code
path where the bytecodes are effectively reevaluated in the event of an
exception).
Does gcj handle reflection yet? I've not kept up with it -- but that
would produce a binary quite a bit different than that produced with
C or C++ compilers.
Yes it supports reflection and yes that is why gcj comes with a distinct
runtime library (libgcj).
So, what this shows, as was stated before in this thread, is that the
language is a specification, and the runtime environment is typically an
implementation detail.
The runtime is still specified. It's not merely an implementation
detail. :)
It is an implementation detail from the perspective of the language
design and definition. It isn't from the perspective of an application,
component, or tool builder.
What, "JVM" and "Java Language" wasn't enough of a distinction? How
should they have done it?
Java and .NET have both suffered from overly broad branding. It would
have been helpful to use a byte-code format and runtime brand that is
independent of the language. The reality is that JVM bytecodes really
only relate to Java language along the most primitive assumptions (and
some of those ought to be dropped). It might even have helped make the
JVM better (it is nice that Microsoft at least has a name for VM that is
independent of their language "CLR = Command Language Runtime", which
makes no reference to C# or .NET... unfortunately they also often use
.NET in a context that effectively means CLR). If you don't think the
Java brand has been spread too thin, perhaps you can tell me what "Java
compatible" might mean? Does it mean something that works with the Java
language? The Java VM? Java's RMI interface? JNI?
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
