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

2017-02-02 Thread Doug Simon
will allow it to run without needed an extra policy file? -Doug > On 2/1/17 6: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-02 Thread Doug Simon
> >> On Jan 30, 2017, at 1:36 PM, Doug Simon <doug.si...@oracle.com> wrote: >> >> >>> On 30 Jan 2017, at 21:55, Mandy Chung <mandy.ch...@oracle.com> wrote: >>> >>> >>>> On Jan 30, 2017, at 10:38 AM, Doug Simon <doug.si...@

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

2017-02-02 Thread Doug Simon
> On 30 Jan 2017, at 21:55, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Jan 30, 2017, at 10:38 AM, Doug Simon <doug.si...@oracle.com> wrote: >> >> I’ve extended the webrev with that change - please re-review: >> >> http://cr.openjd

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

2017-02-02 Thread Doug Simon
tegrate it? -Doug >> On Feb 1, 2017, at 12:03 PM, Doug Simon <doug.si...@oracle.com> wrote: >> >> >>> On 1 Feb 2017, at 20:54, Sean Mullan <sean.mul...@oracle.com> wrote: >>> >>> Couple of comments: >>> >>> - jdk.vm.ci

Re: Running jaotc with an external Graal

2017-02-16 Thread Doug Simon
With the current bits in jdk9/hs and graal-core, the following bootstrapping command works in terms of replacing Graal in the JDK: java -server -XX:+UnlockExperimentalVMOptions --module-path=/Users/dsimon/hs/truffle/mxbuild/modules/com.oracle.truffle.truffle_api.jar

Re: Running jaotc with an external Graal

2017-02-15 Thread Doug Simon
I don’t know how one patches a module in the middle of the module graph. That is, we use --patch-module and --upgrade-module-path to override the jdk.vm.compiler module in the JDK. I don’t know what that means for modules such as jdk.aot that depend on jdk.vm.compiler. Maybe someone from the

Re: Problem loading Truffle service providers in Graal

2017-02-26 Thread Doug Simon
> On 26 Feb 2017, at 13:26, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 26 Feb 2017, at 13:22, Doug Simon <doug.si...@oracle.com> wrote: >> >>> >>> On 26 Feb 2017, at 13:08, Alan Bateman <alan.bate...@oracle.com> wrote: >

Re: Problem loading Truffle service providers in Graal

2017-02-26 Thread Doug Simon
> On 26 Feb 2017, at 14:44, Alan Bateman <alan.bate...@oracle.com> wrote: > > > > On 26/02/2017 13:13, Doug Simon wrote: >> : >> Also, what if there's provider in jdk.internal.vm.compiler itself? Will it >> be loaded along with the providers on my

Re: Problem loading Truffle service providers in Graal

2017-02-26 Thread Doug Simon
> On 26 Feb 2017, at 13:22, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 26 Feb 2017, at 13:08, Alan Bateman <alan.bate...@oracle.com> wrote: >> >> On 26/02/2017 11:20, Doug Simon wrote: >> >>> While trying to get upstream

Re: Problem loading Truffle service providers in Graal

2017-02-26 Thread Doug Simon
> On 26 Feb 2017, at 13:08, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 26/02/2017 11:20, Doug Simon wrote: > >> While trying to get upstream Graal working again with JDK 9, I'm having >> problems with service loading. Graal uses a LayoutFactory servic

Problem loading Truffle service providers in Graal

2017-02-26 Thread Doug Simon
While trying to get upstream Graal working again with JDK 9, I'm having problems with service loading. Graal uses a LayoutFactory service defined by Truffle where the latter also includes a provider. The relevant parts of the module-info descriptors are: module com.oracle.truffle.truffle_api {

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
> On 19 Apr 2017, at 16:04, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 18/04/2017 23:13, Doug Simon wrote: > >> : >> >> https://bugs.openjdk.java.net/browse/JDK-8177845 >> http://cr.openjdk.java.net/~dnsimon/8177845/ >> >

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-21 Thread Doug Simon
and remove the qualified exports. I've tested the current webrev (including hotspot.02 patch) against both upstream Graal and with jprt. -Doug > On 20 Apr 2017, at 20:50, Doug Simon <doug.si...@oracle.com> wrote: > > I've had to update the webrev again to support selection of a

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-20 Thread Doug Simon
y.getSavedProperties(HotSpotGraalCompilerFactory.java:215) ... 26 more -Doug > On 19 Apr 2017, at 23:26, Doug Simon <doug.si...@oracle.com> wrote: > > I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these > changes: > > 1. JVMCIServiceLoc

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-20 Thread Doug Simon
> On 19 Apr 2017, at 22:29, Vladimir Kozlov <vladimir.koz...@oracle.com> wrote: > > ReflectionAccessJDK ? Based on your comment in the file. > > Vladimir > > On 4/19/17 1:02 PM, Doug Simon wrote: >> Sure - how about good old Util? ;-) I'm open to other sugges

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
> On 19 Apr 2017, at 20:01, Mandy Chung wrote: > >> >> On Apr 19, 2017, at 8:03 AM, Peter Levart wrote: >> >> Hi Alan, >> >> On 04/19/2017 03:41 PM, Alan Bateman wrote: >>> On 19/04/2017 08:37, Peter Levart wrote: >>> : Note

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
> be used in JDK 10 too: > > jdk.vm.ci.services.internal.JDK9; > > Thanks, > Vladimir > >> On 4/18/17 3:13 PM, Doug Simon wrote: >> Please review these changes that make jdk.internal.vm.compiler an upgradable >> compiler. >> The primary requirement for

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-20 Thread Doug Simon
hanks, > Vladimir > > On 4/19/17 2:12 PM, Doug Simon wrote: >>> 3. Services.initializeJVMCI() > >>>> 3 is harmless from a security perspective in my opinion. >>> Would be good if one of Oracle’s security engineers could take a quick look >

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
> On 19 Apr 2017, at 21:40, Christian Thalinger <cthalin...@twitter.com> wrote: > >> >> On Apr 19, 2017, at 9:27 AM, Doug Simon <doug.si...@oracle.com> wrote: >> >>> >>> On 19 Apr 2017, at 21:04, Mandy Chung <mandy.ch...@oracl

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
-> jdk.vm.ci.services.internal.ReflectionAccessJDK -Doug > On 19 Apr 2017, at 23:12, Doug Simon <doug.si...@oracle.com> wrote: > >> >> On 19 Apr 2017, at 21:40, Christian Thalinger <cthalin...@twitter.com> wrote: >> >>> >>> On Apr 19, 2017, at 9:27 AM, Doug Simon <

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
(adding hotspot-compiler-dev) > On 19 Apr 2017, at 02:02, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Apr 18, 2017, at 3:13 PM, Doug Simon <doug.si...@oracle.com> wrote: >> >> Please review these changes that make jdk.internal.vm.compiler a

Re: javac unzips class files from jars on class path into output directory

2017-03-07 Thread Doug Simon
ons <jonathan.gibb...@oracle.com> wrote: > > > > On 03/07/2017 08:06 AM, Doug Simon wrote: >> To be able to develop Graal on JDK 9, we're using the `--release 8` javac >> option and providing jar files for API that is either not in 9 or is not >> exported in

RFR: 8177845: Need a mechanism to load Graal

2017-04-18 Thread Doug Simon
Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. The primary requirement for this is to remove all usage of JDK internals from Graal. While this most involves changes in Graal, there remain a few capabilities that must be exposed via JVMCI. Namely: 1.

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
> On 19 Apr 2017, at 02:02, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Apr 18, 2017, at 3:13 PM, Doug Simon <doug.si...@oracle.com> wrote: >> >> Please review these changes that make jdk.internal.vm.compiler an upgradable >> compiler

RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
(adding hotspot-compiler-dev) Please review these changes that make jdk.internal.vm.compiler an upgradable compiler. The primary requirement for this is to remove all usage of JDK internals from Graal. While this most involves changes in Graal, there remain a few capabilities that must be

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-19 Thread Doug Simon
Hi Peter, All of your suggestions look good. I've updated http://cr.openjdk.java.net/~dnsimon/8177845/jdk/src/java.base/share/classes/jdk/internal/misc/VM.java.udiff.html to include them (please check I didn't make any copy errors in the process). I was not aware of the new Map.ofEntries

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-27 Thread Doug Simon
> On 21 Apr 2017, at 13:46, Doug Simon <doug.si...@oracle.com> wrote: > > There has been some discussion about whether we want to update Graal in the > JDK at this late stage. The main (only?) risk is a regression in the AOT tool. > > If we don't update Graal from upst

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-27 Thread Doug Simon
> On 27 Apr 2017, at 17:40, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 27/04/2017 15:47, Doug Simon wrote: > >> : >> >> - The jaotc launcher now needs to explicitly export JVMCI and >> jdk.internal.vm.compiler to jdk.aot[4]. >> U

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-27 Thread Doug Simon
. > Overall changes looks good to me. Thanks for the review! I'll run the Graal and AOT tests once more and then integrate this change. -Doug [1] http://cr.openjdk.java.net/~dnsimon/8177845.02/jdk/make/launcher/Launcher-jdk.aot.gmk.udiff.html [2] http://cr.openjdk.java.net/~dnsimon/8177845.02

Re: RFR: 8177845: Need a mechanism to load Graal

2017-04-27 Thread Doug Simon
ate, this is completely by-passed by the JDK make system. > > src/jdk.internal.vm.ci/share/classes/module-info.java > > Why can we remove the exports to jdk.internal.vm.compiler? Because of this > in JVMCIServiceLocator: > > + ReflectionAccessJDK.openJVMCI

RFR: 8179434: test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails due to JDK-8177845

2017-04-28 Thread Doug Simon
Please review this small fix for a regression introduced by the change for https://bugs.openjdk.java.net/browse/JDK-8177845. http://cr.openjdk.java.net/~dnsimon/8179434/ https://bugs.openjdk.java.net/browse/JDK-8179434 -Doug

Re: RFR: 8179434: test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails due to JDK-8177845

2017-04-28 Thread Doug Simon
> On 28 Apr 2017, at 21:11, Mandy Chung <mandy.ch...@oracle.com> wrote: > > Looks good. Thanks for the review. -Doug >> On Apr 28, 2017, at 12:05 PM, Doug Simon <doug.si...@oracle.com> wrote: >> >> Please review this small fix for a regression

RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable

2018-06-14 Thread Doug Simon
In the context of JDK-8202762, we to need to make the jdk.aot module upgradeable. Otherwise, it is impossible to run or test the version of jdk.aot under development in a Graal repo: java

Re: RFR(XS): 8205025: [AOT] make jdk.aot module upgradeable

2018-06-14 Thread Doug Simon
> On 14 Jun 2018, at 12:03, Alan Bateman wrote: > > > > On 14/06/2018 09:09, Doug Simon wrote: >> In the context of JDK-8202762, we to need to make the jdk.aot module >> upgradeable. Otherwise, it is impossible to run or test the version of >> jdk.aot

RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

2018-04-12 Thread Doug Simon
Please review this change that removes the existing Graal service provider for hooking into the Platform MBean Server and makes jdk.internal.vm.compiler.management an upgradeable module. Please refer to

Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

2018-04-13 Thread Doug Simon
ernal.vm.compiler module. The rest of the changes will come in the next Graal update. If you'd like, I can defer pushing these changes until the Graal changes land on github so that the complete change can be reviewed. -Doug > On 13/04/2018 4:24 AM, Doug Simon wrote: >> Please review this chang

Re: Provides clauses in binary module descriptor but not in source

2018-04-13 Thread Doug Simon
> On 13 Apr 2018, at 14:33, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 13/04/2018 13:16, Doug Simon wrote: >> I just noticed that in the jdk.internal.vm.compiler module descriptor source >> there is a `uses` clause for CompilerConfigurationFactory[1] b

Provides clauses in binary module descriptor but not in source

2018-04-13 Thread Doug Simon
I just noticed that in the jdk.internal.vm.compiler module descriptor source there is a `uses` clause for CompilerConfigurationFactory[1] but no `provides` clause for the CoreCompilerConfigurationFactory provider[2] which is in the same module. However, `java -d jdk.internal.vm.compiler | grep

Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

2018-04-13 Thread Doug Simon
> On 13 Apr 2018, at 15:59, David Holmes <david.hol...@oracle.com> wrote: > > On 13/04/2018 5:12 PM, Doug Simon wrote: >>> On 13 Apr 2018, at 07:15, David Holmes <david.hol...@oracle.com> wrote: >>> >>> Hi Doug, >>> >>>

Re: RFR: 8201794: [Graal] fix regressions from JDK-8187490

2018-04-18 Thread Doug Simon
"jdk.plugin", -Doug > On 18 Apr 2018, at 12:35, Doug Simon <doug.si...@oracle.com> wrote: > > Right after pushing the change for JDK-8187490, I noticed that the mach5 > build had 2 CTW test failures due to jdk.internal.vm.compiler.management now > being a

Re: RFR: 8201794: [Graal] fix regressions from JDK-8187490

2018-04-18 Thread Doug Simon
> On 18 Apr 2018, at 13:23, mandy chung <mandy.ch...@oracle.com> wrote: > > Looks okay. Have you run all jdk_core tests in addition to other hotspot > tests. I ran all open/test/jdk/jdk tests - is that what you mean? -Doug > On 4/18/18 7:00 PM, Doug Simon wrote: >&

RFR: 8201794: [Graal] add dummy HotSpotGraalManagement class

2018-04-18 Thread Doug Simon
Right after pushing the change for JDK-8187490, I noticed that the mach5 build had 2 CTW test failures due to jdk.internal.vm.compiler.management now being an empty module. This will be fixed in the next Graal update but the failing tests should be fixed in the meantime.

Re: BackEnd Service Provider.

2020-04-22 Thread Doug Simon
On 21/04/2020 14:01, Doug Simon wrote: >> Hi Gary, >> >> I cannot understand why --add-reads does not work and have reached out to >> Alan Bateman for more insight. >> > I read through the thread [1] and I don't see an obvious solution to this. > > The mai