what you’re suggesting here is inherently unsafe.
A JVM process that signals exhaustion of the heap would imply that you can’t be sure anymore if the app will be able to continue working correctly. That’s the reason why akka provides the flag to automatically stop the jvm on such kind of errors…
I think you could envision an error handler (and I don’t know where you would put it to guarantee catching such RuntimeErrors), to spawn a separate process that will take place of the running one, and then close the currently failing JVM. But such operation might fail itself, because you’re not sure if the process is anymore in a stable condition.
That said, the general wisdom nowadays is that you want your JVM process to be monitored by an external orchestration system (docker, kubernetes, mesos, …) that will verifiy if your application is running correctly with a periodical heartbeat signal. Should a sufficient number of heartbeats fail to respond, the orchestrator would deduce that the process is gone and will decide if and how to restart it.