On Thu, 13 Jul 2023 05:06:44 GMT, David Holmes wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Suggestion from David. Widen synchronized block so it is not necessarry
>> for notInterrupted to be atomic.
>
> test/
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 Thu, 13 Jul 2023 01:28:57 GMT, Serguei Spitsyn wrote:
>> This is an issue with a dynamic load of a JVMTI agent into running VM.
>> The `VM_SetNotifyJvmtiEventsMode` enabling operation makes a call to the
>> function `count_transitions_and_correct_jvmti_thread_states()`. This
>> function in i
Clean backport from mainline jdk repo to jdk21 for the fix of:
[8311556](https://bugs.openjdk.org/browse/JDK-8311556): GetThreadLocalStorage
not working for vthreads mounted during JVMTI attach
Testing:
- TBD: mach5 tiers 1-5
-
Commit messages:
- Backport 11a5115caf179a1bbed5311e1
On Wed, 12 Jul 2023 15:20:35 GMT, Chen Liang wrote:
>> Daohan Qu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use Assert instead of throwing exceptions
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewrit
> 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
> 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
> some cases wait 5 minutes before generating the prompt, whic
On Wed, 12 Jul 2023 05:02:53 GMT, Serguei Spitsyn wrote:
> This is an issue with a dynamic load of a JVMTI agent into running VM.
> The `VM_SetNotifyJvmtiEventsMode` enabling operation makes a call to the
> function `count_transitions_and_correct_jvmti_thread_states()`. This function
> in its t
On Thu, 13 Jul 2023 00:48:46 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: removed unneeded @compile commands from new test
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/VThrea
> This is an issue with a dynamic load of a JVMTI agent into running VM.
> The `VM_SetNotifyJvmtiEventsMode` enabling operation makes a call to the
> function `count_transitions_and_correct_jvmti_thread_states()`. This function
> in its turn make a call to the function `correct_jvmti_thread_state
On Wed, 12 Jul 2023 08:01:55 GMT, Serguei Spitsyn wrote:
>> This is an issue with a dynamic load of a JVMTI agent into running VM.
>> The `VM_SetNotifyJvmtiEventsMode` enabling operation makes a call to the
>> function `count_transitions_and_correct_jvmti_thread_states()`. This
>> function in i
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 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:57:14 GMT, Coleen Phillimore wrote:
> It looks like javac has preresolved it for us, which you said but I didn't
> know why.
The preresolving is done by the verifier.
https://bugs.openjdk.org/browse/JDK-8308762?focusedCommentId=14584707&page=com.atlassian.jira.plugin.sy
On Tue, 11 Jul 2023 20:47:41 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
>>
Please review this fix to correctly read a long value in the runtime constant
pool. Details are mentioned in the issue [0].
Before this fix the long value generated by SA's dumpclass for
java.lang.String.serialVersionUID was:
private static final long serialVersionUID;
descriptor: J
fl
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 Tue, 11 Jul 2023 20:33:59 GMT, Chris Plummer wrote:
>> Ashutosh Mehra has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Some code motion and factoring out common code
>>
>> Signed-off-by: Ashutosh Mehra
>
> src/jdk.hotspot.agent/s
On Tue, 11 Jul 2023 20:28:29 GMT, Chris Plummer wrote:
>> I think VMObjectFactory is a better place to implement the caching behavior
>> so that all such patterns can benefit from it. I think it is better
>> addressed in another task.
>
> I think maybe you misunderstood what I meant by "cache".
> 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 can represent
> it. I have added ArrayOfU1Array to corre
On Wed, 12 Jul 2023 13:49:17 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 in `
On Tue, 11 Jul 2023 19:13:01 GMT, Ashutosh Mehra 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. Lo
On Tue, 11 Jul 2023 01:03:29 GMT, Coleen Phillimore wrote:
> ConstantPool merging is still really complicated and
> JVM_CONSTANT_Class/UnresolvedClass (and UnresolvedClassInError) may have
> changed to not track with what RedefineClasses does. If I'm reading this
> correctly, we are always cal
On Fri, 7 Jul 2023 00:46:09 GMT, David Holmes wrote:
> these comments both pertain to the problem at hand: the merge reverts the
> resolved class entry to be unresolved; unresolved entries are not considered
> matches for resolved ones, hence we grow the constant pool.
And If if I am reading t
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/753bd563ecca6b
On Tue, 11 Jul 2023 20:47:41 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, 7 Jul 2023 00:34:59 GMT, David Holmes 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 unre
On Tue, 11 Jul 2023 11:20:19 GMT, Thomas Stuefe wrote:
> In preparation for some Lilliput-related changes, I'd like to get some purely
> mechanical code moves out of the way. It would also improve separation of
> concerns and reduces include header bloat.
>
> In particular, this patch does:
>
On Wed, 12 Jul 2023 08:11:00 GMT, Roman Kennke wrote:
> Looks good to me!
Thank you @rkennke !
-
PR Comment: https://git.openjdk.org/jdk/pull/14826#issuecomment-1632130286
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 Tue, 11 Jul 2023 11:20:19 GMT, Thomas Stuefe wrote:
> In preparation for some Lilliput-related changes, I'd like to get some purely
> mechanical code moves out of the way. It would also improve separation of
> concerns and reduces include header bloat.
>
> In particular, this patch does:
>
On Wed, 12 Jul 2023 06:11:04 GMT, Leonid Mesnik wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: removed unneeded @compile commands from new test
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/VThrea
> This is an issue with a dynamic load of a JVMTI agent into running VM.
> The `VM_SetNotifyJvmtiEventsMode` enabling operation makes a call to the
> function `count_transitions_and_correct_jvmti_thread_states()`. This function
> in its turn make a call to the function `correct_jvmti_thread_state
> ### Motivation and proposal
> 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 sam
35 matches
Mail list logo
