[
https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lbruun updated NETBEANS-106:
----------------------------
Description:
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.)
was:
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 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.)
> 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
>
> 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)
