Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04 Still looks good to me. Roland.

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Paul, Roland, thanks for review. Best regards, Vladimir Ivanov On 5/20/15 3:32 PM, Paul Sandoz wrote: On May 20, 2015, at 9:14 AM, Roland Westrelin roland.westre...@oracle.com wrote: What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

On May 20, 2015, at 9:14 AM, Roland Westrelin roland.westre...@oracle.com wrote: What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04 Still looks good to me. And to me. Injected fields seem a little magical but safer. Paul.

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Thanks, John. What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.04 Best regards, Vladimir Ivanov On 5/15/15 8:06 PM, John Rose wrote: I know injected fields are somewhat hacky, but there are a couple of conditions here which would motivate

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

After private discussion with Paul, here's an update: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.03 Renamed CallSite$Context to MethodHandleNatives$Context. Best regards, Vladimir Ivanov On 5/14/15 3:18 PM, Vladimir Ivanov wrote: Small update in JDK code (webrev updated in place):

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

I know injected fields are somewhat hacky, but there are a couple of conditions here which would motivate their use: 1. The field is of a type not known to Java. Usually, and in this case, it is a C pointer to some metadata. We can make space for it with a Java long, but that is a size

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Small update in JDK code (webrev updated in place): http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02 Changes: - hid Context.dependencies field from Reflection - new test case: CallSiteDepContextTest.testHiddenDepField() Best regards, Vladimir Ivanov On 5/13/15 5:56 PM, Paul Sandoz

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Thanks, Roland. Best regards, Vladimir Ivanov On 5/13/15 4:47 PM, Roland Westrelin wrote: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02/ The hotspot code looks good to me. Roland.

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Hi Vladimir, This is nice. I don't know how space-savvy CallSite should be, but you can save one additional object - the Cleaner's thunk: static class Context implements Runnable { private final long dependencies = 0; // Used by JVM to store JVM_nmethodBucket* static

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

I finished experimenting with the idea inspired by private discussion with Kim Barrett: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02/ The idea is to use CallSite instance as a context for dependency tracking, instead of the Class CallSite is bound to. It requires extension of

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Hi Vladimir, I am not an export in the HS area but the code mostly made sense to me. I also like Peter's suggestion of Context implementing Runnable. Some minor comments. CallSite.java: 145 private final long dependencies = 0; // Used by JVM to store JVM_nmethodBucket* It's a

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Peter, Paul, thanks for the feedback! Updated the webrev in place: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02 I am not an export in the HS area but the code mostly made sense to me. I also like Peter's suggestion of Context implementing Runnable. I agree. Integrated. Some

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02/ The hotspot code looks good to me. Roland.

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

On May 13, 2015, at 1:59 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Peter, Paul, thanks for the feedback! Updated the webrev in place: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02 +1 I am not an export in the HS area but the code mostly made sense to me. I

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Peter, http://cr.openjdk.java.net/~vlivanov/8079205/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8079205 Your Finalizator touches are good. Supplier interface is not needed as there is a public Reference superclass that can be used for return type of

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Hi Vladimir, On 05/08/2015 07:16 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8079205 Your Finalizator touches are good. Supplier interface is not needed as there is a public Reference superclass that can be used

[9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

http://cr.openjdk.java.net/~vlivanov/8079205/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8079205 Recent change in sun.misc.Cleaner behavior broke CallSite context cleanup. CallSite references context class through a Cleaner to avoid its unnecessary retention. The problem is the