ForkJoinPool
—

These changes will require a feature extension request and CCC.

Why does the default worker thread construction require the permission 
“getClassLoader” but the innocuous worker thread construction does not? Both 
result in a call to getSystemLoader.

Unless there is some restriction in Thread’s constructor perhaps it is better 
to push the doPriv blocks to the special constructors of ForkJoinWorkerThread  
that way there is less distance between the permissions and the actions?


ConcurrentLinkedDeque
—

1427                 if ((e = p.item) != null)
1428                     ((a != null) ? a : (a = new Object[n]))[i++] = e;

This is awfully hard to read. Is it really worth it to save an extra line or 
two?


ConcurrentLinkedQueue
—

 199         void appendRelaxed(Node<E> next) {

Recommend using “appendPlain” (same in LinkedTransferQueue).


1057     static final VarHandle ITEM;
1058     static final VarHandle NEXT;

Suggest a comment as to why they are package private, due to access via a 
nested class. (Same in LinkedTransferQueue).


ConcurrentSkipListSet
—

  76  * <p>Bulk operations that add, remove, or examine multiple elements,
  77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
  78  * are <em>not</em> guaranteed to be performed atomically.
  79  * For example, a {@code forEach} traversal concurrent with an {@code
  80  * addAll} operation might observe only some of the added elements.

toArray was removed, and it’s not atomic. Same for many other cases.


ThreadPoolExecutor
—

 131     static void spinAwait(Supplier<Boolean> waitingForGodot) {
 132         for (int spins = 0;;) {
 133             if (waitingForGodot.get())
 134                 return;


:-) "Let's wait till we know exactly how we stand.”.


ThreadPoolExecutorSubclassTest
—

 690                 Callable<Boolean> task = new CheckedCallable<Boolean>() {

 756                 Callable<Boolean> task = new CheckedCallable<Boolean>() {


Diamond on the RHS.

Paul.





> On 31 Jan 2017, at 08:58, Martin Buchholz <marti...@google.com> wrote:
> 
> Another too-big too-scary wave for this phase of jdk9, but I still think it 
> should go in.  Or we can put into jdk10 first, then down-integrate into jdk9 
> (when??).
> 
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> ---
> 
> concurrent-collections has spliterator bug fixes and fixes for rare but 
> serious performance problems in LinkedTransferQueue.
> And it continues the optimization of bulk collection methods begun months ago.
> 
> ---
> 
> common-pool has a fix for unwanted ClassLoader retention via an inaccessible 
> thread context class loader.
> 
> This differs from Chris' approach of setting the internal TCCL to null.  
> Instead, it unifies the handling in the default FJTF and the innocuous FJTF 
> by simply setting the TCCL to the system class loader.  Except that the 
> innocuous TCCL cannot be reset by a task.
> 

Reply via email to