On 18/05/2016 12:47, Rory O'Donnell wrote: > Thanks Mark, I'll see what I can do.
Thanks. This might help: https://github.com/markt-asf/memory-leaks It contains simple demonstrations of each of the leaks. Some of the demonstrations are a little contrived but the leaks demonstrated were all observed in production by one of more Tomcat users. Comments at the start of each class indicate if the leak has been fixed and, if so, in what version(s). Thanks again, Mark > > Rgds, Rory > > > On 18/05/2016 12:33, Mark Thomas wrote: >> Rory, >> >> Thanks for letting us know that a new build is available. We continue to >> test Tomcat with Java 9 and are tracking multiple issues. The majority >> of these have emerged as a result of a review of Tomcat's memory leak >> prevention and detection code. >> >> We would appreciate any help you can provide in nudging the following >> issues towards resolution. Some of these are very new so it is not >> surprising that not much has happened so far. >> >> 1. JVMTI bug that prevents tools like YourKit and Eclipse MAT >> identifying the root causes of memory leaks caused by initialization of >> static Exception fields. >> Review ID: JI-9037905 >> >> 2. Memory leak in com.sun.jndi.ldap.pool.PoolCleaner >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040988.html >> https://bugs.openjdk.java.net/browse/JDK-8156824 >> >> 3. Memory leak in sun.rmi.transport.GC >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html >> >> 4. API to trace RMI Target memory leaks without resorting to reflection >> (I accept that this is unlikely but If you don't ask...) >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html >> >> 5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread >> http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html >> >> We have also noticed that JSP compilation is broken. Our current >> understanding is that we should be able to fix this with an update to >> the Eclipse JDT compiler. We'll let you know if that changes. >> >> Finally, there are still some memory leak issues we haven't reviewed. As >> that progresses, we may have a few more issues to add to the memory leak >> issues listed above. >> >> Kind regards, >> >> Mark >> >> >> On 18/05/2016 09:31, Rory O'Donnell wrote: >>> Hi Mark, >>> >>> Early Access b118 <https://jdk9.java.net/download/> for JDK 9 is >>> available on java.net, summary of changes are listed here >>> <http://www.java.net/download/java/jdk9/changes/jdk-9+118.html>. >>> >>> Early Access b118 <https://jdk9.java.net/jigsaw/> (#4913) for JDK 9 with >>> Project Jigsaw is available on java.net. >>> >>> JDK 9 Build 118 includes a refresh of the module system. >>> >>> There are several changes in this update, JDK 9 b118 has the updated >>> policy for root modules described >>> in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't >>> resolved by default and so it will >>> look "as if" the types in these modules have been removed. More info on >>> the JDK 9 dev mailing list [2]. >>> >>> A change that went into JDK 9 b102 is worth mentioning: >>> JDK9: Remove stopThread RuntimePermission from the default java.policy >>> In previous releases, untrusted >>> code had the "stopThread" RuntimePermission granted by default. This >>> permission allows untrusted code >>> to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on >>> threads in the same thread group. >>> Having a ThreadDeath Error thrown asynchronously is not something that >>> trusted code should be expected >>> to handle gracefully. The permission is no longer granted by default. >>> >>> Rgds,Rory >>> >>> >>> [1] http://openjdk.java.net/jeps/261 >>> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
