harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hind <hi...@us.ibm.com>
Subject Re: [arch] JIT interfaces
Date Sat, 27 Aug 2005 14:07:40 GMT
Steve Liao wrote:

> I was just wondering if a unified format (more than a unified interface)
> makes sense for Harmony. One advantage is to allow GC to enumerate
> without relying on JIT. Any other benefit?

Of course, both ways could work.

At a high level, the stack maps are a data structure created by the JIT 
compiler and used by the GC.  Following OO-design principles, the code 
that interprets the maps should be associated with the data structure 
itself.  Thus, it really isn't part of the JIT or the VM. 
Your question asks should there be one such type of data structure or 
should we allow different types for each compiler, if desired.

Although "one type fits all" seems more attractive (less code in the 
system), I think we have to be careful about not imposing design decisions 
on the JIT.  For example, in Jikes RVM the approach that the 
non-optimizing (i.e., "baseline") and optimizing compilers take to finding 
the stack maps are very different.  The optimizing compiler does a live 
analysis on all reference types, and thus, has a (potentially) different 
stack map for GC point in a method. 

On the other hand, the baseline compiler does not perform any real 
register allocation, so it can get away with a much simpler stack map data 

Therefore, at least in this design space, it is advantageous not to 
require the uniform data structure on all compilers.

> In this scheme, JIT records the compiler
> version (baseline or optimizing) and at runtime if a stack map is
> needed by GC, the same version is invoked to recompile the method and
> recover the stack map. 

Although this could work, one needs to be careful because when a GC is 
invoked space is typically scarce, and thus, performing an arbitrary 
compile (to get the stack map) may be problematic.  I believe this becomes 
more obvious in a Java-in-Java approach (the compiler and application 
share the same heap), but one could argue it is also an issue in a 
non-Java implemented VM, as memory is really just memory, whether it is 
given to the Java heap or the C runtime.


View raw message