On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>> issue described in https://bug
On Mon, 31 May 2021 06:06:37 GMT, Jaroslav Tulach
wrote:
>> This PR exposes runtime invisible annotations via `Class.getAnnotation` when
>> `-XX:+PreserveAllAnnotations` option is passed to the JVM.
>>
>> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code
>> that needs
On Tue, 27 Apr 2021 19:07:45 GMT, Igor Ignatyev wrote:
> > I guess this should really be named `isJVMCICompilerEnabled` now and the
> > `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but
> > maybe that's too big a change (or can be done later).
>
> @dougxc, I don't think th
On Mon, 12 Apr 2021 22:10:06 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Java-based JIT compiler (Graal) from JDK:
>>
>> - `jdk.internal.vm.compiler` — the Graal compiler
>> - `jdk.internal.vm.compiler.management` — Graal's `M
On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote:
>> Vladimir Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
On Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov wrote:
>> Marked as reviewed by iignatyev (Reviewer).
>
> Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032
We would definitely like to be able to continue testing of GraalVM with the JDK
set of jtreg tests. So keeping `C
On Wed, 11 Nov 2020 13:31:11 GMT, Jorn Vernee wrote:
>> Where's the logic for the native thread to detach? We have a similar problem
>> in libgraal. We have a [utility
>> class](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/
On Mon, 9 Nov 2020 11:50:54 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>>
>>> 97: if (thread == NULL) {
>>> 98: JavaVM_ *vm = (JavaVM *)(&main_vm);
>>> 99: vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);
>>
>> Style
> On 31 Oct 2019, at 05:30, David Holmes wrote:
>
> Hi Doug,
>
> On 30/10/2019 10:06 pm, Doug Simon wrote:
>>> On 30 Oct 2019, at 05:28, David Holmes >> <mailto:david.hol...@oracle.com>> wrote:
>>>
>>> Hi Doug,
>>>
>>&
currentThread);
+}
}
@SuppressWarnings("all")
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/
>
> Thanks,
> David
> -
>
>
> On 29/10/2019 7:14 pm, Doug Simon wrote:
>>> On 29 Oct 2019, at 10
> On 29 Oct 2019, at 10:12, David Holmes wrote:
>
> Hi Doug,
>
> Thanks for taking a look so quickly! :)
>
> On 29/10/2019 6:55 pm, Doug Simon wrote:
>> Hi David,
>> Since Graal needs to work against multiple JVMCI versions (and VM
>> versions!), th
Hi David,
Since Graal needs to work against multiple JVMCI versions (and VM versions!),
the Graal changes should only disable the intrinsic when the relevant VM config
is missing:
diff --git
a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
> On 29 Nov 2017, at 10:05, Alan Bateman wrote:
>
> On 28/11/2017 23:51, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8191788
>>
>> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to
>> tests
> On 15 Sep 2017, at 14:32, Jaroslav Tulach wrote:
>
> Thanks for the review Mandy, Daniel. Now, that the consolidated JDK10
> repository is available, I have updated my webrev to its structure. In
> addition to that I addressed your comments:
>
> On úterý 12. září 2017 11:19:45 CEST mandy ch
> On 21 Aug 2017, at 10:48, Jaroslav Tulach wrote:
>
> Hello Doug & co.,
> I think your comments are about the old webrev. I hope most of them have been
> (by a chance) addressed in the newest webrev 01:
Indeed they are. Sorry again for missing the latest link when do the review ;-)
-Doug
Hi Jaroslav,
In general, thanks for pushing through with this change.
I don't think JVMCIMXBeans should be in the hotspot-agnostic
jdk.vm.ci.services.internal package since it has a direct reference to
HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot.
In HotSpotJVMCRuntime.j
> On 25 Jul 2017, at 01:37, Mandy Chung wrote:
>
> Vladimir,
>
> I believe you don’t want to add the dependency from JVMCI to java.management.
> Otherwise, JVMCI can’t run with only java.base.
The dependency is unfortunate. Can you suggest how JVMCI platform beans could
participate in platf
> On Jun 29, 2015, at 10:47 PM, John Rose wrote:
>
> On Jun 29, 2015, at 10:48 AM, Doug Simon wrote:
>>
>> As I understand it, part of this change is to split intrinsification into
>> one method that does the checks that then calls a second method which the V
> On Jun 29, 2015, at 3:01 PM, Andrew Haley wrote:
>
> On 06/29/2015 01:38 PM, Doug Simon wrote:
>
>> I seems just plain wrong for an intrinsic to not implement the same
>> semantics as the intrinsified method. I would expect an intrinsic to
>> perform all nec
> On Jun 29, 2015, at 12:41 PM, Zoltán Majó wrote:
>
> Hi,
>
>
> On 06/29/2015 11:45 AM, Andrew Haley wrote:
>> Hi,
>>
>> On 29/06/15 10:41, Zoltán Majó wrote:
>>> On 06/27/2015 10:05 AM, Andrew Haley wrote:
On 25/06/15 12:49, Zoltán Majó wrote:
> Problem: There is need to indicate J
20 matches
Mail list logo
