Time to Safepoint and HotSpot intrinsics

[Andrew Haley]

In several places in HotSpot we have intrinsics that can block for a
long time. The most extreme cases of this are some crypto accelerators
that are only bounded by the maximum size of a byte array, 2
gigabytes.  This leads to extended time to safepoint, where every
thread has to wait for the intrinsic to complete. It can be on the
order of seconds.

We could simply limit the maximum buffer size of the intrinsic and
wrap it in a Java loop with (as usual) a safepoint check. This does
not noticeably slow anything down, but it does solve the TTSP
problem. This can be important when multi-megabyte messages are being
encrypted.

The question is, then, what is the maximum tolerable time that an
intrinsic should block? I suggest that it should be on the order of a
millisecond, particularly when garbage collectors are trying to drive
down the safepoint time. This corresponds to AES/GCM encryption of
about 128k - 256k batches on a decently fast 64-bit processor. Doing
encryption in batches like this doesn't significantly slow down
anything. It is, in a sense, like loop strip mining for primitives.

So, I'm proposing two things: firstly we fix the intrinsics that can
block for extended periods, and we then declare that no new intrinsic
code will be accepted without the worst case safepoint time being
measured and found to be acceptable.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671