Time to Safepoint and HotSpot intrinsics

[Hohensee, Paul]

My bad on the definition of "intrinsic".

I was thinking of "intrinsic" as a method for which C2 generates specialized IR which would then be subject to optimization (as in library_call.cpp), not hand-coded asm (as in stubGenerator_aarch64.cpp). I don't know how feasible it is to switch from the latter to the former, but imo it would be good to do if we could. Maybe a hybrid approach with the loop structure in IR and specialized operators that emit optimized code sequences for stuff the compile can't figure out. But that's not an immediate fix.

On the maximum time an intrinsic should block, Roland pointed at https://bugs.openjdk.java.net/browse/JDK-8186027. Maybe use the same approach for hand-coded asm, i.e, insert safepoint polls into the hand-coded asm based on LoopStripMiningIter.

Or, are the intrinsics completely separate native methods? If so, your approach sounds good to me.

Thanks,

Paul

On 11/27/18, 2:42 AM, "Andrew Haley" <aph at redhat.com> wrote:

    On 11/26/18 10:01 PM, Hohensee, Paul wrote:
    > The compiler could estimate the cost of an iteration using some rough pessimistic heuristic and strip mine based on that.
    
    But the compiler doesn't see the intrinsics: they are hand-coded assembly
    language.
    
    > Measuring the safepoint time directly is fragile due to inability to find all the hardware platforms that might run the JVM. A671
    
    Sure, but all I'm suggesting is that we take an order-of-magnitude guess
    and apply that to our intrinsics. It does not have to be accurate: in the
    case of encryption the speed difference caused by limiting the number of
    iterations is infinitesimal, but the time to safepoint difference is huge.
    
    IMO, this is a true no brainer.
    
    -- 
    Andrew Haley
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671