It also uncovered that the service was not picking up new JVM args from the server.json file on restart
Interesting-- you’re saying that you modified the server.json and then asked Windows to restart the service (which basically does a stop and a start) and the old server.json values were used? I’m not actually sure how that would even be possible as the start command should work just like any other start command that reads the current server.json in and uses it. None of those values are cached anywhere. Now, there are a couple scenarios in which CommandBox will ignore invalid heap size settings. Doing a debug start and reviewing the console output might help detect that.
The other java process thats running …
The other process is the CLI start command itself. In console mode, it “holds on to” the server process that runs as a separate Java instance and it pipes the console output back through. It’s what let’s NSSM track the actual server since NSSM sending a Ctrl-C to the CLI start command is what stops the second server process. There are probably some ways to work around the second process, but currently there’s no easy way not to have them both.
… is consuming around 500mb which seems like alot,
Meh, depends on what your definition of a lot is 
The CLI Java process doesn’t set a max heap size so it is allowed to keep asking for more RAM from the OS if it thinks it needs it. In theory, it shouldn’t take much RAM to just spin up another process and sit there monitoring its console output. It is pretty common for the CLI process to use 400-500 megs and I’ve found Java can be a little greedy and will gladly use what you let it take.
is there a way to trim that down
I was just looking into this a couple days ago for someone-- it is possible for you to cap the CLI process to not consume more than a certain amount of RAM, but it depends on what operating system you’re using. If you’re on Windows using box.exe then we wrap up the java bits using a library called Launch4J (The same one used by Minecraft!) and you can customize the JVM args to the actual CLI process (not the server) by creating a file called “box.l4j.ini” in the same folder as “box.exe” and you can put whatever JVM args you want, one per line.
box.l4j.ini
-Xmx256m
Note, I was playing with this the other day, and 128m is about the absolute smallest I could get Lucee/CommandBox to boot up in on my machine, but it was prone to throwing “GC Overhead Limit Exceeded” errors if I did anything crazy. 256m for a max heap seemed to work well, but keep in mind Java processes use memory that is not strictly heap which means even with a max heap of 256, doing a large amount of work in the shell could still climb upwards to 400 megs total for the entire java process.
One of my ideas for CommandBox 4 is playing with the new Lite version of the Lucee jar which contains no extensions and possibly has a smaller memory footprint. I haven’t actually done any memory-related tests with Lucee Lite but I’m curious about it. If you’re wondering what is using the memory, you’d need to do a heap dump and analyze it. I haven’t bothered to do that yet but I assume it’s just the Lucee innards and class files.
back to my original question is it possible to share the cf instance across several command box servers
No. By design, CommandBox follows a container mindset where each server is a separate, self contained process. The idea being that it’s a direct translation to something like Docker where you run each site as a microservice and can scale and deploy independently. Each server instance also gets its own server home, etc. Now, having more than one “installation” of your CF server isn’t an issue since CommandBox manages those files, upgrading the engine, and you can automatically apply your datasources, etc via CFConfig so it’s 100% automated.
Now, if you have like 50 separate sites, and by sites I mean 50 separate actual web roots then that’s going to limit how many you can reasonably start just due to the amount of memory you’ll need to entertain all of those heaps. You can run more than one ‘app’ out of different subfolders of a single server instance without issue but each CommandBox server instance gets a single web root.