Other than size savings for the download and storage of potentially redundant things-formerly-known-as-the-JRE, were there performance benefits to having a shared JRE?
Theoretically, a slow but Java-optimized system could cache (components of) the JRE in memory and make those pages available to novel JRE-based executables, much like a binary shared library [0]. Was this ever done in practice? I imagine it would have sped up Java Web Start startup times considerably - and mobile platforms as well, perhaps?
On the desktop a clear no, on the server, back when you still had "apps per server" instead of "servers per app", who knows what might have been going on between the classloader hierarchies of your favorite EE platform and it's JVM.
Hard to say, because many performance improvements were done after the JRE had been removed. There are reasons why a custom runtime can have better performance, though. jlink can place both a modular application and the runtime into a single image file that can be loaded quickly, and whose metadata can be cached efficiently.
Theoretically, a slow but Java-optimized system could cache (components of) the JRE in memory and make those pages available to novel JRE-based executables, much like a binary shared library [0]. Was this ever done in practice? I imagine it would have sped up Java Web Start startup times considerably - and mobile platforms as well, perhaps?
[0]: see for instance https://unix.stackexchange.com/questions/458112/how-to-ensur...