Webrev for unloading kernels after class unloading

Eric Caspole eric.caspole at amd.com
Tue Jul 22 14:11:05 UTC 2014


OK, I will see how to use javac API or ASM to compile the embedded class.


On 07/22/2014 07:26 AM, Gilles Duboscq wrote:
> I agree, it would be better to generate the class.
> If you do it with Javac, please tell me because it may require a small
> mx modification (providing libraries from the JDK: we already have JRE
> libraries but JDK is slightly diffrerent). If you prefer ASM you can
> declare it like this:
>
> library at ASM@path=lib/asm-5.0.3.jar
> library at ASM@urls=http://lafo.ssw.uni-linz.ac.at/graal-external-deps/asm-5.0.3.jar,http://central.maven.org/maven2/org/ow2/asm/asm/5.0.3/asm-5.0.3.jar
> library at ASM@sha1=dcc2193db20e19e1feca8b1240dbbc4e190824fa
> library at ASM@sourcePath=lib/asm-5.0.3-sources.jar
> library at ASM@sourceSha1=f0f24f6666c1a15c7e202e91610476bd4ce59368
> library at ASM@sourceUrls=http://lafo.ssw.uni-linz.ac.at/graal-external-deps/asm-5.0.3-sources.jar,http://central.maven.org/maven2/org/ow2/asm/asm/5.0.3/asm-5.0.3-sources.jar
>
> Overall the change looks good but i'm not so happy with the fact that
> that we use the "external" flag in this way. Maybe it's just a naming
> problem and we should just rename it to "gpu" such that we rather have
> a concept of "gpu nmethods" (this renaming would anyway be for a
> different changeset).
>
> -Gilles
>
> On Tue, Jul 22, 2014 at 12:03 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
>> Hi Eric,
>>
>> Seems ok. Embedding the class file as a binary in the test is odd though. Shouldn’t it be possible to compile it from within the test with the javac api?
>>
>> igor
>>
>> On Jul 21, 2014, at 1:52 PM, Caspole, Eric <Eric.Caspole at amd.com> wrote:
>>
>>> Hi everybody,
>>> I put up a new webrev that allows GPU kernels to be unloaded when their class loader context gets unloaded, when used with the latest Sumatra JDK.
>>>
>>> http://cr.openjdk.java.net/~ecaspole/unload_kernels/01/
>>>
>>> There was already a notion of "external nmethod" in the Graal side and in the nmethod, but they had not been connected before. Here, the kernel nmethods get the external flag set, and if the class loader context of the kernel is getting unloaded it will call to the GPU::Hsail class to unload the kernel from the HSA runtime, using the API in the latest version of Okra we added last week. There is a new test case in the webrev to create an offloadable kernel in a custom class loader and see that it gets Gc-ed and collected using jmx APIs.
>>>
>>> One shortcoming in this version I want to get comments on is how to distinguish HSAIL vs PTX nmethods so the unload code calls the correct GPU runtime to do the dispose. We don't use "make not entrant" style flagging of kernel nmethods but this change is the first step in making the kernels more proper members in the code cache.
>>>
>>> I also added the call to dispose the HSA GPU context similar to what the PTX version had for a long while now.
>>> Let me know your comments,
>>> Thanks,
>>> Eric
>>>
>>


More information about the graal-dev mailing list