small webrev for hsail allocation stability

Doug Simon doug.simon at oracle.com
Thu Jul 31 14:26:08 UTC 2014


I’ve integrated this change. I inlined the logic for resetting the donor thread to minimize the diff to upstream hotspot.

On Jul 17, 2014, at 12:55 AM, Deneau, Tom <tom.deneau at amd.com> wrote:

> I have submitted a small webrev to solve the following problem.
> 
> The hsail allocation routines borrow TLABs from donor threads.  The design depended on the donor threads not doing any allocation from those TLABs.  The donor threads should be blocked on a CyclicBarrier.  But we have seen in fairly rare cases things which looked like the  donor threads were doing some allocations and interfering with the HSAIL kernel allocations.  Maybe this is related to the "spurious wakeup" described in Object.wait javadocs?
> 
> Anyway, this webrev zeroes out the donor thread tlabs as it copies the fields out into the TlabInfo structure used by the GPU.  (this copy to TlabInfo has always been there, we just didn't zero out the donor thread tlab fields).  Now if the donor thread does spuriously wakeup and needs to allocate anything it will get a new tlab or wait.  If it gets a new tlab, then in the post-kernel cleanup code, we retire that tlab as we copy fields back in to the donor thread.
> 
> Things were definitely more stable with this change.
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-hsail-donor-tlab-zero/webrev/
> 
> -- Tom
> 



More information about the graal-dev mailing list