Re: [rvm-research] Concurrent Semispace-related questions.

Hi,

On 24.04.2014 03:43, Claire Murphy wrote:
> 2) We would like to use an atomic compare-and-swap to insert a forwarding pointer and forwarding bit into an object. We tried to use this code to do that:
> 
> VM.objectModel.attemptAvailableBits(object, forwardingWord, forwardingWord.or(Word.fromIntZeroExtend(ForwardingWord.FORWARDED)));
Is this the complete code? Remember that compare-and-swap operations will fail if the value at the target address does not match the expected value. You'll have to use a loop and check the return value. Look at the method attemptToForward(ObjectReference) in ForwardingWord for an example of the correct usage.

> 4) In RVMThread.java, there is a boolean, "activeMutatorContext"  with the comment /** Is this a "registered mutator?" */ We assumed that this meant that checking this boolean checks whether a thread is a mutator (as opposed to a collector) but the check returns true even in what we believe are collector threads(as indicated when we checked  isCollectorThread). What does this actually do?
This variable is used to check whether a thread should flush during a mutator flush request (see handleHandshakeRequest() in RVMThread). Currently, activeMutatorContext is true for both for collector threads and mutator threads unless the thread is in the process of terminating. It is possible that this variable shouldn't be true for collector threads at runtime but I don't know if that's the case.

If you need more information about the handshakes, take a look at the section "Thread management" for the user guide.

> ) We have printed the address ranges for our two semispaces as well as the Large Object Space, and they appear to be the same ranges. Is this due to some feature of Jikes we don't understand, or is there some place we need to specify the address ranges to avoid this? We believe that this is causing us issues; our collector fails inside the Large Object Space, while accessing an object that is not large enough to be allocated there. (We set our allocator to be ALLOC_DEFAULT, as in the provided SS collector.)
I'll try to comment on this but keep in mind that I'm not a MMTk expert.

I assume that you're using Jikes RVM 3.1.x (and not hg tip). If that's the case, you could try to apply some patches from the main repository that might be related. The patch for RVM-1026 (hg revision ea90b048731d) adds an assertion that verifies that the space map isn't being changed after it has been finalized. You may also be interested in the patch for RVM-1025 (hg revision c057dcd82509) which fixes a bug that results in creation of a nursery in non-generational garbage collectors.

If that doesn't help, consider providing more information about the failures that you're seeing. This might enable other people on the list to help you out.


Kind regards,

Erik Brangs

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform