On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote:
> The Loom related spec of the extension VirtualThreadMount and
> VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements
> ` ... `, so these specs have to be ignored when the
> `jvmti.html `is generated. However the `j
On Fri, 2 Sep 2022 23:28:38 GMT, Dean Long wrote:
> I suggest splitting this up into the straight-forward refactor (without the
> excluded bytes change), then adding excluded bytes as a follow-up.
Yes, that is a slight change. Splitting is not necessary for the reason you
mention because this
On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote:
> While trying to find a fix for
> [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was
> found), I made some adjustments to the error handling in
> catch_mach_exception_raise() to make it a bit easier to understand the co
On Fri, 2 Sep 2022 03:20:56 GMT, Chris Plummer wrote:
>> While dumping all registers (and doing a findpc on each), the following
>> exception occurred for r8:
>>
>>
>> r8: 0x00750e4fdffc
>> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds
>> for length 4096
>> ja
The Loom related spec of the extension VirtualThreadMount and
VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements
` ... `, so these specs have to be ignored when the `jvmti.html
`is generated. However the `jvmti.xsl` which does the XSL transformation misses
to do that whe
On Fri, 2 Sep 2022 00:04:17 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 Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote:
> While trying to find a fix for
> [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was
> found), I made some adjustments to the error handling in
> catch_mach_exception_raise() to make it a bit easier to understand the co
On Fri, 2 Sep 2022 19:37:16 GMT, Daniel D. Daugherty wrote:
> Forgot to ask: what kind of testing has been done?
I ran test/jdk/sun/tools/jhsdb about 300 times, basically enough times to at
least reproduce the SIGILL failure once. I don't seem to see the SIGTRAP
failure anymore.
ERROR: catch
On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote:
> 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
On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote:
> While trying to find a fix for
> [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was
> found), I made some adjustments to the error handling in
> catch_mach_exception_raise() to make it a bit easier to understand the co
On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote:
> While trying to find a fix for
> [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was
> found), I made some adjustments to the error handling in
> catch_mach_exception_raise() to make it a bit easier to understand the co
While trying to find a fix for
[JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found),
I made some adjustments to the error handling in catch_mach_exception_raise()
to make it a bit easier to understand the code, and to provide a more
meaningful error message when the sof
On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang wrote:
> This task convert 3 shell tests below to java version.
> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh
> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStore
On Tue, 30 Aug 2022 22:39:15 GMT, Bill Huang wrote:
>> This task convert 3 shell tests below to java version.
>> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh
>> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
>> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyS
On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote:
> 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
On Tue, 30 Aug 2022 23:29:18 GMT, Chris Plummer wrote:
> The root cause of this CR is that we are trying to access the java heap
> during the middle of a GC. This particular test is prone to that happening
> since it runs jstack 4 times on the debuggee as it starts up (the debuggee is
> jshell
On Thu, 1 Sep 2022 18:28:58 GMT, Chris Plummer wrote:
>> The root cause of this CR is that we are trying to access the java heap
>> during the middle of a GC. This particular test is prone to that happening
>> since it runs jstack 4 times on the debuggee as it starts up (the debuggee
>> is jsh
On Thu, 1 Sep 2022 19:09:25 GMT, Chris Plummer wrote:
> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which
> prints the failure message and sets the testFailed flag. At some later point
> the failure is detected and an exception is thrown. The end result is the
> excep
On Thu, 1 Sep 2022 21:11:09 GMT, Chris Plummer wrote:
>> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which
>> prints the failure message and sets the testFailed flag. At some later point
>> the failure is detected and an exception is thrown. The end result is the
>> e
On Thu, 1 Sep 2022 21:11:09 GMT, Chris Plummer wrote:
>> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which
>> prints the failure message and sets the testFailed flag. At some later point
>> the failure is detected and an exception is thrown. The end result is the
>> e
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(),
they aren't conne
On Fri, 26 Aug 2022 13:43:00 GMT, Coleen Phillimore wrote:
> Please review this simple conversion for the ProtectionDomainCacheTable from
> Old Hashtable to ResourceHashtable. There are specific tests for this table
> in test/hotspot/jtreg/runtime/Dictionary and
> serviceability/dcmd/vm/Dicti
On Fri, 2 Sep 2022 05:26:45 GMT, David Holmes wrote:
>> // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain
>> objects that are
>> // registered by DictionaryEntry::add_protection_domain() to a unique entry.
>> The entry
>> // is a WeakHandle that holds the protection dom
On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote:
>> Please review this simple conversion for the ProtectionDomainCacheTable from
>> Old Hashtable to ResourceHashtable. There are specific tests for this table
>> in test/hotspot/jtreg/runtime/Dictionary and
>> serviceability/dcmd/vm/D
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 INTPTR_FORMAT instead
of PTR_FORMAT:
Both those format specifiers re
25 matches
Mail list logo
