@nebhale This is the first issue we talked about the other day.
Currently, the Java Buildpack & Memory Calculator look at the following memory spaces:
- Heap
- Meta/PermGen Space
- Stack Size
- "Native"
Where Native includes an estimation of the amount used by NIO direct memory, the code cache, the compressed class space, the (tiny) amount used by initd, bash, memory mapped files (e.g. libjvm.so), etc. The ones that Java gives us tools to limit are the NIO direct memory, the code cache, and the compressed class space.
I think it would be sensible to limit those extra pools that we can, as, by default, their bounds are extremely high, and should they fill up (unlikely, but theoretically possible), the application will crash with exit code 255 (I think), and no detailed information about what caused the crash (I believe Garden are looking into providing better error messages?).
The flags that would be necessary for this are:
-XX:InitialCodeCacheSize (Default: unsure)-XX:ReservedCodeCacheSize (Default: 240MiB; Will never throw an OOM, but code compilation will halt if no free memory - performance implications)-XX:CompressedClassSpaceSize (Default: 1GiB)-XX:MaxDirectMemorySize (Default: unbounded)
The amount that will actually be used for each are broadly dependent on the following:
-XX:InitialCodeCacheSize, -XX:ReservedCodeCacheSize, -XX:CompressedClassSpaceSize: Number of classes in use - the more classes there are, the more things go into the compressed class space, and the more code could be compiled into the code cache.-XX:MaxDirectMemorySize: Number of NIO ByteBuffers (and etc) used. Unless an application makes direct use of them, only Tomcat (or another container) will be using ByteBuffers (AFAIK), so the maximum amount of space used would be porportional to the average response size and the number of threads.
I think that limiting these pools is a good idea, because if Java throws an OutOfMemory error, that makes it a lot easier to find the cause, rather than relying on Garden to provide us enough information to find the root cause.
@nebhale This is the first issue we talked about the other day.
Currently, the Java Buildpack & Memory Calculator look at the following memory spaces:
Where Native includes an estimation of the amount used by NIO direct memory, the code cache, the compressed class space, the (tiny) amount used by initd, bash, memory mapped files (e.g. libjvm.so), etc. The ones that Java gives us tools to limit are the NIO direct memory, the code cache, and the compressed class space.
I think it would be sensible to limit those extra pools that we can, as, by default, their bounds are extremely high, and should they fill up (unlikely, but theoretically possible), the application will crash with exit code 255 (I think), and no detailed information about what caused the crash (I believe Garden are looking into providing better error messages?).
The flags that would be necessary for this are:
-XX:InitialCodeCacheSize(Default: unsure)-XX:ReservedCodeCacheSize(Default: 240MiB; Will never throw an OOM, but code compilation will halt if no free memory - performance implications)-XX:CompressedClassSpaceSize(Default: 1GiB)-XX:MaxDirectMemorySize(Default: unbounded)The amount that will actually be used for each are broadly dependent on the following:
-XX:InitialCodeCacheSize,-XX:ReservedCodeCacheSize,-XX:CompressedClassSpaceSize: Number of classes in use - the more classes there are, the more things go into the compressed class space, and the more code could be compiled into the code cache.-XX:MaxDirectMemorySize: Number of NIOByteBuffers (and etc) used. Unless an application makes direct use of them, only Tomcat (or another container) will be usingByteBuffers (AFAIK), so the maximum amount of space used would be porportional to the average response size and the number of threads.I think that limiting these pools is a good idea, because if Java throws an OutOfMemory error, that makes it a lot easier to find the cause, rather than relying on Garden to provide us enough information to find the root cause.