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
>>
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 *)(_vm);
>>> 99: vm -> functions -> AttachCurrentThreadAsDaemon(vm, _env, NULL);
>>
>> Style nit:
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
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 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
>
>> 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...@
2c44cff993b8/src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java#l29
>
>> On Jan 29, 2017, at 12:40 PM, Doug Simon <doug.si...@oracle.com> wrote:
>>
>> Both jdk.vm.ci and jdk.vm.compiler should be considered part of the VM si
> On 29 Jan 2017, at 20:34, Igor Veresov <igor.vere...@oracle.com> wrote:
>
>>
>> On Jan 27, 2017, at 3:40 PM, Christian Thalinger <cthalin...@twitter.com>
>> wrote:
>>
>>>
>>> On Jan 26, 2017, at 7:40 AM, Doug Simon <doug.si
> On 26 Jan 2017, at 17:55, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
>
>> On Jan 26, 2017, at 3:13 AM, Doug Simon <doug.si...@oracle.com> wrote:
>>
>>>
>>> jdk.vm.compiler is defined by the application class loader and it’s used by
>
> On 26 Jan 2017, at 03:32, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
> (dropping jdk9-dev. security-libs is the appropriate list to review security
> permission)
>
>> On Jan 23, 2017, at 1:56 PM, Doug Simon <doug.si...@oracle.com> wrote:
>>
>&g
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
On Jun 29, 2015, at 3:01 PM, Andrew Haley a...@redhat.com 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 necessary runtime checks
On Jun 29, 2015, at 12:41 PM, Zoltán Majó zoltan.m...@oracle.com 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
13 matches
Mail list logo
