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


Reply via email to