Using non-parallel custom class loaders for Layer configurations
David M. Lloyd
david.lloyd at redhat.com
Fri Sep 9 16:29:47 UTC 2016
On 09/09/2016 11:26 AM, Alan Bateman wrote:
> On 08/09/2016 23:29, David M. Lloyd wrote:
>> Is it not necessary that any class loader in use by a Layer must be
>> parallel-capable? Otherwise it seems like deadlocks could occur in
>> certain situations when there are references that are cyclic with
>> respect to class loaders mapped by the mapping function.
> There aren't cycles in readability graph, at least not at construction
> time. They might arise later due to reflective use of addReads but that
> shouldn't change the class loader delegation graph. So I'm curious if
> you are actually running into an issue or not? I can easily come up with
> a mapping to loaders to force this but it would be unusual mapping.
> BTW: I'm not opposed to exposing isParallelCapable, just curious if this
> is something that you are actually running into or not.
No, I've only run into this with our module system which is separate
from Jigsaw, but I was examining this code recently and I was surprised
to see that Jigsaw did not take this into account.
I don't think there needs to be a readability cycle between modules for
this to be a potential problem; there only has to be a cycle between
class loaders. So if you (for whatever reason) put half of your modules
in one class loader and half in another, and those modules refer to one
another, I think you might have a problem if those modules refer to one
another and the class loaders are not parallel capable. But like I said
that's just a hypothesis.
More information about the jigsaw-dev