[jira] [Comment Edited] (NETBEANS-106) NB classloaders should use fine grained locking

["lbruun (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224806#comment-16224806 ] 

lbruun edited comment on NETBEANS-106 at 11/3/17 9:17 AM:
----------------------------------------------------------

Thanks for quick response. Yes, my example could be shortened. 
I guess I wanted as close as possible to real-life. In your example the Authenticator gets installed while on the EDT which is not what happens in real life. Although it makes absolutely no difference to the example. :)

bq. As far as the deadlock goes, the analysis in NETBEANS-58 is exhaustive. 

I know. I made it. It reflects what I knew then.

bq. Just it should note that the issue is already reported to JDK: JDK-8068184 and that it can be reproduced completely without NetBeans being around. E.g. in my opinion it doesn't make sense to try to fix on NetBeans side.

No, it can't be reproduced without NetBeans, at least not without using a customized classloader. Try out [this minimal Swing example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149]. It doesn't deadlock. Now try executing that example with with {{XX:+AlwaysLockClassLoader}} and you'll see that now it deadlocks. Essentially {{XX:+AlwaysLockClassLoader}} mimics Java pre-7 behavior and mimics what NB does too.  So it is a good non-NB test, I think. I've ranted much about how the JDK people made a mess of it with their change. I retract all of that. From their perspective - with the classloaders in the JDK - they didn't do anything bad. Bottom line:  I haven't been able to recreate the issue outside of NetBeans. The Swing example is my testing of that.  

_You'll need a classloader that locks on the entire classloader for the issue to occur. Since the JDK classloaders  no longer do this as of Java 7, it doesn't happen in standard Java SE application._

At least this has been my conclusion from my tests. 




was (Author: lbruun):
Thanks for quick response. Yes, my example could be shortened. 
I guess I wanted as close as possible to real-life. In your example the Authenticator gets installed while on the EDT which is not what happens in real life. Although it makes absolutely no difference to the example. :)

bq. As far as the deadlock goes, the analysis in NETBEANS-58 is exhaustive. 

I know. I made it. It reflects what I knew then.

bq. Just it should note that the issue is already reported to JDK: JDK-8068184 and that it can be reproduced completely without NetBeans being around. E.g. in my opinion it doesn't make sense to try to fix on NetBeans side.

No, it can't be reproduced without NetBeans. Try out [this minimal Swing example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149]. It doesn't deadlock. Now try executing that example with with {{XX:+AlwaysLockClassLoader}} and you'll see that now it deadlocks. Essentially {{XX:+AlwaysLockClassLoader}} mimics Java pre-7 behavior and mimics what NB does too.  So it is a good non-NB test, I think. I've ranted much about how the JDK people made a mess of it with their change. I retract all of that. From their perspective - with the classloaders in the JDK - they didn't do anything bad. Bottom line:  I haven't been able to recreate the issue outside of NetBeans. The Swing example is my testing of that.  

_You'll need a classloader that locks on the entire classloader for the issue to occur. Since the JDK classloaders  no longer do this as of Java 7, it doesn't happen in standard Java SE application._

At least this has been my conclusion from my tests. 



> NB classloaders should use fine grained locking
> -----------------------------------------------
>
>                 Key: NETBEANS-106
>                 URL: https://issues.apache.org/jira/browse/NETBEANS-106
>             Project: NetBeans
>          Issue Type: Bug
>            Reporter: lbruun
>            Priority: Major
>
> In order to avoid issues such as NETBEANS-58 the NB classloaders should use fine grained locking. (possibly only needed on System Classloader)
> Background:  At the time when the NB classloaders were created the general consensus at the time was that a proper classloader used locking at the level of the classloader itself. This was also how the classloaders in the JDK worked. However, in Java 7 this [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. The JDK classloaders started using more fine grained locking. But the NB classloaders didn't follow suit. (it is not exactly an inheritable feature)
> This means we are now in a situation were deadlocks occur in NB code which cannot be reproduced with only the JDK. One such case is JDK-8068184 which causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix problems that occur only in NB code.
> What I propose is that a more fine grained locking mechanism is used. Look to the JDK for inspiration. This will solve such deadlock issues. I don't think it is necessary to actually claim that it is now fully multi-thread safe by calling [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. This can be left for a later exercise. First step is to remove the lock on the classloader as a whole.
> NETBEANS-58 contains a simple [minimal example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] which can be used as a measure of success. Once an NB application can use the pattern in the example without freezing then we have accomplished the goal.
>  
> (I'm personally not confident with fiddling with the NB classloaders. Scares the sh.. out of me because I know it is the heart of the platform. So won't come up with a PR. Sorry.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)