On 5/31/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 5/31/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > 2006/5/31, Mikhail Fursov <[EMAIL PROTECTED]>: > >> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
