webrev for hsail compiler safepoints

[Doug Simon]

Hi Eric,

This approach of making safepoints cause HSAIL deopts looks reasonable to me.

I’ve integrated your patch with the following changes:

o Renamed HSAILControlFlow.AbstractDeoptimization to HSAILControlFlow.DeoptimizingOp (mimicking the HIR DeoptimizingNode)
o To avoid the HSAIL specific code in gpu.cpp, I:
  - renamed the C++ gpu class to Gpu
  - added notice_safepoints() and ignore_safepoints() virtual methods to Gpu, and
  - made Hsail override these virtual methods
o Made the cleanup suggested by the comment “// todo: define these in HSAIL.java"

-Doug

On Apr 15, 2014, at 11:23 PM, Caspole, Eric <Eric.Caspole at amd.com> wrote:

> Hi everybody,
> I put up a new webrev for supporting compiler safepoints in HSAIL. This is an incremental change using the HSAIL deoptimization feature, so if a safepoint is detected in the kernel it will deoptimize back to CPU to complete the workitems. This will help avoid long running loops in kernels from halting the CPU threads in the event a safepoint is required during the kernel execution.
> 
> http://cr.openjdk.java.net/~ecaspole/hsail_comp_safepoints/webrev/
> 
> There were already about 12 tests in the hsail tests that cause compiler safepoints to be emitted. Also we have an internal app with long running workitems which was a good test. I added a -XX:+UseHSAILSafepoints which is true by default, so we can experiment with it.
> Let me know your comments.
> Thanks,
> Eric
>