--- a/jdk/src/java.base/share/classes/java/util/concurrent/Exchanger.java	Tue Jul 26 10:02:05 2016 -0700
+++ b/jdk/src/java.base/share/classes/java/util/concurrent/Exchanger.java	Tue Jul 26 10:06:19 2016 -0700
@@ -235,22 +235,16 @@
      * As is too common in this sort of code, methods are monolithic
      * because most of the logic relies on reads of fields that are
      * maintained as local variables so can't be nicely factored --
-     * mainly, here, bulky spin->yield->block/cancel code), and
-     * heavily dependent on intrinsics (VarHandles) to use inlined
-     * embedded CAS and related memory access operations (that tend
-     * not to be as readily inlined by dynamic compilers when they are
-     * hidden behind other methods that would more nicely name and
-     * encapsulate the intended effects). This includes the use of
-     * setRelease to clear fields of the per-thread Nodes between
-     * uses. Note that field Node.item is not declared as volatile
-     * even though it is read by releasing threads, because they only
-     * do so after CAS operations that must precede access, and all
-     * uses by the owning thread are otherwise acceptably ordered by
-     * other operations. (Because the actual points of atomicity are
-     * slot CASes, it would also be legal for the write to Node.match
-     * in a release to be weaker than a full volatile write. However,
-     * this is not done because it could allow further postponement of
-     * the write, delaying progress.)
+     * mainly, here, bulky spin->yield->block/cancel code.  Note that
+     * field Node.item is not declared as volatile even though it is
+     * read by releasing threads, because they only do so after CAS
+     * operations that must precede access, and all uses by the owning
+     * thread are otherwise acceptably ordered by other operations.
+     * (Because the actual points of atomicity are slot CASes, it
+     * would also be legal for the write to Node.match in a release to
+     * be weaker than a full volatile write. However, this is not done
+     * because it could allow further postponement of the write,
+     * delaying progress.)
      */
 
     /**

--- a/jdk/src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java	Tue Jul 26 10:02:05 2016 -0700
+++ b/jdk/src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java	Tue Jul 26 10:06:19 2016 -0700
@@ -60,7 +60,7 @@
         }
     }
 
-    private volatile Object value;
+    private volatile V value;
 
     /**
      * Creates a new AtomicReference with the given initial value.
@@ -83,9 +83,8 @@
      *
      * @return the current value
      */
-    @SuppressWarnings("unchecked")
     public final V get() {
-        return (V)value;
+        return value;
     }
 
     /**

--- a/jdk/test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java	Tue Jul 26 10:02:05 2016 -0700
+++ b/jdk/test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java	Tue Jul 26 10:06:19 2016 -0700
@@ -42,6 +42,7 @@
 
 import java.util.concurrent.ArrayBlockingQueue;
 import java.util.concurrent.BlockingQueue;
+import java.util.concurrent.LinkedBlockingDeque;
 import java.util.concurrent.LinkedBlockingQueue;
 import java.util.concurrent.LinkedTransferQueue;
 import java.util.concurrent.SynchronousQueue;
@@ -50,9 +51,11 @@
 public class PollMemoryLeak {
     public static void main(String[] args) throws InterruptedException {
         final BlockingQueue[] qs = {
+            new LinkedBlockingDeque(10),
             new LinkedBlockingQueue(10),
             new LinkedTransferQueue(),
             new ArrayBlockingQueue(10),
+            new ArrayBlockingQueue(10, true),
             new SynchronousQueue(),
             new SynchronousQueue(true),
         };