Time to Safepoint and HotSpot intrinsics
Hohensee, Paul
hohensee at amazon.com
Mon Nov 26 22:16:15 UTC 2018
Also, it's not just intrinsics that have this problem. All counted loops should be "strip-mined" this way. Android JVMs have been doing it for time out of mind because they budget 2-3ms max per 16.67ms frame computation time for stw events.
On 11/26/18, 2:01 PM, "Hohensee, Paul" <hohensee at amazon.com> wrote:
The compiler could estimate the cost of an iteration using some rough pessimistic heuristic and strip mine based on that. Measuring the safepoint time directly is fragile due to inability to find all the hardware platforms that might run the JVM.
Paul
On 11/22/18, 8:07 AM, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-bounces at openjdk.java.net on behalf of aph at redhat.com> wrote:
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
More information about the hotspot-dev
mailing list