Hi, > I had a thought I wanted to run by others. > > I wondered if maybe we should add -XX:+ExplicitGCInvokesConcurrent or > -XX:+DisableExplicitGC to Solr's default GC tuning. > > I checked master with 'git grep System.gc' and the explicit GC calls > only show up in test code and the lucene benchmark, nothing production > in either Lucene or Solr. I cannot say whether any of Solr's > dependencies use it or not. > > In general I doubt those options would have any effect on a completely > stock install ... but it might affect custom code that somebody adds. > In that situation, protecting latency by either completely disabling the > explicit GC or forcing it to run a concurrent collection seems like a > good idea. But maybe it's not worth worrying about, I'm curious what > others think. > > A question for Uwe ... would the following be an acceptable use/abuse of > forbidden APIs in our build system? The check passes with it: > > https://apaste.info/LxIJ
I think this is fine, but we should really verify that all calls to System.gc() are still useful in the tests. Maybe half of them are obsolete anyways or are just there to work around some bug that can be fixed otherwise. Nevertheless, the Solr default start args should disallow Garbage Collections completely. ExplicitGCInvokesConcurrent is not good, as it has problems on its own: it may still cause a stop-the-world, as cleanup of old gen requires this for most garbage collectors. So better disable it completely for user code. Third party libraries in Solr should never ever trigger a GC, and that is what we want to achieve. If somebody installs some 3rd party component and really wants to enable System.gc(), he can just change the solr.in file. To trigger a real GC use command line instead, which is under control of the system admin. FYI, Elasticsearch has user code triggered GC completely disabled. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
