Re: [rvm-research] Pre-Tenuring

I have 1 GC thread and 1 mutator thread. I have one immix space and 2 immix allocators. One allocator for the mutator context and one for the GC context.

My understanding of MMTk is that each space gets a 4 MB chunk from a global free list. Then, each allocator gets a 32 KB block from the space. Based on this understanding, communicating information b/w the mutator and the GC allocator should not be a concern. I guess that’s a fundamental tenet of MMTk design.

> On Aug 10, 2018, at 10:36 PM, Eliot Moss <[email protected]> wrote:
> 
> On 8/10/2018 3:58 PM, Shoaib Akram wrote:
>> Thanks for clarifications. Objects in LOS are only collected during a full-heap GC in my case so I took the liberty of calling them pre-tenured. You are right that one can have logical generations in a non-moving heap region, and pre-tenuring would mean something else.
>> About copying *which* objects, I meant that while the mutator is pre-tenuring objects of type T in the immix mature space, all other (small) object that survive a minor GC are copied to the same immix space (where mutator is allocated type T objects). And based on the failure logs, it seems the fault happens during the copying of a nursery survivor to the immix mature space.
>> I could try to create a 2nd immix space to allocate all object of type T. But in theory, mutator and GC can allocate (and promote) objects to the same space. I have an allocator per GC and Mutator. It should (and must) work out of the box ;)
>> Yes, an object of type T can be large. But in Jikes, the mutator performs a size-check at runtime, and during this check, if the object is larger than a threshold, the allocator picked during compile-time  is overruled, and replaced with the large object allocator.
> 
> Ok, I understand about your use of LOS now, and it should not be a problem.
> 
> I gather that the rest of the configuration is:
> 
> nursery: a bump-pointer space for fresh allocation (of small objects)
> mature:  an immix-policy space for survivors / mature objects (all small objects)
> 
> So, yes, nursery survivors should be promoted.
> 
> I can only guess, but my guess is that some information about immix allocation
> pointers or available space is being cached somewhere, and meanwhile your direct
> allocation into immix space changes the actual state of affairs.
> 
> You say you have an allocator per GC and Mutator.  Maybe the configuration assumes
> that nursery allocation is always by the Mutator and immix allocation is by the GC?
> This leads me to wonder how your Mutator code gains access to the GC's immix
> allocator information.  This is a possible place whether changes between GCs may
> not be being propagated.  If the Mutator and GC *both* have different allocators
> into same space, then when collection is triggered, the Mutator information needs
> to be propagated to the GC (and when GC ends, it needs to be propagated back).
> If not, the GC's allocator would over-write Mutator immix allocation.  I would have
> thought they would share the immix allocator to prevent this kind of thing -- though
> I am assuming stop-the-world collection (at any given time only Mutators are running
> or only GCs).
> 
> Assuming there are M mutators and G GCs - for simplicity, let's say N of each -
> then are there N immix spaces / allocators, or 2N?  Etc.
> 
> Best - EM
> 
> ------------------------------------------------------------------------------
> 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