[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-graal-dev
Subject:    Re: webrev for hsail compiler safepoints
From:       Doug Simon <doug.simon () oracle ! com>
Date:       2014-04-17 16:30:18
Message-ID: B3D54871-0C13-404B-9FDC-E2DBEE3C3FE4 () oracle ! com
[Download RAW message or body]

Yes, Gilles just pointed that out to me as well. He’ll be pushing a fix soon.

-Doug

On Apr 17, 2014, at 6:13 PM, S. Bharadwaj Yadavalli <bharadwaj.yadavalli@oracle.com> \
wrote:

> Doug,
> 
> The following change made as part of integrating this webrev results in
> 
> Internal Error (/home/bharadwaj/basic-graal/src/share/vm/memory/allocation.cpp:692), \
> pid=2004, tid=139757424736000 #  assert(false) failed: Should not call global \
> operator new 
> When I run BasicPTXTest.
> 
> -------------------------- src/gpu/ptx/vm/gpu_ptx.cpp --------------------------
> @@ -271,7 +271,7 @@
> tty->print_cr("[CUDA] Success: Created context for device: %d", _cu_device);
> }
> 
> -  gpu::initialized_gpu(device_name);
> +  Gpu::initialized_gpu(new Ptx());
> 
> return true;
> GPU_END
> 
> 
> On 04/16/2014 07:43 PM, Doug Simon wrote:
> > 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@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
> > > 
> 


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic