You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Lars Bruun-Hansen (Jira)" <ji...@apache.org> on 2020/01/25 15:59:00 UTC
[jira] [Comment Edited] (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=17023597#comment-17023597 ]
Lars Bruun-Hansen edited comment on NETBEANS-106 at 1/25/20 3:58 PM:
---------------------------------------------------------------------
Well, currently this is only "fixed" in JDK 14.
The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important.
I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one.
Therefore I still believe in this ticket.
was (Author: lbruun):
Well, currently this is only "fixed" in JDK 14.
The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as exemplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important.
I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one.
Therefore I still believe in this ticket.
> 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