Re: [rvm-research] remembered sets processing for a three-generational immix collector

Shoaib Akram <[email protected]> Sun, 5 Mar 2017 12:58:57 +0100
Newsgroups gmane.comp.java.jikes.rvm.devel
Message-ID <[email protected]>
Hi Eliot,

Thanks. A couple of more details about the setup. Nursery is collected independently of all other spaces, and the remset buffers that record pointers from outside the nursery to objects inside the nursery are cleared at the end of nursery collection. When the survivors fill up, both nursery and survivors are collected and *all* the remset buffers are processed, and cleared at the end of collection. In my implementation - as elsewhere in Jikes - promotions from nursery to a mature generation are not recorded in remsets. This is not a problem because when the original remset entry in processed, mature to nursery reference in your example, the forwarding mechanism will take care of updating the reference from the nursery to the intermediate space at the slot in mature space recorded in the re
 mset entry. The problem I have with my three generational immix is that, the assertions in the assertRemsetsFlushed() method fail to pass at the end of the collection cycle. These assertions make sure that there is nothing left to process in the remsets at the end of the collection cycle. Otherwise, there could be correctness problems. Since this is a stop-the-world collector, the collector contexts never intercept writes during collection. New entries in remset should accrue only when the mutator contexts are active. I am a but puzzled why these assertions would fail, and how there are unprocessed entries in remsets at the end of collection. The unchanged implementation of completeTrace(), and the  loop that processes the remsets associated with survivors is reproduced below. Thanks aga
 in for taking interest in this!

@Inline
  public void completeTrace() {
    logMessage(4, "Processing GC in parallel");
    if (!rootLocations.isEmpty()) {
      processRoots();
    }
    logMessage(5, "processing gray objects");
    assertMutatorRemsetsFlushed();
    do {
      while (!values.isEmpty()) {
        ObjectReference v = values.pop();
        scanObject(v);
      }
      processRememberedSets();
    } while (!values.isEmpty());
    assertMutatorRemsetsFlushed();
  }

logMessage(5, "processing remsetSurvivors");
    while (!remsetSurvivors.isEmpty()) {
      Address loc = remsetS.pop();
      if (VM.DEBUG) VM.debugging.remsetEntry(loc);
      processRootEdge(loc, false);
    }

 

Regards,
Shoaib.

> On Mar 4, 2017, at 10:23 PM, Eliot Moss <[email protected]> wrote:
> 
> Here is a possibility, if I am understanding your setup correctly:
> 
> Consider a reference from mature space to a nursery object.  This
> will correctly be noted in a remset.  However, when the object is
> promoted to the intermediate space, the fast-path code will now
> insert the slot into a remset again.  This is in fact correct
> since you will need to know in the future about this reference
> from mature to intermediate space, when doing a second-generation
> collection.
> 
> I am not sure what you want to do -- this is not necessarily a
> *problem*.  The entries should land in the remsets for the second
> generation, not the nursery.  The bad case would be if you end up
> with new write buffer items directed toward the (supposed now
> empty) nursery.
> 
> Regards - Eliot Moss
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot