Re: [rvm-research] Failure implementing a Mark-Sweep plus Semispace composite

Turns out the problem was in the isLive() implementation of  my new (moving) MarkSweepSpace. I thought testMarkState(object) is enough to test liveliness. But for a space that has both marked and forwarded objects, the correct way to test the liveliness of an object is to check the mark state and also the forwarding bits. Without checking for forwarding bits, the ReferenceProcessor would clear a reference that is still alive. Not totally sure about all the details in ReferenceProcessor especially weak references, but at least my collectors now work. And no changes necessary to MemoryManager:pickAllocator() at all! Sorry about possible confusion my earlier emails might have caused and thanks everyone for help!

> On Nov 28, 2016, at 12:44 AM, Robin Garner <[email protected]> wrote:
> 
> So there are two cases (or classes of case) where Jikes RVM needs to allocate objects that won't move.  The first class is where it's just too difficult to update all the references - there are several ways to allocate these, such as with the @NonMoving annotation.  Ultimately these are allocated via the MMTk ALLOC_NONMOVING allocator.  Generally this is bound to the "nonmoving" space, which is a MarkSweep space - if you're playing around with MarkSweep, you need to ensure that the nonmoving space isn't broken in the process, so copying the entire class hierarchy as you've done is the safe approach.
> 
> The other case is as an optimization.  The I/O libraries need to pass stable buffers to native code, and the interface code checks "willNeverMove()" on the buffer it's given.  If it is moveable, the I/O code copies data into a stable buffer before passing it to the native code, but if it's non-moving, it passes a pointer directly to the native code.  If the buffer were to move after this, then bad things would happen.  This kind of behaviour happens across the entire JNI interface.
> 
> So double check the allocators.  If ALLOC_NONMOVING is bound to a space that ultimately moves objects, this is a bug you need to fix.  If JikesRVM is allocating objects that can't be moved, then we need to track this down---this is unlikely, though, because there are plans around with moveable mature spaces.
> 
> As another check, try comparing your PlanConstratints class against the PlanConstraints for GenCopy, and double check the changes required for moveable mature spaces.
> 
> hth,
> Robin
> 
> 
> On Sun, Nov 27, 2016 at 7:00 AM, Shoaib Akram <[email protected] <mailto:[email protected]>> wrote:
> Thanks for your reply, Erik! I created new class files for my implementation of SegregatedFreeList and MarkSweepSpace. Same for the SegregatedFreeListLocal allocator and SegregatedFreeList. I set movable to true when calling the constructor of the Space class in SegregatedFreeList.
> 
> > On Nov 26, 2016, at 10:12 AM, Erik Brangs <[email protected] <mailto:[email protected]>> wrote:
> >
> > Hi,
> >
> > On 25.11.2016 22:40, Shoaib Akram wrote:
> >> There is a utility function in Space.java isMovable() which another part of Jikes can use to inquire whether objects in a particular space can move or not. For my implementation of mark-sweep space, I override this function to return true.
> >
> > isMovable() returns the instance variable movable. For MarkSweepSpace, movable is set to false in the constructor of SegregatedFreeListSpace. I assume that you've checked MarkSweepSpace (and related classes) for places where non-movable objects are assumed. Have you done the same for SegregatedFreeListSpace?
> >
> >> After some debugging, I narrowed the problem to a bunch of problematic objects whose moving from MS to A or B causes JikesRVM to hang. These include objects from classes loaded by the bootstrap classloader (Lgnu, Ljava, Lorg/jikesrvm, Lorg/vmmagic). Also some other classes such as
> >> Ljavax create the same problem. After pinning these objects in MS, a selection of dacapo benchmarks finish execution properly. I wonder why moving these objects out of a CopySpace is not a problem but moving them out of mark-sweep space is (?)
> >
> > The only thing that comes to my mind right now is @NonMoving and @NonMovingAllocation. If you have modified the original MarkSweepSpace (rather than creating e.g. MovingMarkSweepSpace and using that), it would be possible for objects that musn't move to get allocated into a MS space that actually moves objects. However, that's probably not what is happening in your case. IIRC the allocation for objects marked with these annotations would be allocated into the MarkSweepSpace provided by Plan and not the one provided by your garbage collector. The same applies for code, which is allocated into MS and LOS spaces, both of which don't move objects by default.
> >
> >
> > Kind regards,
> >
> > Erik Brangs
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Jikesrvm-researchers mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers <https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers>
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers <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