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

Thanks Robin for your suggestions. I turned off this optimization for the moment and process all the references on each collection.

One of the problems I faced with adding an extra generation to GenImmix was that the mutator would allocate a large structure such as a LinkedHashMap in the nursery. During the collection of the intermediate generation, the collector would evacuate this structure to the large object space which I only collect during a full-heap collection. But the objects the map points to are evacuated correctly to the intermediate generation as I want. This leads to the following dreadful situation: during collection time, pointers get created from the mature (large object space) to the intermediate space. For my purposes, it would be so nice if the mutator and the collector use the same heuristic to figure out what objects get allocated to the large object space. That way, the hashmap would go straight to the large object space and the pointers to entries would be remembered using mutator-time barriers. So instead of doing the hard work of remembering collector-time mature to intermediate pointers, I made the collectorContext and the mutatorContext use the same heuristic. I wonder though if anyone knows what is the significance of "maxBytes > Plan.pretenureThreshold" in the following statement in MutatorContext:copyCheckAllocator()? Is it there on purpose? Without this check, the collector and mutator have the same perception of what constitutes a large object. 

return (maxBytes > Plan.MAX_NON_LOS_DEFAULT_ALLOC_BYTES || (maxBytes > Plan.MAX_NON_LOS_COPY_BYTES && maxBytes > Plan.pretenureThreshold)) ? Plan.ALLOC_LOS : Plan.ALLOC_DEFAULT;

> On Mar 28, 2017, at 5:58 AM, Robin Garner <[email protected]> wrote:
> 
> You should also look at the Reference Type processors, as they use a 
> simple nursery.  If 'nursery' is true when calling 
> ReferenceProcessor#scan, no references created before the last GC will 
> be processed - your collector will probably only be correct if you treat 
> all reference passes as full-heap.
> 
> At the time we wrote it, jess was the only benchmark with a significant 
> performance impact, but it's been a while since I checked so it may be 
> more important these days.
> 
> HTH,
> 
> Robin
> 
> 
> On 13/03/17 05:32, Shoaib Akram wrote:
>> Hi Eliot and others,
>> 
>> Your are right. I would need to remember promotions to the intermediate space in the remset. My current solution is to have two sets of remset buffers. The first set remembers every entry from outside the nursery and is processed and squashed at the end of each nursery collection. The second remembered sets logs all pointers from outside both the nursery plus the intermediate space. Since the intermediate space is placed right next to nursery contiguously, a simple address check is enough for remembering the second set of pointers. Note that the second sets does not need to remember pointers from intermediate to nursery objects since both the nursery and intermediate space is collected together. When the intermediate space is collected, I process the second remembered sets. At the end of intermediate collection, both remsets are cleared. To avoid a couple of complications, I currently evacuate the nursery during intermediate collection directly to mature space. In my debugging exercises, I made sure that every remset entry in the first set (except those from intermediate to nursery) is also found in the second set. Using event counters in the fastPath method, I know that the number of remsets entries being processed during intermediate collection is equal to the number of times new slots were inserted in the remsets in the fastPath. Things don’t seem to work properly after the intermediate collection. Am I missing something? Since the crash happens after GC, I presume there are still stale references somewhere.
>> 
>> 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
>> 
>> ------------------------------------------------------------------------------
>> Announcing the Oxford Dictionaries API! The API offers world-renowned
>> dictionary content that is easy and intuitive to access. Sign up for an
>> account today to start using our lexical data to power your apps and
>> projects. Get started today and enter our developer competition.
>> http://sdm.link/oxford
>> _______________________________________________
>> 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
> _______________________________________________
> 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
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers