> Hi,
>
> Could I have a review of this change that merges three vm
> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and
> signal_thread_entry.
>
> `jstack` is a very common command, even in the production environment.
>
> In addition to reduce the cost of entering s
On Fri, 18 Jun 2021 06:17:24 GMT, David Holmes wrote:
>> Denghui Dong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> polish
>
> src/hotspot/share/runtime/os.cpp line 402:
>
>> 400: // the output stream (e.g. tty->flush()) after
On 18/06/2021 4:35 pm, Alan Bateman wrote:
On 17/06/2021 22:44, David Holmes wrote:
I must admit I'm a bit confused about these implementation-specific
MBeans. They are implementation-specific, so no part of the primary
java.management namespace, but they are provided so that they can be
use
> Hi,
>
> Could I have a review of this change that merges three vm
> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and
> signal_thread_entry.
>
> `jstack` is a very common command, even in the production environment.
>
> In addition to reduce the cost of entering s
On 17/06/2021 22:44, David Holmes wrote:
I must admit I'm a bit confused about these implementation-specific
MBeans. They are implementation-specific, so no part of the primary
java.management namespace, but they are provided so that they can be
used - so shutting them behind the modular door
On Fri, 18 Jun 2021 06:08:48 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Could I have a review of this change that merges three vm
>> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump
>> and signal_thread_entry.
>>
>> `jstack` is a very common command, even in the production
On Thu, 17 Jun 2021 15:45:47 GMT, Paul Sandoz wrote:
>> src/java.base/share/classes/java/util/Base64.java line 934:
>>
>>> 932: if (closed)
>>> 933: throw new IOException("Stream is closed");
>>> 934: Preconditions.checkFromIndexSize(len, off, b.length, (x
On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally
> Hi,
>
> Could I have a review of this change that merges three vm
> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and
> signal_thread_entry.
>
> `jstack` is a very common command, even in the production environment.
>
> In addition to reduce the cost of entering s
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
rest
On Thu, 17 Jun 2021 10:19:43 GMT, Alan Bateman wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java
> Hi,
>
> Could I have a review of this change that merges three vm
> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and
> signal_thread_entry.
>
> `jstack` is a very common command, even in the production environment.
>
> In addition to reduce the cost of entering s
On 18/06/2021 12:29 pm, Denghui Dong wrote:
On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes wrote:
Sorry still not a fan even with the hacked in deadline support for
find_deadlocks. It is too arbitrary - you have no idea what constitutes a
reasonable deadline, nor by how much you may overshoo
On Thu, 17 Jun 2021 23:12:04 GMT, David Holmes wrote:
> Sorry still not a fan even with the hacked in deadline support for
> find_deadlocks. It is too arbitrary - you have no idea what constitutes a
> reasonable deadline, nor by how much you may overshoot that deadline.
>
> David
Hi David,
T
On Thu, 17 Jun 2021 15:32:01 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Could I have a review of this change that merges three vm
>> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump
>> and signal_thread_entry.
>>
>> `jstack` is a very common command, even in the production
On 17/06/2021 11:44 pm, Carter Kozak wrote:
On 17/06/2021 3:15 pm, Alan Bateman wrote:
> On 17/06/2021 02:39, David Holmes wrote:
>> In what way does this no longer work? We have a test in
>> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that
>> uses this API and doesn't s
On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore wrote:
> This change removes the mark_for_evol_deoptimization method and removes the
> flag that all dependencies are recorded. Before the change to walk the
> entire nmethod looking for "old" (redefined) methods with metadata_do(), we
> use
On Fri, 11 Jun 2021 19:40:09 GMT, Alex Menkov wrote:
> The fix adds check that IOPipe is connected before sending "quit" command
ProblemListings that are integrated in JDK17 will get sync'ed forward to JDK18.
The thing to do is remove the test from the ProblemList in your PR so that your
test jo
On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore wrote:
> This change removes the mark_for_evol_deoptimization method and removes the
> flag that all dependencies are recorded. Before the change to walk the
> entire nmethod looking for "old" (redefined) methods with metadata_do(), we
> use
On Thu, 17 Jun 2021 10:21:35 GMT, Alan Bateman wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> src/java.base/share/classes/java/util/Base64.
> Hi,
>
> Could I have a review of this change that merges three vm
> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump and
> signal_thread_entry.
>
> `jstack` is a very common command, even in the production environment.
>
> In addition to reduce the cost of entering s
On 17/06/2021 3:15 pm, Alan Bateman wrote:
> On 17/06/2021 02:39, David Holmes wrote:
>> In what way does this no longer work? We have a test in
>> jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java that
>> uses this API and doesn't seem to need to do anything to allow access. ??
> T
On 17/06/2021 8:50 pm, Alan Bateman wrote:
On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote:
There are a lot more tests than just tier1. :) I don't expect many, if any,
tests to be looking for a specific IOOBE message, and I can't see an easy way
to find such tests without running them.
On Thu, 10 Jun 2021 07:50:57 GMT, Ludovic Henry wrote:
>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime
>> stub (like arraycopy), a vtable stub, or the prolog of a compiled method,
>> it wouldn't be able to detect the sender (caller) frame for multiple
>> reasons.
On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote:
> There are a lot more tests than just tier1. :) I don't expect many, if any,
> tests to be looking for a specific IOOBE message, and I can't see an easy way
> to find such tests without running them. If core-libs folk are okay with this
>
On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote:
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
I looked through the changes in java.base and only spotted o
> The glibc is somewhat notorious for retaining released C Heap memory: calling
> free(3) returns memory to the glibc, and most libc variants will return at
> least a portion of it back to the Operating System, but the glibc often does
> not.
>
> This depends on the granularity of the allocatio
On Thu, 17 Jun 2021 08:25:23 GMT, Severin Gehwolf wrote:
>> The glibc is somewhat notorious for retaining released C Heap memory:
>> calling free(3) returns memory to the glibc, and most libc variants will
>> return at least a portion of it back to the Operating System, but the glibc
>> often
On Wed, 16 Jun 2021 12:57:44 GMT, Thomas Stuefe wrote:
> The glibc is somewhat notorious for retaining released C Heap memory: calling
> free(3) returns memory to the glibc, and most libc variants will return at
> least a portion of it back to the Operating System, but the glibc often does
> n
29 matches
Mail list logo
