<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=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2017, at 8:34 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="">Thanks Kirk,</div><div class=""><br class=""></div><div class="">The array is just a temporary buffer held onto that has its entries cleared to null after my LRU sweep. The references that are freed to GC are in the ConcurrentHashMaps, and are all 30 char and 100 char strings, key/vals, but not precisely, so I assume that when I do my LRU sweep when needed, its freeing a ton of small strings, </div></div></div></div></blockquote><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div class="">which G1 has to reallocate into bigger chunks, and mark freed, and so,</div></div></div></div></blockquote><div><br class=""></div>Not sure I understand this bit. Can you explain what you mean by this?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div class=""> so that I can in the future add new such strings to the LRU cache. The concern was whether this sweep of old gen strings scattered all over the huge heap would cause tomcat nio-based threads to "hang", not respond quickly, or would G1 do things less pre-emptively. Are you basically saying that, "no tomcat servlet response time won't be significantly affected by G1 sweep”?<br class=""></div></div></div></div></blockquote><div><br class=""></div>I’m not sure what you’re goal is here. I would say, design as needed and let the collector do it’s thing. That said, temporary humongous allocations are not well managed by the G1. Better to create up front and cache it for future downstream use.</div><div><br class=""></div><div>As for a sweep… what I think you’re asking about is object copy costs. These costs should and typically do dominate pause time. Object copy cost is proportional to the number of live objects in the collection set (CSet). Strings are dedup’ed after age 5 so with most heap configurations, duplicate Strings will be dedup’ed before they hit tenured.<br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;" class=""><div class=""><br class=""></div><div class="">Also, I was wondering does anyone know how memcached works, and why it is used in preference to a custom design such as mine which seems a lot simpler. I.e. it seems that with "memcached", you have to worry about "slabs" and memcached's own heap management, and waste a lot of memory.<br class=""></div></div></div></div></blockquote><div><br class=""></div></div>I’m the wrong person to defend the use of memcached. It certainly does serve a purpose.. that said, to use it to offload temp object means you end up creating your own garbage collector… and as you can see by the efforts GC engineers put into each implementation, it’s a non-trivial under-taking.</div><div class=""><br class=""></div><div class="">Kind regards,</div><div class="">Kirk</div><div class=""><br class=""></div></body></html>