It would be nice if HaLVMs could use all the cool parallel stuff from the mainline of GHC, by utilizing multiple Xen VCPUs.
I think this is not actually all that difficult. In this case, when we boot up, we would figure out how many VCPUs we had been given and pass the appropriate number through the built-in command line. "Starting a new OS thread" then becomes booting an auxiliary processor. The big issue, really, is rewriting the locking structures that the GHC runtime expects of its threaded runtime.
Once the basic support for SMP HaLVMs is in place, we would also have to strongly consider just removing support for non-threaded-runtime versions of the HaLVM.
It would be nice if HaLVMs could use all the cool parallel stuff from the mainline of GHC, by utilizing multiple Xen VCPUs. I think this is not actually all that difficult. In this case, when we boot up, we would figure out how many VCPUs we had been given and pass the appropriate number through the built-in command line. "Starting a new OS thread" then becomes booting an auxiliary processor. The big issue, really, is rewriting the locking structures that the GHC runtime expects of its threaded runtime. Once the basic support for SMP HaLVMs is in place, we would also have to strongly consider just removing support for non-threaded-runtime versions of the HaLVM.