On Mon, 2015-06-08 at 19:24 -0400, trondd wrote: > On 2015-06-08 10:47, Kurt Miller wrote: > > > > Thanks Tim for the testing and research into this issue. I'll take a > > look later at reducing the default CompressedClassSpaceSize. What > > ulimits were you running with? > > > > -Kurt > > There is an extra layer, I've just realized. I'm running java in chroot > and had just upgraded my snapshot so now chroot is aware of user login > classes. So at this point, I think that means it's using the default > class. I believe the only change I have made there is: > :datasize-max=2G:\ > :datasize-cur=1536M:\ > > I don't increase the limit from -cur.
Ok thanks again. I've looked into this a bit and found this nice description of the 1.7 -> 1.8 changes that eliminated the permanent generation in 1.7 and replaced it with metaspace plus compressed class space in 1.8: http://java-latte.blogspot.in/2014/03/metaspace-in-java-8.html Currently the compressed class space is fixed size like perm gen was. Oracle set a large default of 1G but only uses it in chunks as needed by java applications. I can reduce the default in our port, but it may come as a surprise that our default is smaller and cause the need for increasing it at startup for vary large applications. Alternatively, I can keep the large default but it would require a large datasize ulimit (2G may be enough) for 1.8. For users who want to run with smaller datasize ulimits they have the two options you noted: 1) Disable compressed class pointers via: -XX:+UseCompressedClassPointers 2) Reduce the size of the compressed class space via: -XX:CompressedClassSpaceSize=256M I haven't decided which approach is better for us. Requiring a 2G datasize ulimit to run does seem excessive. Thoughts? -Kurt
