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
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
> 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
>>
>
, 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
classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java#l29
>
>> On Jan 29, 2017, at 12:40 PM, Doug Simon wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler should be considered part of the VM since
>> they have the same capabilities as Unsafe. Argua
> On 29 Jan 2017, at 20:34, Igor Veresov wrote:
>
>>
>> On Jan 27, 2017, at 3:40 PM, Christian Thalinger
>> wrote:
>>
>>>
>>> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote:
>>>
>>>>
>>>> On 26 Jan 2017,
> On 26 Jan 2017, at 17:55, Mandy Chung wrote:
>
>
>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote:
>>
>>>
>>> jdk.vm.compiler is defined by the application class loader and it’s used by
>>> AOT tool. I wonder why it
> On 26 Jan 2017, at 03:32, Mandy Chung wrote:
>
> (dropping jdk9-dev. security-libs is the appropriate list to review security
> permission)
>
>> On Jan 23, 2017, at 1:56 PM, Doug Simon wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler require a number o
Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a
security manager is present. Since neither of these modules is accessible to
application code, it should be ok to give them all permissions. This seems to
be the approach for a number of other modules including jdk.scripti
> 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
> 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
13 matches
Mail list logo
