harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Shih-wei Liao <lia...@gmail.com>
Subject Re: [arch] JIT interfaces
Date Fri, 26 Aug 2005 15:34:32 GMT
On 8/23/05, Michael Hind <hindm@us.ibm.com> wrote:
> Steve Liao wrote:
> 
> > I would like to find out how other Harmony developers want to solve
> > some basic JIT/VM interfacing.  One area is stack maps for precise
> > enumeration of live object references.
> 
> > Does anyone know how other open source JVMs do the above?
> 
> Jikes RVM's compilers (baseline & optimizing) produce machine code and
> metadata about the compiled method, which includes stack maps.  The
> compilers create the maps, which are associated with a runtime version of
> the method.   When a GC occurs, the GC stackwalker checks each stack frame
> to see who compiled it, and then asks the appropriate compiler auxiliary
> code to enumerate the references in that stack frame.  This is done by
> repeatedly calling this auxiliary code until it returns a sentinel
> signally "no more references".
> 
> I think this worked pretty well.
> 
> Mike
> 

Yes, currently we also let the compiler control the "interpretation"
of GC maps and enumerate the references. We also employ a unified
interface from GC to different JITs ("baseline & optimizing" in your
case) for this enumeration task. In our case, this worked well too. 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?

Another design point is to rely on compiler even more: Reducing the
storage in VM and asking the compiler to "interpret" more. Let me call
this scheme "lazy generation of stack maps." I think it's a trade-off
between space and time. 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. This is trading time for space and may be
useful for handhelds if memory footprint is an issue. Do you know of
any open source JVM that implements this?

I think the PLDI'1999 paper "Support for Garbage Collection at Every
Instruction in a Java Compiler" from the ORP team pushes this lazy
generation to the extreme. In the paper VM can recover the stack maps
at many more instruction points by asking JIT to recompile to those
points.
  Steve Liao, Intel

Mime
View raw message