Re: [rvm-research] Failure implementing a Mark-Sweep plus Semispace composite
Robin Garner <[email protected]> Mon, 21 Nov 2016 23:00:11 +1100
| Newsgroups | gmane.comp.java.jikes.rvm.devel |
|---|---|
| Message-ID | <CADjFg8QNX-9+vMWW-PfY0D_1TxAoZqpgsjb+BTG8g35bgbkKiA@mail.gmail.com> |
How do your remsets work ? Can you get your collector to work if you ignore remsets and do a full-heap collection every time (a-la CopyMS ?) (CopyMS exists because it separates out the remsets from the GC mechanisms for debugging purposes). On Mon, Nov 21, 2016 at 10:45 AM, Shoaib Akram <[email protected]> wrote: > Thanks Mike for replying. As I understand it, whether objects can move > from a space or not is controlled by some flags. I did modify the > associated variables to reflect the correct flags. Regarding trying a > different space, my plan does work correctly if I use two separate mature > spaces that are both copying i.e. space A consist of two semispaces A0 and > A1, whereas space B consists of two semispaces B0 and B1. Objects can move > from A0 to B0 or B1 and vice-versa. Trouble occurs in case one space is > mark-sweep and objects move from mark-sweep to a copy space. > > > On Nov 17, 2016, at 5:03 PM, Michael Bond <[email protected]> > wrote: > > > > Hi Shoaib, > > > > I believe that the implementation of MarkSweep assumes that objects are > > non-movable (i.e., can't be moved within the space or to another space). > > There are some methods that the MarkSweepSpace (or maybe the collector > > or *Constraints classe(s)?) override/implement that specify whether the > > space and/or objects are movable; at a minimum, you'll need to change > > the implementation of these methods to specify that objects are now > > movable in a MarkSweepSpace. > > > > There might also be assumptions for a MarkSweepSpace that are not > > explicitly specified but that would effectively prohibit moving objects. > > But maybe not; I think it's worth a try. :) MMTk developers, what do you > > think? > > > > Have you considered using a different kind of mature space, such as > > ImmixSpace, that supports moving objects? > > > > Regarding debugging: you could turn on GC assertions in order to > > hopefully get an earlier / more relevant error for runs that fail. > > > > Cheers, > > Mike > > > > On 11/14/2016 02:28 PM, Shoaib Akram wrote: > >> Hi All, > >> > >> I am having problems with a new collector I am trying to build that > extends the traditional generational semispace collector in JikesRVM with > another mature space that is an instance of the MarkSweepSpace (MS). The > plan is as follows. Nursery survivors always evacuate to the active mature > semispace. Objects are copied between the two mature semispaces as usual. > From time to time, a mature collection copies a selection of the live > objects out of the mature semispace to MS and vice-versa. A live object in > MS is guaranteed to be either marked or forwarded during a mature > collection. > >> > >> Everything works fine as long as there are no copies from MS to the > semispace. But if objects are copied from MS to the semispace, then after a > few collections, JikesRVM crashes. It appears to me that crash always occur > during a collection phase. > >> > >> I have taken care that the GC header has both forwarding bits and mark > bits. The GC header is initialized properly when the object is copied to a > space. I updated the masks in MarkSweepSpace appropriately. Also note that > the copies between the different spaces always succeed. > >> > >> Logically, I am quite convinced that my plan should work correctly. > Something is probably missing in the implementation. > >> > >> Anyone who tired similar things: is there any fundamental limitation to > copying objects from a MarkSweep space to a copy space? Other things that I > need to take care to make this plan work correctly? Should I provide more > details? > >> > >> A stack dump from one run of a benchmark is appended. Any help or > suggestion is greatly appreciated! > >> > >> Regards, > >> Shoaib. > >> > >> scanning 6 > >> scanning 2 > >> scanning 3 > >> scanning 1 > >> hardwareTrapHandler: thread = 0xf5fffb40 > >> JikesRVM: TROUBLE. Got a signal (Segmentation fault; #11) from outside > the VM's address space in thread 0xf5fffb40. > >> JikesRVM: UNRECOVERABLE trapped signal 11 (Segmentation fault) > >> handler stack 5cb700 > >> si->si_addr 0x5cb700 > >> cs 0x00000023 > >> ds 0x0000002b > >> es 0x0000002b > >> fs 0x00000000 > >> gs 0x00000063 > >> ss 0x0000002b > >> edi 0x7001d020 > >> esi -- PR/VP 0x70008414 > >> ebp 0x71011b1c > >> esp -- SP 0x70c9dc48 > >> ebx 0x74b3a2f3 > >> edx 0x71011b1c > >> ecx 0x7380a050 > >> eax 0x71011b1c > >> eip 0x005cb700 > >> trapno 0x0000000e > >> err 0x00000014 > >> eflags 0x00010203 > >> fpregs f5604150 > >> oldmask 0x00020000 > >> cr2 0x005cb700 > >> fp0 0x00000000000000000000 > >> fp1 0x00000000000000000000 > >> fp2 0x00000000000000000000 > >> fp3 0x00000000000000000000 > >> fp4 0x00000000000000000000 > >> fp5 0x00000000000080004005 > >> fp6 0x00000000000080004019 > >> fp7 0x00000000e30085fc4016 > >> JikesRVM: internal error > >> -- Stack -- > >> (0x70c9dcb8 19460) at [0x70c9dcb8, 0x647a9bc2] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanFrame(I)Lorg/vmmagic/unboxed/Address; at line 367 > >> (0x70c9dd04 19457) at [0x70c9dd04, 0x64a207c7] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanThreadInternal(Lorg/vmmagic/unboxed/Address;I)V at line 279 > >> (0x70c9dd60 19477) at [0x70c9dd60, 0x64a209ef] 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 229 > >> at [0x70c9dd60, 0x64a209ef] 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 195 > >> (0x70c9ddd0 19475) at [0x70c9ddd0, 0x6497ad0a] Lorg/jikesrvm/mm/mmtk/ScanThread; > scanThread(Lorg/jikesrvm/scheduler/RVMThread;Lorg/mmtk/plan/TraceLocal;Z)V > at line 147 > >> (0x70c9ddfc 20814) at [0x70c9ddfc, 0x6476db36] Lorg/jikesrvm/mm/mmtk/Scanning; > computeThreadRoots(Lorg/mmtk/plan/TraceLocal;)V at line 189 > >> (0x70c9de80 9495) at [0x70c9de80, 0x64790484] Lorg/mmtk/plan/SimpleCollector; > collectionPhase(SZ)V at line 62 > >> at [0x70c9de80, 0x64790484] Lorg/mmtk/plan/generational/GenCollector; > collectionPhase(SZ)V at line 126 > >> (0x70c9ded4 9501) at [0x70c9ded4, 0x64ce1810] > Lorg/mmtk/plan/generational/copying/GenCopyCollector; > collectionPhase(SZ)V at line 158 > >> (0x70c9df40 7462) at [0x70c9df40, 0x64ce2549] Lorg/mmtk/plan/Phase; > processPhaseStack(Z)V at line 474 > >> (0x70c9df70 7460) at [0x70c9df70, 0x6479053b] Lorg/mmtk/plan/Phase; > beginNewPhaseStack(I)V at line 385 > >> (0x70c9df84 9490) at [0x70c9df84, 0x6475bcc3] Lorg/mmtk/plan/StopTheWorldCollector; > collect()V at line 40 > >> (0x70c9dfa4 9478) at [0x70c9dfa4, 0x647aa268] Lorg/mmtk/plan/ParallelCollector; > run()V at line 50 > >> (0x70c9dfc4 15787) at [0x70c9dfc4, 0x64e5df4a] > Lorg/jikesrvm/mm/mminterface/CollectorThread; run()V at line 80 > >> (0x70c9dffc 21056) at [0x70c9dffc, 0x0804f795] > Lorg/jikesrvm/scheduler/RVMThread; startoff()V at line 2606 > >> JikesRVM: exit 124 > >> ------------------------------------------------------------ > ------------------ > >> _______________________________________________ > >> Jikesrvm-researchers mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > > > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > > Jikesrvm-researchers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > Jikesrvm-researchers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > ------------------------------------------------------------------------------ _______________________________________________ Jikesrvm-researchers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers