[9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization checks scale devastatingly poorly
http://cr.openjdk.java.net/~vlivanov/8058309/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8058309 j.l.i.LambdaForm class has ~50-100 dependent nmethods on average. For every compiled LF, Unsafe.defineAnonymousClass() should validate all dependencies on parent class. Since thousands of LFs are compiled, VM wastes considerable amount of time re-validating dependencies. Most of the dependencies on j.l.i.LambdaForm are of type unique_concrete_method and can't be invalidated with the code generated for LFs. The fix is to decouple compiled LambdaForms and j.l.i.LambdaForm class and use j.l.Object as a parent class instead. Since LambdaForm is already used as a host class, all access checks pass. Reviewed-by: vlivanov, jrose, ? Contributed-by: aleksey.shipilev@oracle.com Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}, Aleksey refers to performance analysis in the bug [1]. Thanks! Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~shade/8058309/usdacdependency.txt
On 09/17/2014 07:02 PM, Vladimir Ivanov wrote:
Looks good, thanks! Sorry for not being clear earlier, but I am a bit concerned with the bug synopsis: we have sure worked around the issue with LambdaForms, but are we sure this fixed the general problem? John asked me to follow up on that with more concrete benchmark, and I will do that later. In other words, I would like to see the separate issue submitted for this workaround, and record the fix under that issue. Thanks, -Aleksey.
Aleksey,
Sorry for not being clear earlier, but I am a bit concerned with the bug synopsis: we have sure worked around the issue with LambdaForms, but are we sure this fixed the general problem? John asked me to follow up on that with more concrete benchmark, and I will do that later. In other words, I would like to see the separate issue submitted for this workaround, and record the fix under that issue. It depends on what do you mean by general problem here.
I don't see anything obviously wrong either with U.dAC() or with dependency tracking in VM. What we stumbled upon is an inherent limitation of current dependency tracking implementation. It's not specific to U.dAC(). Regular class loaders can hit similar problem as well. With compiled LFs we ended up in relatively polluted context. Considering how many classes we spin for LFs, validating this context over and over again takes considerable amount of time. The question is how common polluted contexts are and how frequently do we need to validate them. We could think of improving dependency tracking in VM by increasing granularity and narrowing contexts, thus making polluted contexts less likely. If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly. Best regards, Vladimir Ivanov
On 09/17/2014 08:43 PM, Vladimir Ivanov wrote:
I don't see anything obviously wrong either with U.dAC() or with dependency tracking in VM. What we stumbled upon is an inherent limitation of current dependency tracking implementation.
Yes, and so the question from John, which I need to follow up on, if we need to fix that implementation generically, instead of avoiding the problem with point fixes :)
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
Even better, this is even more generic.
If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly.
Yes, please commit the LF fix under the different bug ID, if that is not a hassle? -Aleksey.
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
Even better, this is even more generic. Please, update bug synopsis then.
If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly.
Yes, please commit the LF fix under the different bug ID, if that is not a hassle? Done: 8058661: Compiled LambdaForms should inherit from Object to improve class loading performance https://bugs.openjdk.java.net/browse/JDK-8058661
Best regards, Vladimir Ivanov
On 09/17/2014 08:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
Even better, this is even more generic. Please, update bug synopsis then.
Thanks, did so. Also reassigned the bug, and lowered the priority.
Done: 8058661: Compiled LambdaForms should inherit from Object to improve class loading performance https://bugs.openjdk.java.net/browse/JDK-8058661
Awesome. I have no further comments, the patch is plain and simple. -Aleksey.
On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
Even better, this is even more generic. Please, update bug synopsis then.
If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly.
Yes, please commit the LF fix under the different bug ID, if that is not a hassle? Done: 8058661: Compiled LambdaForms should inherit from Object to improve class loading performance https://bugs.openjdk.java.net/browse/JDK-8058661
I wonder if the Proxy generation code (j.l.r.Proxy) and the method accessor generation code (j.l.r.Method) doesn't have the very same issue.
Best regards, Vladimir Ivanov
Rémi
On 09/17/2014 10:53 PM, Remi Forax wrote:
On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
Even better, this is even more generic. Please, update bug synopsis then.
If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly.
Yes, please commit the LF fix under the different bug ID, if that is not a hassle? Done: 8058661: Compiled LambdaForms should inherit from Object to improve class loading performance https://bugs.openjdk.java.net/browse/JDK-8058661
I wonder if the Proxy generation code (j.l.r.Proxy) and the method accessor generation code (j.l.r.Method) doesn't have the very same issue.
We'll see, Remi, in the course of the original issue: https://bugs.openjdk.java.net/browse/JDK-8058309 Thanks for pointing two new opportunities too look for! -Aleksey
Remi, Good question! I looked into the code and my understanding is that they don't have the same problem as compiled LambdaForms. Proxy doesn't have instance methods (only public/private static), so no unique_concrete_method dependencies in Proxy context. Similar situation with Method: SerializationConstructorAccessorImpl, ConstructorAccessorImpl, MethodAccessorImpl, their supertypes, and interfaces they implement declare megamorphic abstract instance methods. So, I don't expect any unique_concrete_method dependencies in these contexts as well. But it's mostly an educated guess, it'd be great to see some data confirming my observations. Best regards, Vladimir Ivanov On 9/17/14, 10:53 PM, Remi Forax wrote:
On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
It's not specific to U.dAC(). Regular class loaders can hit similar problem as well.
Even better, this is even more generic. Please, update bug synopsis then.
If you want to use 8058309 for dependency tracking improvments in VM, let me know. So far, I got an impression it is about LFs & JSR292 mostly.
Yes, please commit the LF fix under the different bug ID, if that is not a hassle? Done: 8058661: Compiled LambdaForms should inherit from Object to improve class loading performance https://bugs.openjdk.java.net/browse/JDK-8058661
I wonder if the Proxy generation code (j.l.r.Proxy) and the method accessor generation code (j.l.r.Method) doesn't have the very same issue.
Best regards, Vladimir Ivanov
Rémi
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
participants (3)
-
Aleksey Shipilev
-
Remi Forax
-
Vladimir Ivanov