Re: [rvm-research] Pre-Tenuring

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