RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

Doug Simon doug.simon at oracle.com
Mon Jan 30 21:36:10 UTC 2017


> On 30 Jan 2017, at 21:55, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Jan 30, 2017, at 10:38 AM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>> I’ve extended the webrev with that change - please re-review:
>> 
>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev
>> 
> 
> +1

Thanks. Is that a “Reviewed”?

I think I should get at least one sign-off from the security team.

Also, since this is effectively making jdk.vm.compiler an upgradeable module, what’s the implication for it being a hash-checked module? It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448.

-Doug

> 
>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.
>> 
> 
> Default is to be defined by the application class loader.  The build will find all modules from the source. There is no need to list all modules.
> 
>> BTW, I never answered your question:
>> 
>> "How does JVMCI call out to jdk.vm.compiler?  does it load classes using Class::forName with the system class loader?”
>> 
>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader.
> 
> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader.
> 
> Mandy



More information about the security-dev mailing list