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

2017-02-07 Thread Doug Simon
> On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote: > > AOT tool jaotc does not run with SecurityManager. We assume it runs in secure > environment and it does not access any external resources. Great. Can I now consider this change reviewed and integrate it? -Doug

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

2017-02-07 Thread Doug Simon
> On 1 Feb 2017, at 20:54, Sean Mullan wrote: > > Couple of comments: > > - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted > AllPermission and does not need an entry in default.policy. Thanks - I removed it. > - all internal APIs in the

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

2017-02-02 Thread Alan Bateman
On 02/02/2017 02:12, Mandy Chung wrote: On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy:

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

2017-02-01 Thread Mandy Chung
> On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: > > I’ve reworked the webrev as requested to make jdk.vm.compiler a > non-upgradeable platform module, this allowing it to be mentioned in > default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ Looks good.

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

2017-02-01 Thread Sean Mullan
On 2/1/17 4:27 PM, Doug Simon wrote: Can I now consider this change reviewed and integrate it? Yes. --Sean

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

2017-02-01 Thread Vladimir Kozlov
AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Thanks Vladimir > On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: > > >> On 1 Feb 2017, at 20:54, Sean Mullan

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

2017-02-01 Thread Sean Mullan
Couple of comments: - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you

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

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

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

2017-02-01 Thread Doug Simon
I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: http://cr.openjdk.java.net/~dnsimon/8145337/ -Doug > On 30 Jan 2017, at 22:53, Mandy Chung wrote: > >> >> On Jan 30,

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

2017-01-30 Thread Mandy Chung
> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: > > >> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >> >> >>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>> >>> I’ve extended the webrev with that change - please

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

2017-01-30 Thread Doug Simon
> On 30 Jan 2017, at 17:11, Mandy Chung wrote: > > Moving it to platform class loader is okay with me. I’m still unsure if > jdk.vm.compiler should be defined by the boot loader instead and you may want > to look into in a future release. We also want jdk.vm.compiler

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

2017-01-30 Thread Doug Simon
> On 29 Jan 2017, at 20:34, Igor Veresov wrote: > >> >> On Jan 27, 2017, at 3:40 PM, Christian Thalinger >> wrote: >> >>> >>> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: >>> On 26 Jan 2017, at 17:55,

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

2017-01-30 Thread Christian Thalinger
> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: > >> >> On 26 Jan 2017, at 17:55, Mandy Chung wrote: >> >> >>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >>> jdk.vm.compiler is defined by the application

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

2017-01-30 Thread Mandy Chung
> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: > > I’ve extended the webrev with that change - please re-review: > > http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev > +1 > Strangely, there was no existing declaration of jdk.vm.compiler in > Modules.gmk. >

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

2017-01-26 Thread Doug Simon
> On 26 Jan 2017, at 17:55, Mandy Chung wrote: > > >> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >> >>> >>> jdk.vm.compiler is defined by the application class loader and it’s used by >>> AOT tool. I wonder why it has to run with security

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

2017-01-26 Thread Doug Simon
> On 26 Jan 2017, at 03:32, Mandy Chung wrote: > > (dropping jdk9-dev. security-libs is the appropriate list to review security > permission) > >> On Jan 23, 2017, at 1:56 PM, Doug Simon wrote: >> >> Both jdk.vm.ci and jdk.vm.compiler require

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

2017-01-26 Thread Mandy Chung
> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: > >> >> jdk.vm.compiler is defined by the application class loader and it’s used by >> AOT tool. I wonder why it has to run with security manager. > > Without java.security.AllPermission, the policy for jdk.vm.compiler

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

2017-01-25 Thread Mandy Chung
(dropping jdk9-dev. security-libs is the appropriate list to review security permission) > On Jan 23, 2017, at 1:56 PM, Doug Simon wrote: > > Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a > security manager is present. Since neither of these

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

2017-01-25 Thread Doug Simon
Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including