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][JET] write barrier for Java (mmtk)
Date Tue, 10 Oct 2006 18:27:47 GMT
Weldon,
I thought about slightly different approach.
Why not to write fast-path VM helper like was proposed in the thread
"[drlvm]Extending..."
This helper (a static method) can be inlined by JIT without any
devirtualization and call any method needed from MMTk or native
implementation. So JIT won't know if it works with MMTk or with a native GC:
all you need is just to replace the Java version of the helper.
?

On 10/11/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
>
> I am just now getting back to the MMTk port.
>
>
> Looking at MMTk code base, I see that during bootup MMTk creates an
> org.mmtk.vm.VM object.  The VM object contains a static field that holds
> an
> instance of Barriers.  It is called org.mmtk.vm.VM.barriers.
>
>
>
> The complete VM declaration is:
>
>
>
>   public static final Barriers barriers;
>
>
>
> And, of course, the instance method performWriteInBarrier() can be
> devirtualized by an optimizing JIT.  There is no need to improve the
> performance of the write barrier in JET.  Thus there is no need to change
> the existing MMTk interface.
>
>
>
> I can create something like
>
>
>
> class MMTkInitization {
>
>   static org.mmtk.vm.VM   vmBoot;
>
>
>
>   void init() {
>
>       vmBoot = new org.mmtk.vm.VM();
>
> }
>
>
>
> The JIT would use reflection to find vmBoot field and then find
> performWriteInBarrier() entry point.
>
>
>
> Another approach would be to add a new API to JIT/VM interface that would
> return the entry point performWriteInBarrier().  Its certainly not as
> clean
> and maintainable since its an ugly "devirtualization" hack that will break
> if MMTk even wants to subclass Barriers.java
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>


-- 
Mikhail Fursov

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