The java.lang.ref.Reference class has a private Lock class and static lock instance of that class. It is documented as providing synchronization with the garbage collector, with a warning that one must not allocate any new objects while holding this lock.
The Reference class has a tryHandlePending member function containing a synchronized block on that lock object.
Within that synchronized block is a comment indicating some of the code therein is written in a particular way because the instanceof operator might throw OutOfMemoryError. That would seem to imply that instanceof can allocate new objects, which is contrary to the requirement on holders of the lock object.
The Reference class also contains a static initialization to ensure the relevant class for that instanceof (java.lang.misc.Cleaner) has been loaded, with the apparent intent of ensuring that instanceof does *not* need to allocate memory. But if that's so, then it would seem that any code contortions to account for that possibility are unnecessary.
I'm not sure whether there is a bug in the code or not. At the very least, there are problems with the comments.
The Reference class has a tryHandlePending member function containing a synchronized block on that lock object.
Within that synchronized block is a comment indicating some of the code therein is written in a particular way because the instanceof operator might throw OutOfMemoryError. That would seem to imply that instanceof can allocate new objects, which is contrary to the requirement on holders of the lock object.
The Reference class also contains a static initialization to ensure the relevant class for that instanceof (java.lang.misc.Cleaner) has been loaded, with the apparent intent of ensuring that instanceof does *not* need to allocate memory. But if that's so, then it would seem that any code contortions to account for that possibility are unnecessary.
I'm not sure whether there is a bug in the code or not. At the very least, there are problems with the comments.
- relates to
-
JDK-6857566 (bf) DirectByteBuffer garbage creation can outpace reclamation
- Closed
-
JDK-7038914 VM could throw uncaught OOME in ReferenceHandler thread
- Closed
-
JDK-8149925 We don't need jdk.internal.ref.Cleaner any more - part 1
- Resolved