« Return to Thread: [rvm-research] Slots and Object Barriers

Re: [rvm-research] Slots and Object Barriers

by Steve Blackburn :: Rate this Message:

Hi Cristian,

On 26/06/2009, at 8:14 PM, Cristian Perfumo wrote:

Looking at org.mmtk.plan.generational.Gen, I see these constants:

public static final boolean USE_OBJECT_BARRIER_FOR_AASTORE = false; // choose between slot and object barriers
public static final boolean USE_OBJECT_BARRIER_FOR_PUTFIELD = false; // choose between slot and object barriers

I notice that if they are set to true, the applications go faster in general. I was wondering what the tradeoff is, if any, between having them set to true and false.

[...]

Is there any place where I can read what the difference is between using slots and object barriers?

There's a fairly simple tradeoff which Tony Hosking and I studied at some length in the following paper:

http://cs.anu.edu.au/~Steve.Blackburn/pubs/abstracts.html#wb-ismm-2004

For a slot barrier, you remember the address of the newly created pointer. You do this every time a pointer is stored into the nursery (there is no filter for uniqueness). On the other hand, an object barrier remembers (once only) the address of any object within which a pointer to the nursery is created. A bit is set in the header to record that the object has been remembered, and it is not subsequently remembered (until after the next nursery collection). So it is a little more efficient in what it remembers. However it is less precise, because only at GC time the entire remembered object must be scanned to find any pointers into the nursery, whereas with a slot barrier, only the remembered slot need be checked. You can think of an object barrier as a special case of card marking.

Also, I'm curious about the tradeoff between USE_DISCONTIGUOUS_NURSERY true and false.

Using discontinuous nurseries allows us to fully utilize virtual memory at a minor cost (the test for whether something is in the nursery or not requires a dereference rather than a comparison against an address constant). Last time I measured, the overhead was very small, however, when I enabled it on the head we noticed some new regressions, and I did not have time to track them all. I may re-enable this option some time soon---it makes our system more flexible.

The only place where they are tested is org.mmtk.plan.generational.GenMutator, in the fastPath(...) method.

Right. Small bits of code that are ubiquitous. Those few lines of code critically affect the performance of the whole system :-)

Cheers,

--Steve

PS, Since this list is run by researchers for researchers, we always appreciate it if you disclose your affiliation (only an issue if you're using an opaque email address such as gmail). That way we can know which research groups we are conversing with. Thanks.

Thank you very much.

Cristian.
------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------

_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

« Return to Thread: [rvm-research] Slots and Object Barriers