On Fri, 27 Oct 2023 09:09:05 GMT, Jorn Vernee wrote:
> Do you want me to create a separate PR to remove the comment?
No not necessary. Thanks
-
PR Comment: https://git.openjdk.org/jdk/pull/16349#issuecomment-1784664238
On Fri, 27 Oct 2023 05:26:47 GMT, David Holmes wrote:
> @JornVernee please don't forget that all non-trivial (as defined by the dev
> guide) hotspot changes require at least 2 reviews and a 24 hour wait before
> integration. Thanks.
Right, sorry. I think I confused this PR with
On Thu, 26 Oct 2023 15:02:46 GMT, Jorn Vernee wrote:
>> The result of `FindClass` is a local JNI handle (in
>> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such,
>> we need to wrap the return value of `FindClass` in a global reference when
>> storing it inside
> The result of `FindClass` is a local JNI handle (in
> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
> need to wrap the return value of `FindClass` in a global reference when
> storing it inside fallbackLinker.c.
>
> While investigating this, I also noticed an
On Wed, 25 Oct 2023 11:16:54 GMT, Jorn Vernee wrote:
>> The result of `FindClass` is a local JNI handle (in
>> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such,
>> we need to wrap the return value of `FindClass` in a global reference when
>> storing it inside
On Wed, 25 Oct 2023 09:32:42 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> explicitly propagate fallback library init failures
>
>
> The result of `FindClass` is a local JNI handle (in
> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
> need to wrap the return value of `FindClass` in a global reference when
> storing it inside fallbackLinker.c.
>
> While investigating this, I also noticed an
On Wed, 25 Oct 2023 10:05:22 GMT, Jorn Vernee wrote:
>> The old code would throw `ShouldNotReachHere()` if we did not recognize the
>> handle type:
>> https://github.com/openjdk/jdk/blob/d2d1592dd94e897fae6fc4098e43b4fffb6d6750/src/hotspot/share/runtime/jniHandles.cpp#L207
>>
>> I think the
On Wed, 25 Oct 2023 10:01:29 GMT, Aleksey Shipilev wrote:
>> Not sure what you're saying here. As far as I understand the intent of this
>> code is to check whether the handle is of a certain type, and if it's not
>> recognized, return `JNIInvalidRefType`. So, I'm not sure there should be any
On Wed, 25 Oct 2023 09:46:44 GMT, Jorn Vernee wrote:
>> src/hotspot/share/runtime/jniHandles.cpp line 202:
>>
>>> 200: ShouldNotReachHere();
>>> 201: }
>>> 202: } else if (is_local_handle(thread, handle) ||
>>> is_frame_handle(thread, handle)) {
>>
>> Should we still add
On Wed, 25 Oct 2023 09:29:43 GMT, Aleksey Shipilev wrote:
>> The result of `FindClass` is a local JNI handle (in
>> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such,
>> we need to wrap the return value of `FindClass` in a global reference when
>> storing it inside
On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee wrote:
> The result of `FindClass` is a local JNI handle (in
> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
> need to wrap the return value of `FindClass` in a global reference when
> storing it inside
On Tue, 24 Oct 2023 19:49:17 GMT, Alan Bateman wrote:
>> The result of `FindClass` is a local JNI handle (in
>> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such,
>> we need to wrap the return value of `FindClass` in a global reference when
>> storing it inside
On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee wrote:
> The result of `FindClass` is a local JNI handle (in
> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
> need to wrap the return value of `FindClass` in a global reference when
> storing it inside
The result of `FindClass` is a local JNI handle (in
`find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
need to wrap the return value of `FindClass` in a global reference when storing
it inside fallbackLinker.c.
While investigating this, I also noticed an existing bug
15 matches
Mail list logo
