You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ming Wu <wu...@gmail.com> on 2006/06/20 04:30:53 UTC

A GC module written in Java for DRLVM

We have developed a Java GC with mark-sweep algorithm and integrated it into
the current drlvm code. The key feature is, the GC is not prebuilt into
binary, but loaded and jitted by the VM at runtime. Hopefully it is useful
to the existing efforts porting MMTk to DRLVM. It is actually the rewrite of
gc_mf of drlvm in Java language. It can run some simple Java applications,
but there is some issue with the build environment (different from what we
developed the GC with) that prevents us from running it with reasonable size
Java application. We tried to minimize the change to DRLVM existing code.

We have submitted the Java GC and patch file for VM to
JIRA(HARMONY-622<http://issues.apache.org/jira/browse/HARMONY-622>).
To run it, one should specify the classpath of the Java GC for the patched
VM, for example:

        cd $JAVA_GC_HOME
        tar zxvf javagc.tar.gz
        ij -classpath ./:$JAVA_GC_HOME/javagc HelloWorld

You can switch the VM GC module back to GC_v4 in the following code
(vmcore/src/init/vm_main.cpp):

static int initialize_gc_component() {
  if (0) {     //change 0 to 1 to switch to GC_v4
    initialize_c_gc_component();
  } else {
    initialize_java_gc();
  }
}

If you want to completely disable this mechanisms of Java GC support in
DRLVM, please change the macro definition of GC_DLL to "gc" and remove the
invocation to initialize_gc_component in function vm_main."

-- 
Thanks,
Ming

Re: A GC module written in Java for DRLVM

Posted by Ming Wu <wu...@gmail.com>.
Weldon,

2006/6/21, Weldon Washburn <we...@gmail.com>:
>
>
> I looked at JIRA 622.  It looks like there are 22 pages of new
> assembly code and about 26 pages of new java code.  Perhaps you could
> give us a summary of what the assembly code does and why it can't be
> done in Java.


Don't worry about the asms, they are only temporary for
hacking purpose when proper JIT support was (is) unavailable in DRLVM.
Since Java GC needs to access VM internal functionalities, which are
exposed with "C" interfaces, we choose to use fast JNI to access them
easily. Fast JNI in DRLVM requires asm stub for the transition from Java
to C world for every C function, hence you see lots of asms in our code.
They mostly can be eliminated once DRLVM JIT supports intrinsics of
VM_Address, etc., just like the write barrier issue we discussed.
Actually this fast JNI invocations are forming a layer of Java GC
adapter to VM core, which hide the details of VM core implementation
from Java GC, so that the Java GC we developed can plug into a Java VM
core as well.

Also, I would like to see the code you developed that JITs the GC.  It
> might make sense to reuse this code for the MMTk port.


In our work, we do not change JIT much. DRLVM can jit the
Java GC like a normal Java application. The only change is, as explained
above, that JIT needs to know the methods for fast JNI invocations.
Please refer to function
compile_do_compilation_jit(vm/vmcore/src/jit/compile.cpp).


-- 
Thanks,
Ming

Re: A GC module written in Java for DRLVM

Posted by Weldon Washburn <we...@gmail.com>.
Ming,

I looked at JIRA 622.  It looks like there are 22 pages of new
assembly code and about 26 pages of new java code.  Perhaps you could
give us a summary of what the assembly code does and why it can't be
done in Java.

Also, I would like to see the code you developed that JITs the GC.  It
might make sense to reuse this code for the MMTk port.

    Thanks
         Weldon


On 6/19/06, Ming Wu <wu...@gmail.com> wrote:
> We have developed a Java GC with mark-sweep algorithm and integrated it into
> the current drlvm code. The key feature is, the GC is not prebuilt into
> binary, but loaded and jitted by the VM at runtime. Hopefully it is useful
> to the existing efforts porting MMTk to DRLVM. It is actually the rewrite of
> gc_mf of drlvm in Java language. It can run some simple Java applications,
> but there is some issue with the build environment (different from what we
> developed the GC with) that prevents us from running it with reasonable size
> Java application. We tried to minimize the change to DRLVM existing code.
>
> We have submitted the Java GC and patch file for VM to
> JIRA(HARMONY-622<http://issues.apache.org/jira/browse/HARMONY-622>).
> To run it, one should specify the classpath of the Java GC for the patched
> VM, for example:
>
>        cd $JAVA_GC_HOME
>        tar zxvf javagc.tar.gz
>        ij -classpath ./:$JAVA_GC_HOME/javagc HelloWorld
>
> You can switch the VM GC module back to GC_v4 in the following code
> (vmcore/src/init/vm_main.cpp):
>
> static int initialize_gc_component() {
>  if (0) {     //change 0 to 1 to switch to GC_v4
>    initialize_c_gc_component();
>  } else {
>    initialize_java_gc();
>  }
> }
>
> If you want to completely disable this mechanisms of Java GC support in
> DRLVM, please change the macro definition of GC_DLL to "gc" and remove the
> invocation to initialize_gc_component in function vm_main."
>
> --
> Thanks,
> Ming
>
>


-- 
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


Re: A GC module written in Java for DRLVM

Posted by Geir Magnusson Jr <ge...@pobox.com>.
Cute - thanks!

geir

Ming Wu wrote:
> We have developed a Java GC with mark-sweep algorithm and integrated it
> into
> the current drlvm code. The key feature is, the GC is not prebuilt into
> binary, but loaded and jitted by the VM at runtime. Hopefully it is useful
> to the existing efforts porting MMTk to DRLVM. It is actually the
> rewrite of
> gc_mf of drlvm in Java language. It can run some simple Java applications,
> but there is some issue with the build environment (different from what we
> developed the GC with) that prevents us from running it with reasonable
> size
> Java application. We tried to minimize the change to DRLVM existing code.
> 
> We have submitted the Java GC and patch file for VM to
> JIRA(HARMONY-622<http://issues.apache.org/jira/browse/HARMONY-622>).
> To run it, one should specify the classpath of the Java GC for the patched
> VM, for example:
> 
>        cd $JAVA_GC_HOME
>        tar zxvf javagc.tar.gz
>        ij -classpath ./:$JAVA_GC_HOME/javagc HelloWorld
> 
> You can switch the VM GC module back to GC_v4 in the following code
> (vmcore/src/init/vm_main.cpp):
> 
> static int initialize_gc_component() {
>  if (0) {     //change 0 to 1 to switch to GC_v4
>    initialize_c_gc_component();
>  } else {
>    initialize_java_gc();
>  }
> }
> 
> If you want to completely disable this mechanisms of Java GC support in
> DRLVM, please change the macro definition of GC_DLL to "gc" and remove the
> invocation to initialize_gc_component in function vm_main."
> 

---------------------------------------------------------------------
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