The short version is that you are often better off running multiple instances of a JVM application with a heap <32GB when you have the choice between scaling up and scaling out.
That depends on your memory usage. There is an awkward range (32GB - 48GB) where the increase in heap size does not give you a proportional increase in available memory because of the doubling of references. That is where you're better off running multiple instances. But for heaps bigger than 48GB running a single jvm is more efficient.
> The short version is that you are often better off running multiple instances of a JVM application with a heap <32GB when you have the choice between scaling up and scaling out.
We're in an awkward time right now, where many servers have more than 32GB of RAM, but not that much more. Once it becomes routine for servers to have 1TB of memory, this will no longer be much of an issue.
I wonder if using 16 bytes as an alignment would help in those corner cases. Some objects would use up to 33% more space (24 bytes -> 32 bytes), but I think that for most objects the increase will not be very noticeable and one extra bit would allow to use up to 64 GB of RAM with compressed pointers.
Depends on the use case. Sometimes compressed oops is counter productive, and it really isn't a significant piece of overhead if you are say... doing matrix multiplication with very large arrays.
