On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
On Wed, 25 Nov 2020 17:05:15 GMT, Aleksey Shipilev wrote:
>> I've applied open comments. Please let me know if this is ok to merge.
>
> Still looks fine to me. Merge from master to get the fixes for GH actions
> failures, #1427
Thanks, Jorn. The split looks good.
-
PR: https://git
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Wed, 25 Nov 2020 16:30:16 GMT, Jorn Vernee wrote:
>> The VM "entry" changes seem better now. Thanks.
>>
>> The use of CATCH as a safety-net is also good.
>
> I've applied open comments. Please let me know if this is ok to merge.
Still looks fine to me. Merge from master to get the fixes for
On Wed, 25 Nov 2020 00:01:47 GMT, David Holmes wrote:
>> Jorn Vernee 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 contains 10 additional
>> commits si
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Wed, 25 Nov 2020 12:16:01 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Pass in thread instead of rematerializing it.
>
> src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 33:
>
>> 3
On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Tue, 24 Nov 2020 23:59:11 GMT, David Holmes wrote:
>> Jorn Vernee 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 contains 10 additional
>> commits si
On Tue, 24 Nov 2020 13:35:17 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
On Tue, 24 Nov 2020 13:31:17 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Remove JNI_ENTRY_CPP_NOENV
>> - - Move reset_last_Java_frame
>
> This looks fine to me. PIty to see `CATCH` on th
On Tue, 24 Nov 2020 13:21:08 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Tue, 24 Nov 2020 10:30:33 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use the Unimplemented() macro instead of hlt()
>
> I have a few minor comments, in addition to what David is saying
The main assumption is that calling code is fully foreign, and that it
does not know how to Java handle exceptions at all.
So, if an exception is thrown at this point, we should probably just
crash, and make it the callee's responsibility to handle exception if
they need/want to.
Looking at
On 24/11/2020 9:38 pm, Jorn Vernee wrote:
On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote:
src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
34: extern struct JavaVM_ main_vm;
35:
36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject
rec, address buff
On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote:
>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>>
>>> 34: extern struct JavaVM_ main_vm;
>>> 35:
>>> 36: JNI_ENTRY_CPP_NOENV(void,
>>> ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
>>
>> I do not like
On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
On Tue, 24 Nov 2020 01:14:20 GMT, David Holmes wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use the Unimplemented() macro instead of hlt()
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>
>> 34:
On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Mon, 23 Nov 2020 13:19:23 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR.
>
> src/hotspot/cpu/x86/universalNative
On Mon, 23 Nov 2020 19:25:31 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee 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 contains seven additional
>> com
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Mon, 23 Nov 2020 18:58:15 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote:
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing
JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the
needed changes to get it working again.
Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro.
Using just JNI_ENTRY was causing a linkage failure, due to the declaration of
the function in th
30 matches
Mail list logo
