> On Jan 26, 2017, at 3:13 AM, Doug Simon <doug.si...@oracle.com> 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 required > to get through a bootstrap (i.e., java -server > -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI > -XX:+UseJVMCICompiler -version) is show below (annotated with comments > denoting the methods requiring the permissions): > > :
Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? > There’s no guarantee that this is all the permissions required since not all > code paths are exercised during bootstrap. > >> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not >> granted with any permission. > > Neither of those tools create code and install it in the VM. I don’t think a > fine grained SecurityManager policy makes sense for a VM compiler since it > could subvert security by compiling/installing malicious code. That is, a VM > compiler has to be a trusted component. Keep in mind that user code cannot > get to jdk.vm.compiler. My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. grant codeBase "jrt:/jdk.vm.compiler" { permission java.security.AllPermission; }; If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? Mandy