On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl wrote:
> Hi all,
>
> please review this change that removes some remaining CMS related stuff.
>
> Testing: tier1-3, gha
>
> Thanks,
> Thomas
Looks good.
-
Marked as reviewed by kbarrett (Reviewer).
PR Review: https://git.open
Please review this trivial fix.
When checking for bits in `m.getAccessFlags()`, the mask
`JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of
`m.getAccessFlags()` in ClassWriter.java
-
Commit messages:
- 8305771: SA ClassWriter.java fails to skip overpass
The fix updates JVMTI spec updates description of heap functions to support
virtual threads.
Virtual threads are not heap roots by design, so
FollowReference/IterateOverReachableObjects specs are updated to note only
platform threads.
References from thread stacks (including virtual threads) are
> The fix updates JVMTI FollowReferences implementation to report references
> from virtual threads:
> - unmounted vthreads are detected, their stack references for
> JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL;
> - stacks of mounted vthreads are splitted into 2 parts (virtual
On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote:
> Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed
> the "@ignore 6951287 ", allowing this test to run, which is why this failure
> mode is now turning up.
>
> There is a race condition, leading to the `popFrames
On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote:
> Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed
> the "@ignore 6951287 ", allowing this test to run, which is why this failure
> mode is now turning up.
>
> There is a race condition, leading to the `popFrames
Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the
"@ignore 6951287 ", allowing this test to run, which is why this failure mode
is now turning up.
There is a race condition, leading to the `popFrames()` call being done while a
native method is in the set of frames
On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote:
> The code introduced by
> [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses
> `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is
> currently missing.
Thanks for the reviews!
-
PR Comme
On Wed, 19 Apr 2023 23:40:56 GMT, Chris Plummer wrote:
> Note this PR depends on the #13546 PR for the following:
>
> [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of
> virtual threads to JVMTI StopThread
>
> So it can't be finalized and push until after JDK-8306434 i
On Wed, 19 Apr 2023 23:40:56 GMT, Chris Plummer wrote:
> Note this PR depends on the #13546 PR for the following:
>
> [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of
> virtual threads to JVMTI StopThread
>
> So it can't be finalized and push until after JDK-8306434 i
Note this PR depends on the #13546 PR for the following:
[JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of
virtual threads to JVMTI StopThread
So it can't be finalized and push until after JDK-8306434 is pushed. There will
also be GHA failures until then. If JDK-8306434
On Tue, 25 Apr 2023 15:59:05 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that removes the pinned tag from `HeapRegion`.
>>
>> So that "pinned" tag for G1 heap regions indicates that the region should
>> not move during (young) gc. This applies to now removed archive
> This enhancement adds support of virtual threads to the JVMTI `StopThread`
> function.
> In preview releases before this enhancement the StopThread returned the
> JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads.
>
> The `StopThread` supports sending an asynchronous exception t
On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl wrote:
> Hi all,
>
> please review this change that removes some remaining CMS related stuff.
>
> Testing: tier1-3, gha
>
> Thanks,
> Thomas
Marked as reviewed by cjplummer (Reviewer).
Copyrights need updating
-
PR Review: ht
On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote:
> The code introduced by
> [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses
> `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is
> currently missing.
Looks good.
Thank you for taking care about it.
> Hi all,
>
> please review this change that removes the pinned tag from `HeapRegion`.
>
> So that "pinned" tag for G1 heap regions indicates that the region should not
> move during (young) gc. This applies to now removed archive regions and
> humongous objects/regions.
>
> With "real" g1 r
On Tue, 25 Apr 2023 04:05:05 GMT, Leonid Mesnik wrote:
>> test/lib/jdk/test/lib/process/ProcessTools.java line 792:
>>
>>> 790: @Override
>>> 791: public InputStream getInputStream() {
>>> 792: return out;
>>
>> This is a little bit confusing that the `getInputStream
On Tue, 25 Apr 2023 15:29:08 GMT, Thomas Schatzl wrote:
>> src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414:
>>
>>> 412: // There are no other valid region types. Check for one invalid
>>> 413: // one we can identify before crashing: non-movable.
>>> 414: assert(hr->is_young
On Tue, 25 Apr 2023 15:05:10 GMT, Albert Mingkun Yang wrote:
>> Hi all,
>>
>> please review this change that removes the pinned tag from `HeapRegion`.
>>
>> So that "pinned" tag for G1 heap regions indicates that the region should
>> not move during (young) gc. This applies to now removed ar
On Tue, 25 Apr 2023 13:49:05 GMT, Thomas Schatzl wrote:
> Hi all,
>
> please review this change that removes the pinned tag from `HeapRegion`.
>
> So that "pinned" tag for G1 heap regions indicates that the region should not
> move during (young) gc. This applies to now removed archive regio
Hi all,
please review this change that removes the pinned tag from `HeapRegion`.
So that "pinned" tag for G1 heap regions indicates that the region should not
move during (young) gc. This applies to now removed archive regions and
humongous objects/regions.
With "real" g1 region pinning to d
On Fri, 21 Apr 2023 13:33:53 GMT, Alan Bateman wrote:
>> What does "suspended at an event" mean? As a programmer trying to use this
>> how am I supposed to know when it can be used without getting an error?
>>
>> I find it very surprising that the error would occur with an unmounted
>> thread
22 matches
Mail list logo
