On Mon, 24 Apr 2023 00:23:18 GMT, Kim Barrett wrote:
> I believe this may have missed removing the exception specifier from an
> operator new inside AnyObj, allocation.cpp, since gcc 12 and up on my end now
> refuses to compile HotSpot with this change. I'll create a cleanup change for
> this,
On Thu, 27 Apr 2023 04:49:10 GMT, David Holmes wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>> atom
On Tue, 25 Apr 2023 19:09:23 GMT, Coleen Phillimore wrote:
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> ato
> This refactoring to separate ThreadStart/ThreadEnd events posting code in the
> JVMTI VTMS transitions is needed for future work on JVMTI scalability and
> performance improvements. It is to easier put this code on slow path.
>
> Testing: mach5 tiers 1-6 were successful.
Serguei Spitsyn has u
On Wed, 19 Apr 2023 22:02:20 GMT, Serguei Spitsyn wrote:
>> This refactoring to separate ThreadStart/ThreadEnd events posting code in
>> the JVMTI VTMS transitions is needed for future work on JVMTI scalability
>> and performance improvements. It is to easier put this code on slow path.
>>
>>
> This refactoring to separate ThreadStart/ThreadEnd events posting code in the
> JVMTI VTMS transitions is needed for future work on JVMTI scalability and
> performance improvements. It is to easier put this code on slow path.
>
> Testing: mach5 tiers 1-6 were successful.
Serguei Spitsyn has u
> Hi, heap dump brings about pauses for application's execution(STW), this is a
> well-known pain. JDK-8252842 have added parallel support to heapdump in an
> attempt to alleviate this issue. However, all concurrent threads
> competitively write heap data to the same file, and more memory is req
On Wed, 26 Apr 2023 18:33:28 GMT, Roman Kennke wrote:
>> src/hotspot/share/logging/logTag.hpp line 80:
>>
>>> 78: LOG_TAG(exceptions) \
>>> 79: LOG_TAG(exit) \
>>> 80: LOG_TAG(fastlock2) \
>>
>> So why 'fastlock2'? Where's 'fastlock1'? Or 'fastlock'?
>
> It's currently only used in the ar
On Wed, 26 Apr 2023 11:00:33 GMT, Quan Anh Mai wrote:
>> How would I check if we are emitting code?
>>
>> I am not sure I understand. The check for ANONYMOUS is only relevant when we
>> observe an already-inflated monitor. I think this is the right place to put
>> it.
>
> The entry barrier doe
On Wed, 26 Apr 2023 18:29:36 GMT, Thomas Stuefe wrote:
>> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>>
>>> 1801: #ifdef ASSERT
>>> 1802: // Poison scratch regs
>>> 1803: POISON_REGS((~savemask), t1, t2, t3, 0x1001);
>>
>> Should this poison value be: 0x2002
>
> The poiso
On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote:
> 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
This pull request has now
On Wed, 26 Apr 2023 17:43:26 GMT, Kevin Walls wrote:
>> 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
>
> Marked as revi
On Tue, 25 Apr 2023 19:09:23 GMT, Coleen Phillimore wrote:
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> ato
On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>
>> 1801: #ifdef ASSERT
On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty
wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803:
>
>> 1801: #ifdef ASSERT
On Mon, 24 Apr 2023 19:42:35 GMT, Roman Kennke wrote:
>> Hi there,
>> what is needed to bring this PR over the approval line?
>
>> @rkennke - I'm planning to do another crawl thru review next week.
>
> Thanks! That is greatly appeciated!
> @rkennke - finished my second crawl thru review of 60/6
On Wed, 26 Apr 2023 08:41:30 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that removes some remaining CMS related stuff.
>>
>> Testing: tier1-3, gha
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional
> commit
On Tue, 25 Apr 2023 19:09:23 GMT, Coleen Phillimore wrote:
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> ato
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 23:49:56 GMT, Ioi Lam wrote:
> 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
Marked as reviewed by kevi
On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote:
> 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
Marked as reviewed by cjpl
On Wed, 26 Apr 2023 09:12:24 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
On Wed, 26 Apr 2023 08:41:30 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that removes some remaining CMS related stuff.
>>
>> Testing: tier1-3, gha
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional
> commit
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 Mon, 24 Apr 2023 19:42:35 GMT, Roman Kennke wrote:
>> Hi there,
>> what is needed to bring this PR over the approval line?
>
>> @rkennke - I'm planning to do another crawl thru review next week.
>
> Thanks! That is greatly appeciated!
@rkennke - finished my second crawl thru review of 60/68
On Wed, 26 Apr 2023 10:43:48 GMT, Roman Kennke wrote:
>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 701:
>>
>>> 699: // ZFlag == 0 count in slow path
>>> 700: jccb(Assembler::notZero, NO_COUNT); // jump if ZFlag == 0
>>> 701:
>>
>> `DONE_LABEL` is conditionally jumped into from a l
On Thu, 20 Apr 2023 11:15:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Wed, 26 Apr 2023 13:16:26 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/java.smartcardio/unix/native/libj
On Tue, 11 Apr 2023 08:16:29 GMT, Afshin Zafari wrote:
> The `finalize()` method is removed from base classes/interfaces and are
> replaced by a Cleaner callback..
Amendment to my comment above. 1. FinalizableObject does seem to serve a
purpose, so shouldn't be removed.
-
PR Com
This change moves the flags from AccessFlags to either ConstMethodFlags or
MethodFlags, depending on whether they are set at class file parse time, which
makes them essentially const, or at runtime, which makes them needing atomic
access.
This leaves AccessFlags int size because Klass still has
On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
> This fix preserve process
On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou wrote:
>> - Make functions 'static' when feasible:
>> - throwByName() in
>> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>> - throwByName(), throwIOException() and throwNullPointerException() in
>> src/java.smartcardio/unix/native
On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote:
>> Please review this change to the string deduplication thread to make it a
>> kind
>> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
>> this change:
>>
>> (1) New class StringDedupThread (derived from JavaThrea
On Wed, 26 Apr 2023 09:38:45 GMT, Serguei Spitsyn wrote:
>> Right. From the API caller's POV, it is asking for InputStreams that it can
>> use to read the process' stdout or stderr streams.
>
> Okay, thanks.
> I'm thinking about simple/short comments on this to make it clear this naming
> misma
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
> This fix preserve process streams content and allow to read reuse the date.
> The
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with Li
On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote:
> 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
Looks good to me. Other ex
On Wed, 26 Apr 2023 03:09:53 GMT, Quan Anh Mai wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 691:
>
>> 689: jccb(Assembler::no
On Wed, 26 Apr 2023 10:52:29 GMT, Roman Kennke wrote:
>> This stub has 2 instructions, and it seems not really uncommon, is it worth
>> it to have a stub here?
>
> Ok I will change the value.
> Yes, this path is relatively uncommon (monitors are inflated only once, and
> not necessarily via ANO
On Wed, 26 Apr 2023 09:03:07 GMT, Quan Anh Mai wrote:
>> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81:
>>
>>> 79: // C2CodeStubList::emit() will throw an assertion and report the
>>> actual size that
>>> 80: // is needed.
>>> 81: return 33;
>>
>> This should be 36 with `ASSERT` and 2
On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou wrote:
>> - Make functions 'static' when feasible:
>> - throwByName() in
>> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>> - throwByName(), throwIOException() and throwNullPointerException() in
>> src/java.smartcardio/unix/native
Hi, heap dump brings about pauses for application's execution(STW), this is a
well-known pain. JDK-8252842 have added parallel support to heapdump in an
attempt to alleviate this issue. However, all concurrent threads competitively
write heap data to the same file, and more memory is required to
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 Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
> This fix preserve process
On Tue, 25 Apr 2023 15:50:24 GMT, Daniel D. Daugherty
wrote:
>> Agree, it is confusing, even in standard j.l.Process API . The `InputStream
>> java.lang.Process.getInputStream()`" returns **output** stream of started
>> process. So for our implementation ProcessImpl the 'out' and 'err' mean
On Wed, 26 Apr 2023 08:12:41 GMT, Quan Anh Mai wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary comments
>
> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81:
>
>> 79: // C2CodeStubList::emit()
On Thu, 20 Apr 2023 11:15:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Tue, 25 Apr 2023 18:31:19 GMT, Chris Plummer wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> cplummer review
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 1109:
>
>> 1107:
> 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 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.
This pull request has now been integrated.
Chan
> Hi all,
>
> please review this change that removes some remaining CMS related stuff.
>
> Testing: tier1-3, gha
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally with one additional
commit since the last revision:
cplummer review
-
Changes:
52 matches
Mail list logo
