Hi Karen,
Thanks for your feedback.
On 11/12/2012 12:31 PM, Karen Kinnear wrote:
David,
I fully support the concept of a fully concurrent class loader, which allows
parallel defineClass.
I would agree that we deprecate registerAsParallelCapable - starting
deprecation in JDK8.
Okay that seems to be the consensus. I'm obviously way too conservative :)
My memory is that customers asked us for the getClassLoadingLock API so that
they could
do their own internal concurrency controls using the same lock we created, so I
think we need
the blog etc. to explicitly ask for feedback on having this API return NULL or
deprecating it. It does
matter if our customers are using the results.
Okay it would be good to understand this better. Given each parallel
classloader had a different lock per class this really only matters if
they try to get the lock used by one of the existing system
classloaders. Their own parallel loaders will continue to function as
normal.
"Fully concurrent" means custom class loaders that need to protect any
per-class data
do their own internal locking, not that no locks are needed. It means we allow
concurrent defineClass, with the defineClassIfNotPresent semantics.
Is that a question or a statement? :) A fully concurrent loader needs no
'framework' support for synchronizing classloading. That could be
because it uses its own locks, or that no locks are needed.
Question on the source code: registerAsFullyConcurrent has confusing comment -
do the super classes all need to be parallel capable? Or do the super classes
all need
to be FullyConcurrent? I assume the latter, so just fix the comments.
Actually it is the former. There's no reason to require that all
superclasses be fully-concurrent. Of course a given loaders degree of
concurrency may be constrained by what it's supertype allows, but
there's no reason to actually force all the supertypes to be
fully-concurrent: it is enough that they are at least all parallel capable.
Thanks,
David
thanks,
Karen
On Dec 9, 2012, at 11:08 PM, David Holmes wrote:
Thanks for the comments Mandy.
On 8/12/2012 9:46 AM, Mandy Chung wrote:
On 12/5/12 3:59 AM, David Holmes wrote:
Java 7 introduced support for parallel classloading by adding to each
class loader a ConcurrentHashMap, referenced through a new field,
parallelLockMap. This contains a mapping from class names to Objects
to use as a classloading lock for that class name. This scheme has a
number of inefficiencies. To address this we propose for Java 8 the
notion of a fully concurrent classloader ...
This is a fairly simple proposal that I've written up as a blog entry:
https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
It's a good and simple proposal and also handles the backward
compatibility nicely.
I think having getClassLoadingLock() to return null for a fully
concurrent loader is a good idea. In case if any code synchronizes on
the returned value after migrating to fully concurrent class loader, it
will catch such usage (it might be very rare)/
The only glitch with this is that a concurrent loader is-a parallel loader, so
anyone trying work with an arbitrary parallel loader will encounter a problem
with a concurrent loader if they don't make their code concurrent-loader aware.
I am hopeful that the parallelLockMap is only being used internally by the
classloaders themselves, and that there are no, or very few, external clients.
I agree with Alan's suggestion - we should consider deprecating
registerAsParallelCapable.
Definitely a consideration, though as I said perhaps for 9 rather than 8.
Thanks,
David
Mandy
