Time to Safepoint and HotSpot intrinsics
hohensee at amazon.com
Fri Nov 30 14:28:34 UTC 2018
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.
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
> 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.
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