Re: [rvm-research] about the lock() in freelist

On 11/06/15 01:22, 王晨曦 wrote:
> Hi,everyone
>
>     I'm reading the codes about  how  immix get blocks from the  freelist.
> But I have some doubts about the lock() use in the
> FreeListPageResource.java /allocPages()
>
> such as :
>
>      lock();
>      boolean newChunk = false;

It's worth understanding this thoroughly because it's a commonly used 
idiom throughout MMTk.  It's a design pattern described briefly in the 
2004 "Oil and Water" paper [1].

You will see that the lock() method is inherited from the PageResource 
class, which acquires a lock on the instance variable 'lock'.  This 
tells you that what is being locked is this specific instance of 
FreeListPageResource.  The only threads blocked by this lock are ones 
that a) are allocating in the same space, and b) have to allocate fresh 
blocks from the PageResource.  Blocks are sized so as to make (b) 
infrequent.

[1] http://users.cecs.anu.edu.au/~steveb/downloads/pdf/mmtk-icse-2004.pdf

> I can't understand that is this lock()  used to synchronize the immix
> mutator threads or to synchronize the all the discontiguous spaces'
> mutator threads at this point.
> I think the free list is shared by all discontiguous space. So I think
> the free list need to synchronize
> all the spaces thread.

The only reason to lock the Chunk Map (which is the data structure 
common to all discontiguous spaces) is when the page resource must 
allocate a new chunk.  This is done in Space#growDiscontiguousSpace, and 
the lock that protects the chunk map lives in the Map class.

Regards,
Robin

------------------------------------------------------------------------------
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers