Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class loader is initialized. Since the common Cleaner is intended for system cleaning code to use, this patch now creates InnocuousThread with null TCCL and expects the system cleaning code to handle null TCCL only if it uses it. Mandy
Hi Mandy, Nice to see this fixed. It looks good to me. Thanks! Regads, Peter On 03/22/2016 07:41 PM, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/
This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class loader is initialized. Since the common Cleaner is intended for system cleaning code to use, this patch now creates InnocuousThread with null TCCL and expects the system cleaning code to handle null TCCL only if it uses it.
Mandy
On 22/03/2016 18:41, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/
This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class loader is initialized. Since the common Cleaner is intended for system cleaning code to use, this patch now creates InnocuousThread with null TCCL and expects the system cleaning code to handle null TCCL only if it uses it. This looks okay although the hasTCCL flag is a bit ugly. An alternative would be for InnocuousThread to take the TCCL in the constructor and have it reject all but null or the SCL.
-Alan
On Mar 23, 2016, at 4:54 AM, Alan Bateman <Alan.Bateman@oracle.com> wrote:
On 22/03/2016 18:41, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/
This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class loader is initialized. Since the common Cleaner is intended for system cleaning code to use, this patch now creates InnocuousThread with null TCCL and expects the system cleaning code to handle null TCCL only if it uses it. This looks okay although the hasTCCL flag is a bit ugly. An alternative would be for InnocuousThread to take the TCCL in the constructor and have it reject all but null or the SCL.
I did consider taking ClassLoader parameter and I don’t like either option. I was tempted to convert the constructors to factory methods to avoid passing a ClassLoader or hasTCCL. Mandy
On Mar 23, 2016, at 8:27 AM, Mandy Chung <mandy.chung@oracle.com> wrote:
I did consider taking ClassLoader parameter and I don’t like either option. I was tempted to convert the constructors to factory methods to avoid passing a ClassLoader or hasTCCL.
This version converts the constructors to static factory methods: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.01/index.html Mandy
Hi Mandy, On 22/03/16 18:41, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/
I think this is fine. ( I also agree with Alan's comment ) Just a few minor, subjective, comments: - Maybe update the CleanerFactory class-level docs, OpenJDK modules -> system modules. - CleanerFactory.cleaner I find the paragraph a little confusing. Maybe something like: * <p> This Cleaner will run on a thread whose context class loader * is {@code null}. The ( system ) cleaning action should be robust * enough to handle a {@code null} context class loader. -Chris
participants (4)
-
Alan Bateman
-
Chris Hegarty
-
Mandy Chung
-
Peter Levart