From: Robin G. <rob...@an...> - 2010-04-21 08:16:17
|
Hi Marcin, Some more debugging suggestions: So what happens if you run with GC verbosity high enough to dump stack when GC is triggered ? (verbose=4, I think) Does this occur on the first GC ? What if you increase the GC frequency (with -X:gc:stressFactor=1m, for example) ? What kind of build ? Can you reproduce it in BaseBase ? BaseAdaptive ? Full adaptive with baseline compiled mutator (-X:aos:enable_recompilation=false, -X:aos:initial_compiler=base) hth, robin Marcin wrote: > Hi Robin, > > First of all I have to apologize for late answer, somehow this message > appeared in spam folder... > I have used test harness and everything works well there. > I think I have already tried everything and yet I haven't found the > solution to my problem - I tried compiling JikesRVM with alignment > checking, enabling checks for memory being zeroed correctly, tried > allocating all code to immortal space but none of these ideas gave > positive results. > Furthermore I've found that it doesn't only fail with sanity checker but > also if I enable MMTkCallback in DaCapo benchmark together with low > initial heap size and also during execution of some test programs. > The error is repeatable under VM, I always get same stack trace, same > invalid method IDs and it fails at same places during execution. > It appears to me as if it was some sort of stack corruption, however I > have no idea how to debug this issue. > Any ideas are welcome. > > Below a copy of recent stack trace (JikesRVM 3.1.0). > > Best regards, > Marcin Wyrwas > > > > # rvm -Xms12m -Xmx512m -X:processors=all -jar ~/dacapo-9.12-bach.jar -c > MMTkCallback -s small pmd > WARNING: attempt to get compiled method #0x0805d94c > Died in GC: > attempt to get an invalid compiled method ID > Thread #2 > -- Stack -- > at [0x6744cce4, 0x5b2fdde5] Lorg/jikesrvm/VM; > sysFail(Ljava/lang/String;)V at line 2278 > at [0x6744cd00, 0x5b1fdf7e] > Lorg/jikesrvm/compilers/common/CompiledMethods; > getCompiledMethod(I)Lorg/jikesrvm/compilers/common/CompiledMethod; at > line 109 > at [0x6744cd2c, 0x5b1fe11d] Lorg/jikesrvm/mm/mmtk/ScanThread; > setUpFrame(I)Z at line 412 > at [0x6744cd50, 0x5b1fe653] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 370 > at [0x6744cd7c, 0x5b1fe7b0] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 282 > at [0x6744cdc0, 0x5b24bc3d] Lorg/jikesrvm/mm/mmtk/ScanThread; > startScan(Lorg/mmtk/plan/TraceLocal;ZLorg/jikesrvm/scheduler/RVMThread;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V > at line 232 > at [0x6744ce1c, 0x5b24bd63] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanThread(Lorg/jikesrvm/scheduler/RVMThread;Lorg/mmtk/plan/TraceLocal;ZLorg/vmmagic/unboxed/Address;Lorg/vmmagic/unboxed/Address;)V > at line 198 > at [0x6744ce60, 0x5b2261cd] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanThread(Lorg/jikesrvm/scheduler/RVMThread;Lorg/mmtk/plan/TraceLocal;Z)V > at line 138 > at [0x6744ce94, 0x5b1fa7ba] Lorg/jikesrvm/mm/mmtk/Scanning; > computeThreadRoots(Lorg/mmtk/plan/TraceLocal;)V at line 325 > at [0x6744cebc, 0x5b1fb173] Lorg/mmtk/plan/SimpleCollector; > collectionPhase(SZ)V at line 74 > at [0x6744cee8, 0x5b2c7f98] Lorg/mmtk/plan/TM/TMCollector; > collectionPhase(SZ)V at line 134 > at [0x6744cf40, 0x5b2c82d0] Lorg/mmtk/plan/Phase; processPhaseStack(Z)Z > at line 429 > at [0x6744cf60, 0x5b1fae14] Lorg/mmtk/plan/Phase; beginNewPhaseStack(I)Z > at line 351 > at [0x6744cf7c, 0x5b1fb295] Lorg/mmtk/plan/StopTheWorldCollector; > collect()V at line 39 > at [0x6744cf98, 0x5b1fec90] Lorg/mmtk/plan/TM/TMCollector; collect()V at > line 65 > at [0x6744cfd8, 0x5b312a39] > Lorg/jikesrvm/mm/mminterface/CollectorThread; run()V at line 367 > at [0x6744cff8, 0x0804fd95] Lorg/jikesrvm/scheduler/RVMThread; > startoff()V at line 2532 > Virtual machine state: > > -- Threads -- > 4-main-4-RUNNABLE > 2-daemon-collector-1-RUNNABLE > 3-daemon-5-RUNNABLE > > > -- Locks in use -- > > lock availability stats: 0 locks allocated, 0 locks freed, 0 free locks > Dumping stack of active thread > > > > > Dnia 6-04-2010 o godz. 2:54 Robin Garner napisał(a): >> Marcin wrote: >>> Daniel, >>> >>> I am implementing a non-moving collector that manages whole heap (apart >>> from immortal space), similarly to RC collector. >>> Without sanity checker it is crashing after 50+ full heap (300M heap) >>> collections due to some corruption. >>> With sanity checker enabled I get the reported error immediately. >> Hi Marcin, >> >> Have you used the MMTk test harness ? It includes several additional >> sanity checks that are impractical when MMTk is run inside JikesRVM. >> >> Also, if you have a GC bug that the harness can't detect, I'd be >> interested in knowing about it so that I can improve the harness. >> >> Regards, >> Robin >> >>> Best regards, >>> Marcin Wyrwas >>> >>> Dnia 29-03-2010 o godz. 0:19 Daniel Frampton napisał(a): >>> >>> Memory for code is also managed by MMTk, so it is possible your GC >>> is not treating code objects correctly. Code is not allowed to move, >>> and generally allocated using a different set of allocators. The >>> harness does not generally allocate these types of objects (although >>> it would be relatively straightforward to create a case that tested >>> that). >>> >>> I would have a look through MMTk at the small and large code >>> allocation/collection. >>> >>> I assume you run into a similar problem when running without the >>> sanity checker? >>> >>> Cheers, >>> Daniel. >>> >>> >>> >>> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |