Why are there two separate MathKernel processes running when I start up Mathematica 9?

Question

When I start the Mathematica 9 Front End, and check the list of running processes, I see two separate MathKernel processes. If I only start the kernel, without a front end, then there's only one process running. I'm on OS X. Do others also see two processes? What about other operating systems? What is the purpose of having two MathKernel processes running?

ps ux | grep Math gives me this:

szhorvat  1077   7.0  0.7  1136220 110948   ??  S     7:01PM   0:13.46 /Applications/Mathematica 9.app/Contents/MacOS/Mathematica -psn_0_712878
szhorvat  1080   0.5  0.3  2637284  46084   ??  S     7:01PM   0:00.81 /Applications/Mathematica 9.app/Contents/MacOS/MathKernel -nopaclet -noinit -pwfile /Applications/Mathematica 9.app/Configuration/Licensing/playerpass -mathlink -linkmode connect -linkprotocol SharedMemory -linkname dvm_shm
szhorvat  1083   0.1  0.4  2634236  67284   ??  S     7:01PM   0:01.30 /Applications/Mathematica 9.app/Contents/MacOS/MathKernel -mathlink -linkmode connect -linkprotocol SharedMemory -linkname gny_shm
szhorvat  1103   0.0  0.0  2432768    620 s001  R+    7:02PM   0:00.00 grep Math

Answer 1

As people have figured out in the comments, this was a quite deliberate decision on our part. One which I can take a significant amount of credit/responsibility/blame for.

First a little bit about the extra kernel. The kernel is enabled using a password which causes it to run in Wolfram Player mode. It runs using the same binary as the regular kernel, but it runs in a limited mode which prevents it from being fully functional (for example, there are serious limitations on writing to disk). Most importantly, it does not use up one of your kernel license slots.

Beginning in version 6, the front end has been increasingly leaning on kernel programming to do a lot of stuff that had, previously, been relegated to C++ code in the front end binary (a testament to the increasing power of the underlying product). Many dialog boxes are driven by kernel programming. The help viewer has lots of kernel functionality behind it. Even some menu commands invoke the kernel to work properly. This became something of a problem for people who like to modify their default kernels; especially if the default kernel happens to be a remote kernel, where the transport mechanism could really slow down FE dynamic interfaces. So, I believe in v7, we started locking down the Local kernel as a "special" kernel which would only allow limited changes and would always be running. But I was never really satisfied with this solution. It seemed really hacky, and potentially penalizes users by soaking up a kernel license they might not wish to run.

In v9, we came up with the idea of a "service kernel". This kernel exists only to service the front end. True, it runs as a separate process, but that doesn't use as much real extra resources as you might think. Caching and memory-mapped files leads to a lot of reuse or efficiencies for running multiple copies of the same binary. And the FE doesn't push its kernel very hard, so it's not going to be allocating a lot of memory for FE programs. But the important point is that the FE kernel is available when the user kernel may not be. Maybe it's not available because the user didn't want to launch it. Or maybe because the user's busy doing real computational work, but doesn't want that work making it difficult to do something like running the Find dialog or copying some formula to MS Word (to pick two real examples that rely on the kernel).

In the future, I would expect more computation to shift to the service kernel. I was disappointed, for example, that we weren't able to run all help viewer operations in the kernel. But the trajectory moves us back to a place where the Local kernel, or whatever a user wants his/her kernel to be, is really now their own and not being borrowed to run FE operations. Of course some FE operations must always run in the user's kernel because they rely on probing kernel state -- most notably syntax coloring and auto-completion. But we'll offload as much of the other stuff as we can to the service kernel.