1. Wait, until it is safe to change the capabilities structure.
2. Allocate memory for number_of_capabilities + 1
3. Copy old capabilities structure to new allocated one
4. Relink to new memory location

To be honest, I don’t think it’s so easy; but at least this is a starting point I can use. Currently, I have to things to think about and which have to be solved before I can hack around in the code:

1. How can I call C code in the RTS from Haskell?
2. When is it safe to modify the capabilities structure?

Happy for any suggestions,
Michael

Extension  Lines
.lhs       300482
.hs        473479
.c         184039
.h         448394

combined  1406394

Found using wc -l `find . -name \*.`

Thankfully I only need a tiny fraction of it to add the dynamic-capabilities-feature: according to the commentary on the runtime system it consist of only about 50000 lines, and again, I probably need to modify / extend just a fraction of it. The code of the runtime system has an extra page on the wiki; it describes

• the purpose of the single files. Unfortunately these are currently only one liners and links to the particular files. Maybe I will add a much more extensive description for the Capabilities-files.
• the coding conventions for this subsystem. They are quite extensive but (in my humble opinion) very good and describe not only syntactical conventions but also some general remarks, debugging and robustness tricks.

For seeing how the capabilites are initialized I think that the file RtsFlag.c is helpful:

• RtsFlag.c defines parsing for -N<…>, hence I see where the capabilites are set and how they fit in the big puzzle of the RTS.
• RtsFlag.c uses and sets RtsFlags.ParFlags.nNodes (line 958). The structure is included in includes/Rts.h which includes include/rts/Flags.h (line 189 defines the important parts).
• RtsMessage.c would probably help me in the future for printing some debugging messages.

I’m curious if I’m on the right track. By the way, take all the informations with a grain of salt, since I’m currently in the beginning of understanding the code of the runtime system.

Minor update: After a look at the commentary I’m pretty sure I need to understand much of the scheduling subsystem to extend the capabilities-system. Thankfully the wiki seems to document it.

Currently I

• made an account (mlesniak) on the GHC’s developers wiki.
• opened a ticket (No. #3729) as a task, describing my idea: “Currently the number of capabilities can only be set at the start of a program using -N. At least for benchmarking and playing with semi-implicit code (any other real-world scenarious?) if would be nice to change the number of capabilities at runtime.”

  Current questions:
  

  • There is no person assigned on this task, should I assign myself?
  • It’s the only project without a particular difficulty (Diffuclty: None); should I set one or is this set by one of the “important” maintainers?
• downloaded the source for GHC HEAD, according to Getting Started
• was able to compile it on my 2.4 GHz Dualcore with 4 GB memory using the Building Guide. It took about 40 minutes for a full compile (yikes!)
• took a first look into ghc/rts/ Capability.c and Capability.h. This looks quite complicated and I probably have to understand a lot of the underlying system before I can even think about trying to modify this part of the RTS itself. Hopefully, the GHC Commentary will help.

Why do I do this? Firstly, I really like to solve problems and learn new things on the way. Secondly, I was always interested in the underlying parallel runtime system of GHC but without a concrete task motivating myself to understand this huge system was difficult. Thirdly, I hope that by learning part of the system I’m able to implement some of my (currently quite vague) ideas on dynamic adaptiblity of parallel runtime systems.

I will keep the interwebs updated, but do not expect too much soon, since I do this primary in my free time. Any hints, questions, remarks, (de-)motivating comments?