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

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

------------------------------------------------------------------------------