Bug ID: JDK-8155023 [JVMCI] jdk.vm.ci needs to securely export services

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 9

Priority: P1
Status: Closed
Resolution: Fixed

Submitted: 2016-04-25
Updated: 2017-08-15
Resolved: 2016-05-11

JDK 9
9 b122Fixed

A JVMCI based compiler will implement providers for certain services defined by JVMCI:

jdk.vm.ci.runtime.JVMCICompilerFactory
jdk.vm.ci.hotspot.HotSpotVMEventListener
jdk.vm.ci.hotspot.events.EventProvider

A JVMCI based compiler must be deployed as a module (since JVMCI is a module) and so will have the relevant `provides` clauses in its module-info for these providers. The -XaddExports VM option cannot be used to export the service type to the service provider module since module resolution and binding (apparently) doesn't take -XaddExports into account.

In addition, the utility jdk.vm.ci.services.Services needs to be visible to JVMCI compilers as it is the abstraction by which services that may have JVMCI providers are looked up. This utility abstracts over whether the standard ServiceLoader (in JDK9) or some other JVMCI specific mechanism is used (in JDK8).

hotspot/test/compiler/jvmci tests cover this.
15-08-2017
http://cr.openjdk.java.net/~dnsimon/8155023/
04-05-2016
Adding [~alanb].
02-05-2016
While JVMCI is primarily for compiler implementors, its API is also useful for other applications. For example, a utility for performing analysis on the state of the VM after running some sample code or a benchmark may find the API useful. Such clients do not necessarily implement any of the JVMCI services mentioned above. As such, there needs to be another entry point for requesting access to the JVMCI API. This entry point also needs to be callable from pre-JDK9 JVMCI clients such as Graal. The proposed entry point is: /** * Performs any required security checks and dynamic reconfiguration to allow the module of a * given class to access the classes in the JVMCI module. * * Note: This API exists to provide backwards compatibility for JVMCI clients compiled against a * JDK release earlier than 9. * * @param requestor a class requesting access to the JVMCI module for its module * @throws SecurityException if a security manager is present and it denies * {@code RuntimePermission("jvmci")} */ public static void exportJVMCITo(Class<?> requestor) In JDK8, this method is empty since security in JVMCI-8 is achieved via alternative mechanisms. In JDK9, the implementation would be: public static void exportJVMCITo(Class<?> requestor) { SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(new RuntimePermission("jvmci")); } Module jvmci = jdk.vm.ci.services.Services.class.getModule(); for (String pkg : jvmci.getPackages()) { // Export all JVMCI packages dynamically instead // of requiring a long list of -XaddExports // options on the JVM command line. jvmci.addExports(pkg, requestor.getModule()); } } Since jdk.vm.ci.services is already exported by jdk.vm.ci's module-info, it's suggested to add this method to jdk.vm.ci.services.Services.
01-05-2016
To ensure only the minimal API is publicly exported, all exported JVMCI service types will be put into "services" packages that contain nothing but the exported services and their associated types. In addition, all service types will be made into abstract classes that perform security checks upon installation (like FileSystemProvider does). These are the refactored JVMCI service entry points: jdk.vm.ci.runtime.services.JVMCICompilerFactory jdk.vm.ci.hotspot.services.EventProvider.java jdk.vm.ci.hotspot.services.HotSpotVMEventListener Along with the existing entry: jdk.vm.ci.services.Services
28-04-2016

Blocks :	JDK-8152311 - [JVMCI] allow JVMCI compiler to change the compilation policy for a method
Blocks :	JDK-8156034 - [JVMCI] Notify the jvmci compiler on completion of a bootstrap
Duplicate :	JDK-8155622 - make JVMCICompilerFactory an abstract class with security checks