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