On Fri, 13 May 2022 19:13:46 GMT, Vladimir Ivanov wrote:
>> Ok. Then, if no one objects, I will leave this area as-is for now. (and
>> perhaps come back to this issue in the future, if it becomes more pressing).
>>
>> (I'll also note that this issue already exists in the current code that's in
On Thu, 12 May 2022 17:26:44 GMT, Jorn Vernee wrote:
>>> Do nothing special for async exceptions. i.e. if they happen anywhere
>>> between 1. and 6. they will end up in one of the fallback handlers and the
>>> VM will be terminated.
>>
>> My understanding is that if they materialize while
On Thu, 12 May 2022 12:10:53 GMT, Maurizio Cimadamore
wrote:
>> Okay, I see. I think I acted a little too hastily on this yesterday. I'll
>> revert the change that uses this blocking mechanism.
>>
>> The stack more or less looks like this during an upcall:
>>
>>
>> | ---
>> | |
>> | ---
On Thu, 12 May 2022 09:24:23 GMT, Jorn Vernee wrote:
> Do nothing special for async exceptions. i.e. if they happen anywhere between
> 1. and 6. they will end up in one of the fallback handlers and the VM will be
> terminated.
My understanding is that if they materialize while we're executing
On Thu, 12 May 2022 03:32:15 GMT, David Holmes wrote:
>> Is it possible for these upcalls to be nested? If yes, we could add a
>> boolean to context to avoid unsetting the flag in those nested cases. And
>> now that I think we should probably add that check in
>> NoAsyncExceptionDeliveryMark
On Wed, 11 May 2022 20:27:42 GMT, Patricio Chilano Mateo
wrote:
>> I went ahead and implemented this suggestion. Now we block async exceptions
>> in on_entry, and unblock in on_exit.
>
> Is it possible for these upcalls to be nested? If yes, we could add a boolean
> to context to avoid
On Wed, 11 May 2022 17:55:16 GMT, Jorn Vernee wrote:
>> Oh nice! I was just thinking that the only possible way out of this
>> conundrum would be to somehow block the delivery of async exceptions (at
>> least outside of the user's exception handler). So, that seems to be exactly
>> what we
On Wed, 11 May 2022 16:38:54 GMT, Jorn Vernee wrote:
>> If you want to avoid processing asynchronous exceptions during this upcall
>> you could block them (check NoAsyncExceptionDeliveryMark in
>> JavaThread::exit()). Seems you could set the flag in
>> ProgrammableUpcallhandler::on_entry()
On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo
wrote:
>> Discussed this with Maurizio as well.
>>
>> My understanding is as follows:
>> 1. Async exceptions are installed into a thread's `pending_exception` field
>> by handshake at a safepoint
>> 2. From there they are "thrown" (I
On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee wrote:
>> We have an exception handler in Java as well, so this code is only a fail
>> safe. But, I think in the case of asynchronous exceptions this might be
>> problematic if the exception is discovered by the current thread outside of
>> the
On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306:
>>
>>> 304: intptr_t exception_handler_offset = __ pc() - start;
>>> 305:
>>> 306: // Native caller has no idea how to handle exceptions,
>>
>> Can you elaborate,
On Tue, 10 May 2022 20:38:05 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Wed, 11 May 2022 11:06:51 GMT, Jorn Vernee wrote:
>> src/hotspot/share/opto/callGenerator.cpp line 1131:
>>
>>> 1129:
>>> 1130: case vmIntrinsics::_linkToNative:
>>> 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(),
>>
>> Why is it unconditionally reported as
On Tue, 10 May 2022 21:02:39 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 20:53:37 GMT, Vladimir Ivanov wrote:
>> src/hotspot/share/utilities/growableArray.hpp line 151:
>>
>>> 149: return _data;
>>> 150: }
>>> 151:
>>
>> This accessor is added to be able to temporarily view a stable GrowableArray
>> instance as a C-style array. It is
On Tue, 10 May 2022 20:45:02 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Wed, 11 May 2022 10:51:10 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30:
>>
>>> 28: #include "utilities/growableArray.hpp"
>>> 29:
>>> 30: class outputStream;
>>
>> Redundant declaration?
>
> Yeah, this whole file is redundant :) (replaced by
On Tue, 10 May 2022 21:01:48 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 20:48:47 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 20:30:09 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 19:21:58 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 19:16:35 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 18:55:03 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 18:48:08 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Tue, 10 May 2022 18:44:01 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded
On Mon, 28 Mar 2022 12:15:10 GMT, Jorn Vernee wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>> - Remove unneeded ComputeMoveOrder
On Mon, 9 May 2022 10:28:27 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This PR updates the VM implementation of the foreign linker, by bringing
>> over commits from the panama-foreign repo.
>>
>> This is split off from the main JEP integration for 19, since we have
>> limited resources to handle
> Hi,
>
> This PR updates the VM implementation of the foreign linker, by bringing over
> commits from the panama-foreign repo.
>
> This is split off from the main JEP integration for 19, since we have limited
> resources to handle this. As such, this PR might fall over to 20.
>
> I've
28 matches
Mail list logo
