estimate

[Gilles Duboscq]

Tom,

This experiment, as well as what is foreseen for PTX, seem to indicate
that we don't need a nmethod for the GPU kernels themselves.
The kernel in turn may need to know about a special nmethod which is
used for example to implement deoptimization.

This special nmethod needs to 'interface' with the VM because it
potentially has an unexpected signature (i.e. its signature is not the
signature of the method it pretends to be). For this i would propose
to have long pointer to a "custom c2i" in HotSpotNMethod or in a new
subclass of HotSpotNMethod. This would be picked up automatically by
JavaCall when using our "alternative nmethod" mechanism.

An other thing I'm not yet sure about is if we need the
ExternalCompilationResult at all. I currently transmit the "host
graph" (which is built during HSAIL compilation) through it but maybe
there is a better solution.

Regarding coordination, I don't know if/when you want to push the
changes for deoptimization support. If you want to push them, we
should prepare a webrev which combines your work and what I did.

-Gilles

On Mon, Feb 10, 2014 at 5:10 PM, Tom Deneau <tom.deneau at amd.com> wrote:
> Gilles --
>
> This is working well for us and it also passes tests on some early HSA hardware we have.
>
> Let me know what kind of coordination you refer to below.
> I guess there's not yet quite a clean line between the hsail-dependent part and the hsail-independent part.
> Maybe you can send a proposal on what you would like for such an interface.
>
> -- Tom
>
>> -----Original Message-----
>> From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of
>> Gilles Duboscq
>> Sent: Friday, February 07, 2014 5:13 AM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: estimate
>>
>> After some debugging, it now passes all the HSAIL unit tests.
>>
>> I attach a diff, it's based on your patch (v4 if i remember correctly)
>> itself applied on graal a9604b40f5e7.
>>
>> This diff contains a number of changes to HotSpot and Graal outside the
>> strict context of HSAIL which were necessary to make this work.
>> Going forward, I'll first integrate those changes (the ones that are not
>> strictly HSAIL) into our repo but then we need to coordinate to polish
>> and push both your and my changes.
>>
>> I think we should remove the hsail-deopt-info support
>> (HSAILCodeInstaller and HSAILLocation) since it is not needed any more.
>>
>> -Gilles
>>
>> On Fri, Feb 7, 2014 at 10:29 AM, Gilles Duboscq <duboscq at ssw.jku.at>
>> wrote:
>> > Hello Tom,
>> >
>> > I now have code for the whole depot path. I am now in the process of
>> > debugging the access to the HSAILFrame from the host code (some of the
>> > indices I'm using seem to be off).
>> > For now, besides some indices problem, the host code looks correct and
>> > I can get HotSpot to execute it when there is a hsail deopt. Also
>> > HotSpot can walk the stack properly when the host code triggers the
>> > actual deopt and it sees the correct VM->Java transitions.
>> >
>> > The changes should simplify the code a bit since I don't need the
>> > special code installer or anything around that. All debug info are now
>> > host debug info.
>> >
>> > I'm hoping that debugging will work out today but in any case I will
>> > send you a patch today. Hopefully it should pass at least some of the
>> unit tests.
>> >
>> > -Gilles
>> >
>> > On 6 Feb 2014 21:38, "Deneau, Tom" <tom.deneau at amd.com> wrote:
>> >>
>> >> Hi Gilles --
>> >>
>> >>
>> >>
>> >> Again to help with our internal planning, can you give us a rough
>> >> estimate of how far away the gpu-deopt-to-interpreter infrastructure
>> might be?
>> >>
>> >>
>> >>
>> >> And is there anything we can do on our side to prepare for it?
>> >>
>> >>
>> >>
>> >> -- Tom
>> >>
>> >>