You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Benjamin Asbach (Jira)" <ji...@apache.org> on 2020/01/25 11:55:00 UTC
[jira] [Commented] (NETBEANS-106) NB classloaders should use fine
grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023525#comment-17023525 ]
Benjamin Asbach commented on NETBEANS-106:
------------------------------------------
[~jtulach], [~lbruun] The upstream issue seems to be fixed: [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184] but I'm a little bit unsure what this means for this issue since there's some more activity on [NETBEANS-58|https://issues.apache.org/jira/browse/NETBEANS-58] but it.
The test [~jlahoda] attached seems to be deleted during jira migration.
> 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: Lars Bruun-Hansen
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists