Support for reducing the number of Capabilities with setNumCapabilities
authorSimon Marlow <marlowsd@gmail.com>
Tue, 13 Dec 2011 13:09:46 +0000 (13:09 +0000)
committerSimon Marlow <marlowsd@gmail.com>
Thu, 15 Dec 2011 15:48:54 +0000 (15:48 +0000)
commit9bae79159d3cb5cbb6491711341aa9b07d703ae6
tree4aa767f2a58d4d42637dc999ab469dd2dd07db19
parentdff852b1b65d07a4a400d3f20c854172c8fcecaf
Support for reducing the number of Capabilities with setNumCapabilities

This patch allows setNumCapabilities to /reduce/ the number of active
capabilities as well as increase it.  This is particularly tricky to
do, because a Capability is a large data structure and ties into the
rest of the system in many ways.  Trying to clean it all up would be
extremely error prone.

So instead, the solution is to mark the extra capabilities as
"disabled".  This has the following consequences:

  - threads on a disabled capability are migrated away by the
    scheduler loop

  - disabled capabilities do not participate in GC
    (see scheduleDoGC())

  - No spark threads are created on this capability
    (see scheduleActivateSpark())

  - We do not attempt to migrate threads *to* a disabled
    capability (see schedulePushWork()).

So a disabled capability should do no work, and does not participate
in GC, although it remains alive in other respects.  For example, a
blocked thread might wake up on a disabled capability, and it will get
quickly migrated to a live capability.  A disabled capability can
still initiate GC if necessary.  Indeed, it turns out to be hard to
migrate bound threads, so we wait until the next GC to do this (see
comments for details).
rts/Capability.c
rts/Capability.h
rts/Schedule.c