Time to Safepoint and HotSpot intrinsics

[Hohensee, Paul]

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