On Thu, 2 Feb 2023 19:08:49 GMT, Alex Menkov wrote:
>> classFileParser drops stack map frames for JDK classes (when verification is
>> not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for
>> class redefinition.
>> Note that if the class is in CDS archive, t
> classFileParser drops stack map frames for JDK classes (when verification is
> not required).
> As a result JvmtiClassFileReconstituter cannot restore the attribute for
> class redefinition.
> Note that if the class is in CDS archive, the frames are restored from CDS,
> so this issue affects o
On Thu, 2 Feb 2023 00:17:58 GMT, Alex Menkov wrote:
>> classFileParser drops stack map frames for JDK classes (when verification is
>> not required).
>> As a result JvmtiClassFileReconstituter cannot restore the attribute for
>> class redefinition.
>> Note that if the class is in CDS archive, t
On Thu, 2 Feb 2023 17:32:15 GMT, Daniel D. Daugherty wrote:
> This PR does not document the type of pre-integration testing that was done
on these changes. We're seeing intermittent test failures in Mach5 Tier3 with
I ran all com/sun/jdi, nsk/jdb, nsk/jdi, and nsk/jdwp tests on all supported
ho
On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer wrote:
> jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all
> created threads. It creates them with the SUSPEND_ALL policy. This is
> unnecessary since jdb always immediately resumes all threads after doing the
> thread b
On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer wrote:
> jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all
> created threads. It creates them with the SUSPEND_ALL policy. This is
> unnecessary since jdb always immediately resumes all threads after doing the
> thread b
On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer wrote:
> This test started failing after
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the
> jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of
> SUSPEND_ALL. This sped up the handling of these eve
On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer wrote:
> This test started failing after
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the
> jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of
> SUSPEND_ALL. This sped up the handling of these eve
On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters wrote:
> Small, trivial change to resolve initialization order reordering in
> constructors, required for
> [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
>
> gcc will fail to compile a Windows JDK with the following errors, which
> c
On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters wrote:
> Small, trivial change to resolve initialization order reordering in
> constructors, required for
> [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
>
> gcc will fail to compile a Windows JDK with the following errors, which
> c
On Fri, 27 Jan 2023 05:06:25 GMT, Leonid Mesnik wrote:
> PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is
> failing" to new test and remove duplication.
>
> Test allthr002 ported as
> serviceability/jvmti/negative/GetAllThreadsNullTest/GetAllThreadsNullTest.java
This pull
On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters wrote:
> Small, trivial change to resolve initialization order reordering in
> constructors, required for
> [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
>
> gcc will fail to compile a Windows JDK with the following errors, which
> c
On Thu, 2 Feb 2023 12:12:37 GMT, Kevin Walls wrote:
> (In the description you mean it is required for JDK-8288293.)
Ah, yes that was what I meant, sorry for the oversight
kevin and aivanov: When compiling for Windows with gcc instead of Visual C++,
gcc will raise the following warnings
`m_nCou
On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters wrote:
> Small, trivial change to resolve initialization order reordering in
> constructors, required for
> [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)
Looks good to me.
David's comment sheds some light on why it's needed. I will a
On Thu, 2 Feb 2023 12:12:37 GMT, Kevin Walls wrote:
> Could we say in the bug exactly when this is an issue (maybe it's a certain
> compiler?), and include a copy of the error or warning that is seen?
Yes, I agree. The change is simple enough yet there are no details why it's
needed.
On Mon, 23 Jan 2023 14:14:50 GMT, Daniel Fuchs wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix parameters order for Util.wildmatch
>
> Hi Alexey - you have addressed most of my concerns but let me reinstate t
> Please find a patch to improve JMX Repository.query performance
>
> Using ObjectName.apply() allows significantly decrease memory usage and the
> number of GC cycles:
> Before:
>
> $ java test 100 100
> Test PASSED in 8943169791 ns.
> GC: G1 Young Generation getCollectionCount()=177 ge
On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters wrote:
> Small, trivial change to resolve initialization order reordering in
> constructors, required for
> [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)
(In the description you mean it is required for JDK-8288293.)
Could we say in th
On Wed, 1 Feb 2023 23:51:02 GMT, Chris Plummer wrote:
> This test started failing after
> [JDK-8300811](https://bugs.openjdk.org/browse/JDK-8300811), which made the
> jdb ThreadStartRequest and ThreadDeathRequest use SUSPEND_NONE instead of
> SUSPEND_ALL. This sped up the handling of these eve
19 matches
Mail list logo
