Not the parent but the biggest overheads are going to be startup time (which is easy to work around by just bringing up the procs and keeping them there) and memory overhead. There's some extra memory used for keeping all of the code or other shared resources around but let's assume that's negligible.
Because the JVM never gives memory back to the OS, you have to give it the maximum amount of memory that it could ever want, plus enough to last you between GC runs. Often this means that you have to give it at least twice the memory it actually needs. If you have more than one process, you end up having to multiply that extra "slack" memory by the number of processes that you have, which means that you have all of this wasted memory sitting around all of the time. "Memory is cheap" is a common attitude but in my experience in web stuff it's the only resource that's anywhere close to 100% used on an app server. So things with high memory overhead mean that you need more machines or bigger ones.
Of course, whether that matters depends on the actual numbers of how much memory is needed, how much is "wasted", whether that's actually your bottleneck, etc.
If you are using multiple JVMs and high performance IPC libraries you have largely already solved the memory bound problem on the JVM with standard techniques like arena allocation.
