-
Stephan Bergmann yazdı
AsynchronousFinalizer was originally added as 870a4401 "INTEGRATION: CWS mtg1: #i57753# Avoid long-running finalize methods" referring to <https://issues.apache.org/ooo/show_bug.cgi?id=57753> " Fix JNI-UNO bridge so that the JVM doesn't run out of memory when a destructor locks the SolarMutex." It is unclear to me how relevant "If JVMs are getting more mature and should no longer have problems with long-running finalize methods, this class could be removed again" really is in practice. After all, advice on hotspot-gc-devel is to avoid finalize() if possible (<http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-June/010215.html> "Re: History of finalizer execution and gc progress?"). So stick with this approach of home-grown draining for now (where a home-grown approach using PhantomReferencens would need a dedicated draining thread, too, so would not have much benefit over the existing code in practice). Timely termination of AsynchronousFinalizer threads is achieved by using a dedicated thread per bridge and joining it in the remote bridge's dispose() resp. the JNI environment's new java_env_dispose. Change-Id: Idcef2dbf361a1de22f60db73828f59e85711aea7
6ddde10b
Adı |
Son kayıt (commit)
|
Son güncelleme |
---|---|---|
.. | ||
JNI_info_holder.java | ||
JNI_proxy.java | ||
manifest |