RVM

MarkCompact broken by new threading model

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 3.1.0
  • Fix Version/s: 3.1.1
  • Component/s: MMTk: MarkCompact
  • Labels:
    None
  • Number of attachments :
    0

Description

In the new threading model, every thread is a Mutator. When a thread dies, it notifies MMTk that it should "flush" the mutator, but for MarkCompact this isn't presently possible.

The obvious fix is something along the lines of switching MarkCompactSpace to use a FreeListPageResource, and have the mutators acquire and return blocks to the shared page resource. Then the Collectors could do the collection work, and sanity would be restored.

Activity

Hide
Permalink
Robin Garner added a comment -

Fixed in r15845. Salient features of the fix are:

  • The BumpPointer allocates from a FreeListPageResource rather than a MonotonePageResource. This allows the collector to return unused pages to the shared pool.
  • When a thread dies, its mutator flushes allocated pages to a shared list where collectors can acquire work. This fixes the threading model issue.
  • When a collection starts, all active mutator threads flush to the shared page list.
  • Collector threads maintain a private list of pages to compact. When they run out of work during the calculateForwardingPointers pass, they get new work from the shared pool. Compacted pages are not flushed back to the common list.

Some shortcomings that could be addressed in future are:

  • Collectors will tend to interleave regions from multiple mutator threads. It would be nice to keep mutator pages together as far as possible.
  • Some collector threads could conceivably be left with more work than others. It would be nice to be able to balance work more dynamically.
  • Global synchronization is fairly heavyweight. It would be nice to look at a single CAS to acquire regions from the shared list rather than a lock/unlock sequence.
Show
Robin Garner added a comment - Fixed in r15845. Salient features of the fix are: The BumpPointer allocates from a FreeListPageResource rather than a MonotonePageResource. This allows the collector to return unused pages to the shared pool. When a thread dies, its mutator flushes allocated pages to a shared list where collectors can acquire work. This fixes the threading model issue. When a collection starts, all active mutator threads flush to the shared page list. Collector threads maintain a private list of pages to compact. When they run out of work during the calculateForwardingPointers pass, they get new work from the shared pool. Compacted pages are not flushed back to the common list. Some shortcomings that could be addressed in future are: Collectors will tend to interleave regions from multiple mutator threads. It would be nice to keep mutator pages together as far as possible. Some collector threads could conceivably be left with more work than others. It would be nice to be able to balance work more dynamically. Global synchronization is fairly heavyweight. It would be nice to look at a single CAS to acquire regions from the shared list rather than a lock/unlock sequence.

People

  • Assignee:
    Robin Garner
    Reporter:
    Robin Garner
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: