On Wed, 7 Sep 2022 05:55:56 GMT, Alan Bateman wrote:
> So if I read the issue correctly, the reply to the
> ThreadReference/ForceEarlyReturn command never returned THREAD_NOT_ALIVE so
> it's okay to remove the mapping to IncompatibleThreadStateException.
It was not some recent change in the de
On Wed, 7 Sep 2022 05:51:53 GMT, Serguei Spitsyn wrote:
> The JDI files `com/sun/jdi/ClassLoaderReference.java` and
> `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec
> with the extra folder name `jvmti`.
>
> The fix is to get rid unneeded part from the links:
>
> --
On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote:
> THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it
> to INVALID_THREAD before passing it on to the debug agent client (the
> debugger, usually JDI), so debug agent users (JDI) should never see it.
> Currently Thr
On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote:
> The diamond operator was introduced in Java 7. We can take advantage of this
> language feature to make code easier to read.
> Tested on Linux release x64. `make test TEST="jdk/java/lang/management
> jdk/javax/management jdk/com/sun/jmx
On Wed, 7 Sep 2022 05:51:53 GMT, Serguei Spitsyn wrote:
> The JDI files `com/sun/jdi/ClassLoaderReference.java` and
> `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec
> with the extra folder name `jvmti`.
>
> The fix is to get rid unneeded part from the links:
>
> --
On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote:
> THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it
> to INVALID_THREAD before passing it on to the debug agent client (the
> debugger, usually JDI), so debug agent users (JDI) should never see it.
> Currently Thr
On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote:
> THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it
> to INVALID_THREAD before passing it on to the debug agent client (the
> debugger, usually JDI), so debug agent users (JDI) should never see it.
> Currently Thr
The JDI files `com/sun/jdi/ClassLoaderReference.java` and
`com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec with
the extra folder name `jvmti`.
The fix is to get rid unneeded part from the links:
--- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java
+++
THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to
INVALID_THREAD before passing it on to the debug agent client (the debugger,
usually JDI), so debug agent users (JDI) should never see it. Currently
ThreadReference.forceEarlyReturn() is the only API that even bother
> Refactor code from inside of CompressedStream into its own unit.
>
> This code is likely to be used in future refactorings, such as JDK-8292818
> (replace 96-bit representation for field metadata with variable-sized
> streams).
>
> Add gtests.
John R Rose has updated the pull request increme
On Tue, 6 Sep 2022 19:28:15 GMT, Chris Plummer wrote:
> As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010),
> when a bad threadID is passed to the clhsdb "thread" command, the error
> message is incorrect:
>
> hsdb> thread 18
> Couldn't find thread thread
>
> It shou
On Tue, 6 Sep 2022 19:28:15 GMT, Chris Plummer wrote:
> As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010),
> when a bad threadID is passed to the clhsdb "thread" command, the error
> message is incorrect:
>
> hsdb> thread 18
> Couldn't find thread thread
>
> It shou
On Tue, 6 Sep 2022 19:28:15 GMT, Chris Plummer wrote:
> As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010),
> when a bad threadID is passed to the clhsdb "thread" command, the error
> message is incorrect:
>
> hsdb> thread 18
> Couldn't find thread thread
>
> It shou
As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010),
when a bad threadID is passed to the clhsdb "thread" command, the error message
is incorrect:
hsdb> thread 18
Couldn't find thread thread
It should say "thread 18", not "thread thread". The code looks like:
Each time you attach to a target JVM on Windows, thread Id's can change
(although they rarely do). For this reason you can't reliably do what this test
is doing, which is attach, run jstack to get the threadId of a thread, detach,
attach again and run the `thread` command using the threadId. It
> Refactor code from inside of CompressedStream into its own unit.
>
> This code is likely to be used in future refactorings, such as JDK-8292818
> (replace 96-bit representation for field metadata with variable-sized
> streams).
>
> Add gtests.
John R Rose has updated the pull request increme
On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote:
> The diamond operator was introduced in Java 7. We can take advantage of this
> language feature to make code easier to read.
> Tested on Linux release x64. `make test TEST="jdk/java/lang/management
> jdk/javax/management jdk/com/sun/jmx
On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote:
> The diamond operator was introduced in Java 7. We can take advantage of this
> language feature to make code easier to read.
> Tested on Linux release x64. `make test TEST="jdk/java/lang/management
> jdk/javax/management jdk/com/sun/jmx
The diamond operator was introduced in Java 7. We can take advantage of this
language feature to make code easier to read.
Tested on Linux release x64. `make test TEST="jdk/java/lang/management
jdk/javax/management jdk/com/sun/jmx jdk/sun/management"`
Test summary
==
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatibl
On Sat, 3 Sep 2022 11:05:18 GMT, Kevin Walls wrote:
>> src/hotspot/share/runtime/javaThread.cpp line 165:
>>
>>> 163: oop JavaThread::threadObj() const {
>>> 164: // Using Thread::current_or_null_safe() here risks that calling
>>> threadObj() can
>>> 165: // overwrite a native thread local,
> This is an MR which partially reverts JDK-8289091 such that
> JavaThread::threadObj() does not call Thread::current().
>
> A JVMTI operation could call threadObj() and clear the Windows GetLastError
> value.
>
> Partial, because I haven't reverted changes in JavaThread::print_on_error(),
> t
22 matches
Mail list logo
