On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote:
>> 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).
>>
>>
On Wed, 7 Sep 2022 20:09:05 GMT, Alex Menkov wrote:
>> The problem is RedefineClasses does not update cached_class_bytes, so
>> subsequent RetransformClasses gets obsolete class bytes (this are testcases
>> 3-6 from the new test)
>>
>> cached_class_bytes are set when an agent instruments the c
On Wed, 7 Sep 2022 21:53:06 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
>
> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList
> serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
>
> [JDK-8293516](https://bug
On Wed, 7 Sep 2022 22:03:43 GMT, Brian Burkhalter wrote:
>> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
>>
>> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList
>> serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
>>
>> [JDK-8293516](https://
On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote:
> During the discussion of
> [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was
> voiced that we should stop using INTPTR_FORMAT when printing pointers.
>
> Some background that could explain why some tend to use IN
On Wed, 7 Sep 2022 21:53:06 GMT, Daniel D. Daugherty wrote:
> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
>
> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList
> serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
>
> [JDK-8293516](https://bug
Trivial fixes to ProblemList 4 tests that fail in the upper Tiers:
[JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList
serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode
[JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList
gc/cslocker/TestCSLocker.ja
On Tue, 6 Sep 2022 19:26:09 GMT, Chris Plummer wrote:
> 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, a
On Tue, 6 Sep 2022 19:26:09 GMT, Chris Plummer wrote:
> 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, a
On Tue, 6 Sep 2022 19:26:09 GMT, Chris Plummer wrote:
> 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, a
On Sat, 3 Sep 2022 09:47:05 GMT, Serguei Spitsyn wrote:
> Also, I'm curious how did you verify that no regressions have been introduced?
Run all Redefine/Retransform Classes tests:
test/jdk/java/lang/instrument
test/hotspot/jtreg/serviceability/jvmti/RedefineClasses
test/hotspot/jtreg/vmTe
> The problem is RedefineClasses does not update cached_class_bytes, so
> subsequent RetransformClasses gets obsolete class bytes (this are testcases
> 3-6 from the new test)
>
> cached_class_bytes are set when an agent instruments the class from
> ClassFileLoadHook.
> After successful Redefine
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
On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote:
>> 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).
>>
>>
On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote:
>> 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).
>>
>>
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 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 06:35:23 GMT, Chris Plummer wrote:
>> src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java line
>> 600:
>>
>>> 598: case JDWP.Error.THREAD_NOT_ALIVE:
>>> 599: throw new IncompatibleThreadStateException(
>>> 600:
On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote:
> During the discussion of
> [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was
> voiced that we should stop using INTPTR_FORMAT when printing pointers.
>
> Some background that could explain why some tend to use IN
20 matches
Mail list logo
