<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Andy,<div class=""><br class=""></div><div class="">I wouldn’t do anything special. The array is effectively a cache and in G1 that would be a humongous allocation (in most configurations). After that, it’s business as usual.</div><div class=""><br class=""></div><div class="">Kind regards,</div><div class="">Kirk Pepperdine</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2017, at 3:07 PM, Andy Nuss <<a href="mailto:andrew_nuss@yahoo.com" class="">andrew_nuss@yahoo.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div class="">I am writing a custom servlet replacement for memcached, suited to my own needs. When the servlet boots, I create a huge array, about 1% of total memory in a static variable of my Cache class. This is for quickselect median sorting, when memory is about 75% full by my calculations, so I can throw away half of my cached entries in a background thread.</div><div class=""><br class=""></div><div class="">My cache consists of tiered ConcurrentHashMaps, whose key is a base64 string of about 30 chars that is completely random. The mapped value is always about 100 chars. But the first char of the key takes you to the second tier of ConcurrentHashMaps and so, at a shallow depth, until you get to the ConcurrentHashMap that maps the key to the string. The cache has get and put and delete methods for these String key values, and again, though the strings are roughly the same length they are not exactly the same length. And because the tree of maps is statically held, all the strings are in old generation heap.</div><div class=""><br class=""></div><div class="">The machine is 8gig or 16gig or more with 2 or 4 or more cpus. The map fills and fills over time on the tomcat instance with many millions of mappings, again, because in static references, old generation. So the tomcat machine is mostly old generation heap usage. The question is what happens at about the time the quickselect prunes away half of the LRU entries, by deleting them from the map tree. It is removing the key and value strings, that are smallish, and all over the heap. Thus potentially reclaiming half of memory when done. For future additions to the map once the garbage has been cleared. What gc settings should I use in the tomcat program and what gc (jdk 8)? And the most important question is this, how do I ensure my tomcat threads (using nio) do not hang for long periods of time, when the gc is sweeping the old generation.</div><div class=""><br class=""></div><div class="">E.g. a servlet get method would do puts or gets to the map to fulfill the servlet request, and I want to ensure that it always completes in micros, and does not hang, even when the GC is doing extensive reclamation.<br class=""></div><div class=""><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>