Re: [DRLVM] adding write barriers to Jitrino.JET

[Weldon Washburn <we...@gmail.com>]

On 5/31/06, Rana Dasgupta <rd...@gmail.com> wrote:
> On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> >
> > 2006/5/31, Mikhail Fursov <mi...@gmail.com>:
> > >> 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.
> >
> > >FYI: Write barrier GC implementation doesn't throw exceptions or
> > >starts garbage collection. The whole idea of write barriers is to make
> > >them as lightweight as possible.
I don't care about how lightweight the write barrier at this stage of
development.  See below.
>
>
>  gen_call_vm() is  more heavyweight( as Ivan explains above ), but that's
> why the  higher level goals of this feature development would be good to
> know. Prototyping in .Jet cannot really have a performance focus.
Correct.  Performance is a non-goal for the initial bring up on .JET.
My thinking is that once .JET/MMTK is "bullet proof", we worry about
bringing up the optimizing JIT.  Meanwhile the bullet proof .JET is
not modified so that we can use it to chase write barrier bugs in the
optimizing compiler.  Once the optimizing compiler is stable and the
lightweight WB's are inlined, the third stage is to go back and
performance profile .JET.  Use this perf info as a guide to fix .JET
write barrier performance problems.
>  Weldon, would it be right to call this a proof of concept, to be later
> redone in the .OPT jit when necessary?
Instead of "proof of concept", I would use the term, "initial bring up".
>
> >> 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?
I am reading the MMTK source code now.  I should have comments on
mix/matching MMTK interface and OPEN and DRLVM GC interface(s) soon.

> > > >Also what will be usage and testing scenarios in the nearest future?
Probably the best option is to test write barriers using MMTK.  The
existing GC in DRLVM (gcv4) is probably going to be too hard to work
with.  Also, writing a GC from scratch is a possibility but I would
rather go with an existing, known to work GC (mmtk or some other
battle tested 3rd party open source GC).
> >
> > >The VM<>GC interfaces is already exists in DRLVM. The only interface
> > >is missing: JIT->VM helper.

Yes.  I am aware of this interface.  I need to look at harmony-438
sources to see if it has changed since I last worked on this interface
back when I posted ORP to sourceforge in 2000.  If memory serves me
correct, ORP contains GCV3 which is an incremental moving collector.
And write barriers were working just fine.

>
>
>  Not sure that I understood what you said here...are you saying that the
> VM_GC interface has (stubbed out) barriers related entries( eg.,
> gc_requires_barrier()/gc_write_barrier()), but the JIT->VM Helper runtime
> support interface does not have the necessary barrier helper entries in this
> code version?
I don't want to inline write barrier code in Jitrino.JET during this
startup stage.  It needs to call a runtime helper function.  If the
function is missing, it needs to be added to the runtime helper table.
>
>  It may be worth considering if we want JET to just call the barrier
> functionality( with from/to/and slot locations )and the barrier helper
> actually do everything ... including generating the store. May be
> unconventional, but more modular.
I really want to take the lazy way out.  If it is easier to leave the
store code as it is, then that's what will be done.  If it is easier
to clump the WB code and the java store code together, then do that
instead.
>
> Thanks,
> Rana
>
>
>
>
>
>
>
> --
> > Ivan
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org