I don't understand what would be the purpose of this feature. Is it in order to really force a GC when clicking on the "Find leaks" button of the manager ? If it's for that, I don't think it's worth the trouble. People really interested in fixing their leaking webapps should take a snapshot of the heap and analyze it to confirm (as advised by the manager page) and find the origin of the leak.
Just my personal feeling... Sylvain On 22 avr. 2010, at 11:43, Rainer Jung wrote: > Just a short note: I stumbled over the "ForceGarbageCollection" JVMTI > function today. It reliably triggers a full GC and the call only returns > after having run the GC. It will do so, even when System.gc() is disabled. It > looks like it doesn't respect ExplicitGCInvokesConcurrent, so it will always > do a stop-the-world collection leading to possibly long stop times but also > to defragmented tenured space. > > As always, it is not expected, that the finalizers will be run. > > Maybe something we could add to tcnative. Since the call is stateless, adding > it should be simple, just implementing Agent_OnLoad to initialize the JVMTI > environmnt using GetEnv() and then making ForceGarbageCollection(env) > publicly accessible. One must also register the JVMTi agent using e.g. the > "-agentlib" startup option. > > I don't know, whether that would lead to a problem with duplicate library > loading, in which case one would have to separate it from tcnative. > > Caution: this is all form looking at docs and code, no tests done yet. > > Regards, > > Rainer > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
