harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Goetz <br...@quiotix.com>
Subject Re: I hope the JVM implements most using Java itself
Date Wed, 11 May 2005 15:43:30 GMT
> Imagine your execution engine (or whatever you call it) makes the
> assumption that object references are direct and don't change, for
> the naturally desirable reason that it wants to be fast. Then along
> comes somebody who says, "Hey, I want to implement a copying GC!"
> Oops, then what?

Copying is only one of many garbage collection approaches that involves 
relocating objects.  So does mark-compact, and most of the interesting 
concurrent and parallel algorithms.

I think you mean "relocating" GC.  (By the way, not all relocating GC's 
today involve an extra level of indirection, so the performance hit to 
the execution engine is not necessarily what you think it is.)

> This code can be agressively optimized (including inlining, array bounds
> check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being
> a perfect example. Not to mention the application itself. After all,
> who only runs an application once? You can WAT compile the application
> and then all of your code (except for anything loaded & run dynamically
> at runtime) will run fast.

This argument neglects many of the benefits of JITs.  First of all, you 
can't inline virtual method calls effectively (at which point, you can 
basically forget about optimizing) unless you know every class that is 
going to be loaded, which you never do.

Modern JITs can make aggressive assumptions about inlining based on 
current information and back them out if the information is later 
invalidated (say, by another class being loaded.)  Such speculative 
optimizations are very effective.

JITs can also make better optimization decisions based on profiling data 
gathered during interpretation.  This is the JVM equivalent of branch 
prediction -- by the time the code is compiled, the JVM has a lot of 
information such as "how often is this branch taken" (which can be used 
to make inlining space-vs-speed tradeoffs) and "how often is this lock 
contended" (which can be used to make decisions about whether or not to 
even try thin-locking.)  And the list goes on and on.

View raw message