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

Robin Garner <[email protected]> Mon, 28 Nov 2016 10:44:58 +1100
Newsgroups gmane.comp.java.jikes.rvm.devel
Message-ID <CADjFg8T5G6VvwZ5vKBg7gL-hxyMJ5eaJCM+8m9m40_WMPV0FBg@mail.gmail.com>
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]> 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]> 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]
> > 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