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 m
> 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
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
--module-path=../sdk/mxbuild/modules/org.graalvm.graal_sdk.jar:../truffle/mxbuild/modules/com.oracle.truff
> On 18 Apr 2018, at 13:23, mandy chung 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:
>> I've updated the web
"jdk.plugin",
-Doug
> On 18 Apr 2018, at 12:35, 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. T
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.
http://cr.openjdk.java.
> On 13 Apr 2018, at 15:59, David Holmes wrote:
>
> On 13/04/2018 5:12 PM, Doug Simon wrote:
>>> On 13 Apr 2018, at 07:15, David Holmes wrote:
>>>
>>> Hi Doug,
>>>
>>> Not a review. :) Just wondering what HotSpotRuntimeMBean has to do w
> On 13 Apr 2018, at 14:33, Alan Bateman 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] but no
>>
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 C
f 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 change that removes the existin
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
https://bugs.openjdk.java.net/browse/JDK-8187490?focusedCommentId=14170942&page=com.atlassia
> On 28 Apr 2017, at 21:11, Mandy Chung wrote:
>
> Looks good.
Thanks for the review.
-Doug
>> On Apr 28, 2017, at 12:05 PM, Doug Simon wrote:
>>
>> Please review this small fix for a regression introduced by the change for
>> https://bugs.openjdk.java.ne
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 27 Apr 2017, at 23:24, Mandy Chung wrote:
>
>
>> On Apr 27, 2017, at 7:47 AM, Doug Simon wrote:
>>
>> [1] http://cr.openjdk.java.net/~dnsimon/8177845.02
>
> I reviewed the top repo and jdk repo change. For hotspot change,
> I reviewed jdk.vm.ci.serv
l 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/make/mak
y-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.openJVMCITo(getClass());
Yes. And the --add-expor
> On 27 Apr 2017, at 17:40, Alan Bateman 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].
>> Unfortunately there needs to
> On 21 Apr 2017, at 13:46, Doug Simon 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 upstream, then the quali
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 wrote:
>
> I've had to update the webrev again to support selection of a "null" co
actory.getSavedProperties(HotSpotGraalCompilerFactory.java:215)
... 26 more
-Doug
> On 19 Apr 2017, at 23:26, Doug Simon wrote:
>
> I've updated http://cr.openjdk.java.net/~dnsimon/8177845/hotspot/ with these
> changes:
>
> 1. JVMCIServic
> On 19 Apr 2017, at 22:29, Vladimir Kozlov 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 suggestions.
>>
>> Sent
t/~dnsimon/8177845/hotspot/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java.udiff.html).
As previously stated, I can't see any security issues with this method which
is why it doesn't check JVMCIPermission.
-Doug
>
> Thanks,
> Vladimi
.JDK9 ->
jdk.vm.ci.services.internal.ReflectionAccessJDK
-Doug
> On 19 Apr 2017, at 23:12, Doug Simon wrote:
>
>>
>> On 19 Apr 2017, at 21:40, Christian Thalinger wrote:
>>
>>>
>>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote:
>>>
>>>>
>>>> On 19
> On 19 Apr 2017, at 21:40, Christian Thalinger wrote:
>
>>
>> On Apr 19, 2017, at 9:27 AM, Doug Simon wrote:
>>
>>>
>>> On 19 Apr 2017, at 21:04, Mandy Chung wrote:
>>>
>>>
>>>> On Apr 19, 2017, at 11:55 AM, Christi
> 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 this is to remove all usage
> On 19 Apr 2017, at 21:04, Mandy Chung wrote:
>
>
>> On Apr 19, 2017, at 11:55 AM, Christian Thalinger
>> wrote:
>>
>>
>>> On Apr 19, 2017, at 8:38 AM, Mandy Chung wrote:
>>>
>>> Since jdk.internal.vm.compiler becomes an upgradeable module, it is not
>>> hashed with java.base to allow i
> 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 that Properties class is thread-safe, while HashMa
> On 19 Apr 2017, at 16:04, Alan Bateman 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/
>>
> I'm happy to see jdk.internal.vm.c
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 method
(adding hotspot-compiler-dev)
> On 19 Apr 2017, at 02:02, Mandy Chung wrote:
>
>
>> On Apr 18, 2017, at 3:13 PM, Doug Simon wrote:
>>
>> Please review these changes that make jdk.internal.vm.compiler an upgradable
>> compiler.
>> :
>> http://cr.o
(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 expos
> On 19 Apr 2017, at 02:02, Mandy Chung wrote:
>
>
>> On Apr 18, 2017, at 3:13 PM, Doug Simon wrote:
>>
>> Please review these changes that make jdk.internal.vm.compiler an upgradable
>> compiler.
>> :
>> http://cr.openjdk.java.net/~dnsimon/81778
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. Graal
Please coordinate with the
> Labs.
>
> CCing Doug Simon.
>
> igor
>
>
>> On Apr 4, 2017, at 9:28 AM, Alan Bateman wrote:
>>
>> As I mentioned on jigsaw-dev yesterday, we have accumulated a number of
>> changes in the jake forest and would like to bring
ou want that) as compared to class files.
>
> Whether you prefer to have javac read source files or class files depends on
> whether you just want the signatures defined in the class file, or whether
> you want all the info available in the source file, and/or whether
> perform
; bin/org
> bin/org/graalvm
> bin/org/graalvm/compiler
> bin/org/graalvm/compiler/api
> bin/org/graalvm/compiler/api/runtime
> bin/org/graalvm/compiler/api/runtime/GraalRuntime.class
> bin/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.class
> $
>
> -- Jon
>
Gibbons 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 9. Here is a simplifie
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 9. Here is a simplified form of a javac command:
javac -cp jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/
--release
> On 26 Feb 2017, at 14:44, Alan Bateman 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:26, Doug Simon wrote:
>
>>
>> On 26 Feb 2017, at 13:22, Doug Simon wrote:
>>
>>>
>>> On 26 Feb 2017, at 13:08, Alan Bateman wrote:
>>>
>>> On 26/02/2017 11:20, Doug Simon wrote:
>>>
>>
> On 26 Feb 2017, at 13:22, Doug Simon wrote:
>
>>
>> On 26 Feb 2017, at 13:08, Alan Bateman wrote:
>>
>> On 26/02/2017 11:20, Doug Simon wrote:
>>
>>> While trying to get upstream Graal working again with JDK 9, I'm having
>>>
> On 26 Feb 2017, at 13:08, Alan Bateman 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 service defined by
>> Truff
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 {
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
--upgrade-module-path=/User
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 AOT
Feb 1, 2017, at 12:03 PM, Doug Simon wrote:
>>
>>
>>> 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 AllP
ed 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:
>>
>> http://cr.openjdk.java.n
, 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
> 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
>>
>
49 matches
Mail list logo
