Intrinsic methods and time to safepoint

[Roland Westrelin]

> I believe we should have a policy to cover how long an intrinsic can
> delay without responding to a safepoint, and that it should be in the
> millisecond range. It would make almost no difference to the
> performance of encryption if chunks handles by a fast intrinsic were,
> say, about a megabyte. The difference in performance is so small as to
> be immeasurable, and the improvement in the performance of other threads
> is vast.

I agree with you (seems like a no brainer) but I have a couple comments
about implementation details.

Those intrinsics usually call some stub. It's not possible AFAICT, to
have the safepoint in the stub itself. So we need some loop that
repeatedly calls the stub. That loop can either be added 1) by the JIT
as IR when the intrinsic is expanded 2) in java code, that is java
library code needs to be refactored.

2) would seem much easier to implement and would work for both c1 and c2
(if some of these intrinsics end up implemented by c1).

Also a note of caution about loop strip mining: it doesn't have a model
for what the loop body costs. So it blindly assumes all loop bodies can
be run for 1000 iterations (by default) between safepoints. Unless I'm
missing something, with a stub running for 1ms, delays between safepoint
could still be 1s.

Roland.