harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [DRLVM] adding write barriers to Jitrino.JET
Date Wed, 31 May 2006 11:39:33 GMT
On 5/31/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> DRLVM contains a simple JIT called Jitrino.JET in addition to a highly
> optimizing JIT.  The simple JIT seems to be a better choice for
> starting the write barrier work.
> Looking at Jitrino.JET sources, it looks like the best place to add
> write barriers is in cg_ia32.cpp: Compiler::gen_st() {.......}   Does
> this seem right?

No, this method is used to store operand stack item to local variable.  If
you're interested in writing to fields then Compiler::gen_field_op is the
right place. We can generate a call to VM or GC helper in this method. To
create a call to any VM helper (which may throw Exception or force GC) you
should use Compiler::gen_call_vm() method.

Also, I have looked for documentation on Jitrino.JET but have not been
> able to locate it.

The brief overview of Jitrino.JET features is in DRL VM Developers Guide.
For more detailed information you can generate Doxygen documentation.  To
generate Doxygen documentation for Jitrino.JET browse to vm/jitrino/src/jet
folder and run 'doxygen -g', 'doxygen Doxyfile' commands.

 It would be nice see some graphic documentation on
> how the compiler spill/fills between the stack and registers.  And
> also how the compiler deals with the live ranges of reference
> variables.

Jitrino.JET is designed to be a pretty simple baseline compiler.  It does
not perform optimizations or data/control flow analysis. Operands do not
live across call sites on registers. i.e. Jitrino.JET spills into memory
every operand before a call. The live range of operand is exactly the same
as in bytecode, so even if object reference will never be used again, but
occupies a local variable or stack slot in Java bytecode, Jitrino.JET will
report it to GC during enumeration.

In specific how root set enumeration works.  While not
> absolutely essential for hacking in write barriers, it will help a
> bunch during the debug stage.

Root set enumeration works as follows:  Jitrino.JET emulates Java
stack/locals and has reserved areas in stack frame (see
Jitrino::Jet::StackFrame class) to map bytecode locals and stack slots. For
every GC enumeration point JET maintains two masks: "GC map for locals" and
"GC map for stack" which define which variables and which stack slots must
be reported to GC. Both masks are saved to StackFrame in runtime right
before GCenumeration point, but calculated separately. Locals mask is always
calculated in
runtime: every store operation changes a bit in mask. Stack operands mask is
calculated during compilation and
is a constant for every GC enumeration point.

It seems not to be a problem to implement WB support in Jitrino.JET, let's
discuss requirements and design.
How will it affect VM or GC ? The WBs will also require support from both VM
and GC. Do you have ideas on VM/GC interface for this?
Also what will be usage and testing scenarios in the nearest future?

Mikhail Fursov
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message