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:
>>
>
>
>> 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...@
> 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
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
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
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
> 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:
>
> 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
> 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
> 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
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 {
> 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/
>>
>
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
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
> 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
> 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
> 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
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
>
> 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
->
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 <
(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
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
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.
> 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
(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
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
> 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
> 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
.
> 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
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
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
> 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
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
> 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
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
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
> 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
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
> 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,
>>>
>>>
"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
> 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:
>&
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.
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
43 matches
Mail list logo