Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#58 Patch for 1511447, partial: MMTk assert on concurrent gc()

closed
nobody
None
5
2012-09-21
2006-06-26
averymoon
No

This patch fixes the MMTk assertion failure:

/rvm/gdb> rvm -cp . TestYield
vm internal error at:
-- Stack --
Lcom/ibm/JikesRVM/VM; sysFail(Ljava/lang/String;)V at
line 1075
Lcom/ibm/JikesRVM/VM;
_assertionFailure(Ljava/lang/String;Ljava/lang/String;)V at
line 573
Lcom/ibm/JikesRVM/VM;
_assert(ZLjava/lang/String;Ljava/lang/String;)V at line 554
Lcom/ibm/JikesRVM/VM; _assert(Z)V at line 534
Lorg/mmtk/vm/Assert; _assert(Z)V at line 63
Lorg/mmtk/plan/Plan; collectionComplete()V at line 335

Lcom/ibm/JikesRVM/memoryManagers/mmInterface/VM_CollectorThread;
run()V at line 404
Lcom/ibm/JikesRVM/VM_Thread; startoff()V at line 786

identified by the following test case from bug 1511447:

public class TestYield implements Runnable {

    public static void main (String[] args) {

            int threadCount = 10;

            Thread[] t = new Thread[threadCount];
            for (int i = 0; i < threadCount; i++) {
                    t[i] = new Thread(new TestYield());
            }

            for (int i = 0; i < threadCount; i++) {
                    t[i].start();
            }

    }

    public void run () {

            int i = 0;
            while (i < 10000000) {

                    i++;
                    System.gc();
            }
    }

}

Fix logic: add an atomic test-and-set (with matching
fetch-and-store) on a gc field lock within
VMRuntime.gc() to prevent concurrent invocations of
VMRuntime.gc(). This logic does not implement mutex
locking (as such is unnecessary), but rather simply
prevents multiple threads (physical or logical) from
invoking [System|Runtime].gc() concurrently. If such
concurrent invocation occurs, then the second and
subsequent concurrent invocations are simply
idempotently ignored.

This patch is applied VMRuntime (rather than
MM_Interface), as adding it to MM_Interface causes
building of interface declarations to fail (due to
recursive dependency) as follows.

jbuild.interfaceDeclarations: Exception in thread
"main" java.lang.NoClassDefFoundError: com.ibm.JikesRVM.VM
at
com.ibm.JikesRVM.classloader.VM_BootstrapClassLoader.loadVMClass(VM_BootstrapClassLoader.java:124)
at
com.ibm.JikesRVM.classloader.VM_TypeReference.resolve(VM_TypeReference.java:541)
at
com.ibm.JikesRVM.VM_Entrypoints.getMember(VM_Entrypoints.java:305)
at
com.ibm.JikesRVM.VM_Entrypoints.getMethod(VM_Entrypoints.java:330)
at
com.ibm.JikesRVM.VM_Entrypoints.<clinit>(VM_Entrypoints.java:19)
at
com.ibm.JikesRVM.memoryManagers.mmInterface.MM_Interface.<clinit>(MM_Interface.java:1035)
at
com.ibm.JikesRVM.VM_Configuration.<clinit>(VM_Configuration.java:213)
at
GenerateInterfaceDeclarations.main(GenerateInterfaceDeclarations.java:108)
Caused by: java.lang.NullPointerException
at
java.util.StringTokenizer.<init>(StringTokenizer.java:146)
at
java.util.StringTokenizer.<init>(StringTokenizer.java:162)
at
com.ibm.JikesRVM.classloader.VM_BootstrapClassLoader.getResourceInternal(VM_BootstrapClassLoader.java:282)
at
com.ibm.JikesRVM.classloader.VM_BootstrapClassLoader.getResourceAsStream(VM_BootstrapClassLoader.java:233)
at
com.ibm.JikesRVM.classloader.VM_BootstrapClassLoader.loadVMClass(VM_BootstrapClassLoader.java:104)
... 7 more

jbuild.interfaceDeclarations: Exiting unexpectedly with
status 1.

Note, however, that applying in VMRuntime does NOT
catch the other invocations of System.gc() in
VM_Runtime: deliverHardwareException(),
resolvedNewArray(
), and resolvedNewScalar(*).
Fortunately, System.gc() is only invoked by those
methods when VM.ForceFrequentGC flag is set.

CVS Note: this patch uses Eclipse-compatible RVM
packaging, so the headers will need modification for
patching HEAD.

Discussion

  • averymoon
    averymoon
    2006-06-26

    -u patch for (partial) fix

     
    Attachments
  • averymoon
    averymoon
    2006-06-26

    Logged In: YES
    user_id=1519260

    This patch modifies VM_Runtime to invoke System.gc() rather
    than MM_Interface.gc(), to exploit the previous patch across
    all of RVM (in addition to the user-facing VMRuntime.gc()).

    The current classpath invocation chain for System.gc() is:

    System.gc() -> Runtime.gc() -> VMRuntime.gc()

    The author of MM_Interface.java is requested to review this
    patch to ensure invoking System.gc() (rather than
    MM_Interface.gc()) does not break any undocumented magic RVM
    assumptions.

    CVS Note: this patch uses Eclipse-compatible RVM packaging,
    so the headers will need modification for patching HEAD.

     
  • averymoon
    averymoon
    2006-06-26

    -u patch for (partial) fix

     
  • Logged In: YES
    user_id=1215444

    Patch applied and committed. Thanks Avery.