RFR[13]: 8226366: Excessive ServiceThread wakeups for OopStorage cleanup

[Kim Barrett]

Please review this change to OopStorage's notifications to the ServiceThread
to perform empty block deletion.  The existing mechanism (introduced by
JDK-8210986) is driven by entry allocation, and may arbitrarily delay such
cleanup, or alternatively may be much too enthusiastic about waking up the
ServiceThread.

The new mechanism does not depend on allocations.  Instead, a new safepoint
cleanup task is used to (irregularly) check for pending requests and notify
the ServiceThread.  That notification has a time-based throttle, and also
avoids duplicate notifications.  Also, requests are now only recorded for
to-empty transitions and not for full to not-full transitions.

Changed the work limit for delete_empty_blocks to have a small surplus to
avoid some common cases with small number of blocks leading to unnecessarily
spinning the ServiceThread.

While making these changes, noticed and fixed a problem in block allocation
that could result in a mistaken report of allocation failure.

CR:
https://bugs.openjdk.java.net/browse/JDK-8226366

Webrev:
http://cr.openjdk.java.net/~kbarrett/8226366/open.00/

Testing:
mach5 tier1-5

Locally ran gc/stress/TestReclaimStringsLeaksMemory.java with some extra
logging and verified that the number of ServiceThread notifications was
reduced by a *lot*, down to something reasonable.