Debug Scope when on other thread

[Doug Simon]

Ok, looks good. I’ll integrate it.

On Feb 19, 2014, at 3:46 PM, Caspole, Eric <Eric.Caspole at amd.com> wrote:

> Hi Doug,
> I updated the webrev in http://cr.openjdk.java.net/~ecaspole/other_thd_debuginfo/webrev.01/
> In this one I added the "only once" check and tried it in different main thread/other thread/two different kernels compiled on other thread situations and it all worked.
> Thanks,
> Eric
> 
> ________________________________________
> From: Doug Simon [doug.simon at oracle.com]
> Sent: Tuesday, February 18, 2014 12:35 PM
> To: Caspole, Eric
> Cc: graal-dev at openjdk.java.net
> Subject: Re: Debug Scope when on other thread
> 
> On Feb 18, 2014, at 5:53 PM, Caspole, Eric <Eric.Caspole at amd.com> wrote:
> 
>> Hi everybody,
>> We have 2 sample apps that use our Stream API forEach() based offload. In one sample, the Graal compiler runs on the main thread when invoked by the app. In the other sample, Graal runs on the AWT-EventQueue-0 due to the design of the sample's screen drawing code.
>> 
>> In this second app, Graal debug flags like -G:Log=CodeGen do not work. It looks like the debug flag state is stored in thread locals, but the the initialization for that is only done once for the main thread, called from VMToCompilerImpl.startCompiler(). Later when we use Graal from the AWT thread, its debug flag state config is null. Otherwise everything seems to be working fine.
>> 
>> I made a very simple webrev to work around this problem, but I don't think it is the 'real' fix -
>> http://cr.openjdk.java.net/~ecaspole/other_thd_debuginfo/webrev/
>> 
>> Generally, does an app using Graal need to do some more initialization that we are not doing yet when on another thread besides the main thread, or can this be automagically done under the covers in Graal? What is the right way to fix this specific problem?
> 
> As you have observed, any thread using the Debug facilities, needs to initialize the debug configuration per thread. For the main thread and the CompilerThreads, this is currently taking care of. Your solution is probably the best for now until we consider adding supporting for some kind of default config initialization factory.
> 
> In your fix, it’s probably worth guarding the call to DebugEnvironment.initialize() to ensure it’s only done once per thread.
> 
> -Doug
>