RFR(XS): 8229236: CriticalJNINatives: dll handling should be done in native thread state

[Doerr, Martin]

Hi Dean and David,

thanks for your feedback.

> Hi Martin.  Making an exception for this code makes me a little
> nervous.  It looks like with a little refactoring the problem could go
> way: move the call to method->critical_native_function() up into
> AdapterHandlerLibrary::create_native_wrapper() before the lock is entered.
I had already thought about this. Disadvantage is that several threads can perform the same dll lookup concurrently.
But I guess we can live with that.

> Further, doing I/O while holding a lock seems like a bad idea anyway, so 
> if this call can be done before the lock is acquired as Dean suggested, 
> I think that would be a much better solution.
I'm not convinced that it's always a bad idea to hold a lock while performing I/O.
At least if the duration is not completely unpredictable and the lock is not used for anything critical, it may be ok.
But I don't like the exception to allow a lock only for this case, either.

Here's the new version:
http://cr.openjdk.java.net/~mdoerr/8229236_critNat_resolution/webrev.01/

Please review.

Best regards,
Martin