On Thu, 13 Jul 2023 18:56:56 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
On Fri, 14 Jul 2023 05:02:34 GMT, David Holmes wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Bikeshed Trim log lines
>
> test/hotspot/gtest/runtime/test_trim_native.cpp line 44:
>
>> 42: NativeHeapTrimmer
On Fri, 14 Jul 2023 02:45:36 GMT, Daohan Qu wrote:
>> This patch should fix the wrong CP index for `invokedynamic` instruction
>> generated by SA's `ClassWriter`. The buggy code in
>> `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` should have been up-to-date
>> with the following code snippet
On Thu, 13 Jul 2023 19:18:38 GMT, Alex Menkov wrote:
> The change fixes handling of "suspended" bit in VT state.
> The code looks very strange.
> java_lang_VirtualThread::RUNNING == 3, so line 803 clears
> JVMTI_THREAD_STATE_ALIVE(1) and JVMTI_THREAD_STATE_TERMINATED(2)
> Per log this code came
On Thu, 13 Jul 2023 02:13:54 GMT, Chris Plummer wrote:
>> After [JDK-8308232](https://bugs.openjdk.org/browse/JDK-8308232), both the
>> test and the debuggee shared the same waittime of 5 minutes. The test would
>> wait up to 5 minutes for the expected prompt, but the debuggee would also in
>>
On Fri, 14 Jul 2023 04:47:23 GMT, David Holmes wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Bikeshed Trim log lines
>
> src/hotspot/share/runtime/trimNativeHeap.cpp line 83:
>
>> 81:
>> 82: // in seconds
>>
On Thu, 13 Jul 2023 18:56:56 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
On Thu, 13 Jul 2023 18:51:09 GMT, Aleksey Shipilev wrote:
> Want to replace "Native heap trimmer" with "Periodic native heap trimmer"
> too? Would be clear that we are suspending only the periodic one. The DCmd
> command would still be accepted and acted upon. Thinking about it, maybe we
> sho
On Thu, 13 Jul 2023 19:55:49 GMT, Aleksey Shipilev wrote:
> Realized that in production, we would like to see why trimmer might be late.
> I think this would look even better:
> [trimnative-shipilev-2.patch](https://github.com/openjdk/jdk/files/12043977/trimnative-shipilev-2.patch)
I thought a
On Wed, 12 Jul 2023 12:50:56 GMT, Kevin Walls wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Different approach to fix. Widen synchronized block so there is no need to
>> refetch the notInterrupted count.
>
> Ye
On Thu, 13 Jul 2023 18:56:56 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
On Thu, 13 Jul 2023 19:18:38 GMT, Alex Menkov wrote:
> The change fixes handling of "suspended" bit in VT state.
> The code looks very strange.
> java_lang_VirtualThread::RUNNING == 3, so line 803 clears
> JVMTI_THREAD_STATE_ALIVE(1) and JVMTI_THREAD_STATE_TERMINATED(2)
> Per log this code came
On Thu, 13 Jul 2023 19:18:38 GMT, Alex Menkov wrote:
> The change fixes handling of "suspended" bit in VT state.
> The code looks very strange.
> java_lang_VirtualThread::RUNNING == 3, so line 803 clears
> JVMTI_THREAD_STATE_ALIVE(1) and JVMTI_THREAD_STATE_TERMINATED(2)
> Per log this code came
On Wed, 12 Jul 2023 19:48:52 GMT, Ashutosh Mehra wrote:
> Please review this fix to correctly read a long value in the runtime constant
> pool. Details are mentioned in the issue [0].
> As an example, before this fix the long value generated by SA's dumpclass for
> java.lang.String.serialVersio
On Thu, 13 Jul 2023 03:25:38 GMT, Daohan Qu wrote:
>> This patch should fix the wrong CP index for `invokedynamic` instruction
>> generated by SA's `ClassWriter`. The buggy code in
>> `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` should have been up-to-date
>> with the following code snippet
On Thu, 13 Jul 2023 20:33:45 GMT, Chris Plummer wrote:
> ByteCodeRewriter.java needs a copyright update. You also need to update the
> PR tittle to match the CR.
Updated.
-
PR Comment: https://git.openjdk.org/jdk/pull/14852#issuecomment-1635181325
> This patch should fix the wrong CP index for `invokedynamic` instruction
> generated by SA's `ClassWriter`. The buggy code in
> `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` should have been up-to-date
> with the following code snippet in `hotspot`:
>
> https://github.com/openjdk/jdk/blob/75
On Thu, 13 Jul 2023 03:25:38 GMT, Daohan Qu wrote:
>> This patch should fix the wrong CP index for `invokedynamic` instruction
>> generated by SA's `ClassWriter`. The buggy code in
>> `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` should have been up-to-date
>> with the following code snippet
On Thu, 13 Jul 2023 18:56:56 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
The change fixes handling of "suspended" bit in VT state.
The code looks very strange.
java_lang_VirtualThread::RUNNING == 3, so line 803 clears
JVMTI_THREAD_STATE_ALIVE(1) and JVMTI_THREAD_STATE_TERMINATED(2)
Per log this code came from loom repo with VT integration.
Testing: tier1-4, updated Ge
On Thu, 13 Jul 2023 18:08:03 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
On Thu, 13 Jul 2023 18:02:08 GMT, Aleksey Shipilev wrote:
> Yes, the only thing left is to bikeshed the logging statements a little.
Okay done.
-
PR Comment: https://git.openjdk.org/jdk/pull/14781#issuecomment-1634730982
> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I closed
> https://github.com/openjdk/jdk/pull/10085 because it had accumulated too much
> comment history and got confusing. For a history of this issue, see previous
> discussions [1] and the comment section of 10085.
>
>
On Thu, 13 Jul 2023 03:25:38 GMT, Daohan Qu wrote:
>> This patch should fix the wrong CP index for `invokedynamic` instruction
>> generated by SA's `ClassWriter`. The buggy code in
>> `sun.jvm.hotspot.tools.jcore.ByteCodeRewriter` should have been up-to-date
>> with the following code snippet
On Mon, 10 Jul 2023 13:53:36 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
On Mon, 10 Jul 2023 13:53:36 GMT, Thomas Stuefe wrote:
>> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I
>> closed https://github.com/openjdk/jdk/pull/10085 because it had accumulated
>> too much comment history and got confusing. For a history of this issue, see
>> pre
On Wed, 12 Jul 2023 08:47:47 GMT, Aleksey Shipilev wrote:
>> Thomas Stuefe 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 32 additional
>> comm
> This is a continuation of https://github.com/openjdk/jdk/pull/10085. I closed
> https://github.com/openjdk/jdk/pull/10085 because it had accumulated too much
> comment history and got confusing. For a history of this issue, see previous
> discussions [1] and the comment section of 10085.
>
>
On Thu, 13 Jul 2023 17:42:28 GMT, Aleksey Shipilev wrote:
>> No, since `_num_trims_performed` is the number of trims performed during the
>> lifetime of the JVM. It should probably bumped to 64-bit, now that we have
>> millisecond intervals.
>
> Yeah, my patch, see the link above, does it as `u
On Thu, 13 Jul 2023 17:40:47 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/runtime/trimNativeHeap.cpp line 47:
>>
>>> 45:
>>> 46: // Statistics
>>> 47: unsigned _num_trims_performed;
>>
>> Sorry for the nit, but this is `uint16_t` too then, for consistency?
>
> No, since `_num_trims_perfo
On Mon, 10 Jul 2023 18:50:15 GMT, Aleksey Shipilev wrote:
>> Thomas Stuefe 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 32 additional
>> comm
On Fri, 30 Jun 2023 14:32:03 GMT, Ashutosh Mehra wrote:
> Please review this PR that enables ClassWriter to write annotations to the
> class file being dumped.
>
> The fields annotations are stored in `Annotations::_fields_annotations` which
> is of type `Array*>`. There is no class in SA that
On Thu, 13 Jul 2023 09:46:30 GMT, Viktor Klang wrote:
> I'd use a monotonic clock like `System.nanoTime()` for things like this since
> the system clock can be changed to anything at any time.
We have 100's of uses of `System.currentTimeMillis()` in our tests. I think
changing them should be h
On Thu, 6 Jul 2023 05:18:01 GMT, Jean-Philippe Bempel
wrote:
> Fix a small leak in constant pool merging during retransformation of a class.
> If this class has a catch block with `Throwable`, the class `Throwable` is
> pre-resolved in the constant pool, while all the other classes are in a
>
On Wed, 12 Jul 2023 23:21:12 GMT, Chris Plummer wrote:
>> Ashutosh Mehra has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments
>>
>> Signed-off-by: Ashutosh Mehra
>
> Marked as reviewed by cjplummer (Reviewer).
@plu
On Thu, 6 Jul 2023 05:18:01 GMT, Jean-Philippe Bempel
wrote:
> Fix a small leak in constant pool merging during retransformation of a class.
> If this class has a catch block with `Throwable`, the class `Throwable` is
> pre-resolved in the constant pool, while all the other classes are in a
>
On Wed, 12 Jul 2023 19:48:52 GMT, Ashutosh Mehra wrote:
> Please review this fix to correctly read a long value in the runtime constant
> pool. Details are mentioned in the issue [0].
> As an example, before this fix the long value generated by SA's dumpclass for
> java.lang.String.serialVersio
On Wed, 12 Jul 2023 18:48:42 GMT, Ashutosh Mehra wrote:
>> Please review this PR that enables ClassWriter to write annotations to the
>> class file being dumped.
>>
>> The fields annotations are stored in `Annotations::_fields_annotations`
>> which is of type `Array*>`. There is no class in SA
On Wed, 12 Jul 2023 15:17:10 GMT, Thomas Stuefe wrote:
>>> What would be needed to make the Annotations appear in the "printall"
>>> command? I was somehow expecting to see at least something like
>>> "Annotation@".
>>
>> I am not sure what all details `printall` is expected to emit out. L
On Thu, 13 Jul 2023 02:13:54 GMT, Chris Plummer wrote:
>> After [JDK-8308232](https://bugs.openjdk.org/browse/JDK-8308232), both the
>> test and the debuggee shared the same waittime of 5 minutes. The test would
>> wait up to 5 minutes for the expected prompt, but the debuggee would also in
>>
40 matches
Mail list logo
