On Thu, 4 Jan 2024 03:19:17 GMT, Denghui Dong wrote:
>> Denghui Dong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> refine description
>
> Thanks for the review.
> @D-D-H the new test is failing in our CI in tier3 on all platforms:
>
On Thu, 4 Jan 2024 01:52:44 GMT, David Holmes wrote:
>> Hi all,
>>
>> This pull request contains a backport of commit
>> [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94)
>> from the [jdk](https://github.com/openjdk/jdk/) repository.
>>
>> The commit
On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer wrote:
> Use "cause" argument when rethrowing an exception. See CR for details on how
> this helps.
>
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
>
> I'd like to push this as a trivial change.
Setting the cause is good,
On Thu, 4 Jan 2024 02:18:10 GMT, Chris Plummer wrote:
> Remove unused debugMonitorTimedWait() function.
>
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
>
> I'd like to push this as a trivial change.
Seems fine and trivial.
-
Marked as reviewed by dholmes
On Sat, 16 Dec 2023 04:36:57 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Could I have a review of this patch?
>>
>> In the current implementation, HeapDumpBeforeFullGC/AfterFullGC will
>> generate dumps for every FGC, increasing the risk of disk full.
>>
>> This patch introduces a new option
On Thu, 4 Jan 2024 03:19:17 GMT, Denghui Dong wrote:
>> Denghui Dong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> refine description
>
> Thanks for the review.
@D-D-H the new test is failing in our CI in tier3 on all platforms:
On Tue, 5 Dec 2023 16:31:24 GMT, Denghui Dong wrote:
> Hi,
>
> Could I have a review of this patch?
>
> In the current implementation, HeapDumpBeforeFullGC/AfterFullGC will generate
> dumps for every FGC, increasing the risk of disk full.
>
> This patch introduces a new option
On Sat, 16 Dec 2023 04:36:57 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Could I have a review of this patch?
>>
>> In the current implementation, HeapDumpBeforeFullGC/AfterFullGC will
>> generate dumps for every FGC, increasing the risk of disk full.
>>
>> This patch introduces a new option
On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls wrote:
> Remove the MLet feature and its tests.
>
> Some tests use MLet classes but are not testing MLets. These are updated, to
> use another test MBean or an MBean which is a URLClassLoader, e.g.
>
Use "cause" argument when rethrowing an exception. See CR for details on how
this helps.
Tested with all of tier1, and also ran tier2 and tier4 svc tests.
I'd like to push this as a trivial change.
-
Commit messages:
- Use "cause" argument when rethrowing an exception
Changes:
Remove unused debugMonitorTimedWait() function.
Tested with all of tier1, and also ran tier2 and tier4 svc tests.
I'd like to push this as a trivial change.
-
Commit messages:
- Remove unused debugMonitorTimedWait() function.
Changes: https://git.openjdk.org/jdk/pull/17260/files
On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls wrote:
> Remove the MLet feature and its tests.
>
> Some tests use MLet classes but are not testing MLets. These are updated, to
> use another test MBean or an MBean which is a URLClassLoader, e.g.
>
In threadControl.c, at build time you can decide to keep track of thread names
by compiling with "#define DEBUG_THREADNAME". If this is also a debug build,
some extra debugging functions are included in the build, including
"dumpThread(ThreadNode *node)". These are intended to be called from
On Wed, 25 Oct 2023 17:02:03 GMT, Kevin Walls wrote:
> Remove the MLet feature and its tests.
>
> Some tests use MLet classes but are not testing MLets. These are updated, to
> use another test MBean or an MBean which is a URLClassLoader, e.g.
>
> Hi all,
>
> This pull request contains a backport of commit
> [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94)
> from the [jdk](https://github.com/openjdk/jdk/) repository.
>
> The commit being backported was authored by @dholmes-ora on 3 Jan 2024 and
Hi all,
This pull request contains a backport of commit
[028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94)
from the [jdk](https://github.com/openjdk/jdk/) repository.
The commit being backported was authored by @dholmes-ora on 3 Jan 2024 and was
reviewed
On Tue, 2 Jan 2024 05:51:59 GMT, David Holmes wrote:
> Please review these missing updates to the `jcmd` manpage - see JBS issue for
> details.
>
> I also fixed the sub-command ordering in a few places and a couple of minor
> formatting fixes.
>
> Thanks to @tstuefe for collating the initial
On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt wrote:
> The libinstrument library is linked against libjava and libjvm, twice. This
> is mostly harmless but Xcode 15.x generates a warning:
>
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12
> file(s)
> ld: warning:
On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt wrote:
> The libinstrument library is linked against libjava and libjvm, twice. This
> is mostly harmless but Xcode 15.x generates a warning:
>
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12
> file(s)
> ld: warning:
On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote:
>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
>> cleanup has been proposed before (and was done in the change). But there are
>> a number of other places in the codebase where the import is done and still
On Sat, 16 Dec 2023 17:25:20 GMT, Alan Bateman wrote:
> A lot of test changes have accumulated in the loom repo, this includes both
> new tests and updates to existing tests. Some of these updates can be brought
> to the main line. This update brings over:
>
> - The existing tests for pinning
On Wed, 3 Jan 2024 13:55:24 GMT, Thomas Wuerthinger wrote:
> Are these new compiler intrinsics required or an optional performance
> optimization?
Performance. If the intrinsic isn't there then some methods executed on virtual
threads, or on a virtual thread as the target for some op, will
On Wed, 3 Jan 2024 13:55:22 GMT, Matthias Baesken wrote:
>> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
>> cleanup has been proposed before (and was done in the change). But there are
>> a number of other places in the codebase where the import is done and still
On Wed, 20 Dec 2023 10:40:23 GMT, Serguei Spitsyn wrote:
>>> You can't do this! The Java code knows nothing about JVM TI being
>>> enabled/disabled and will call this function unconditionally.
>>
>> Indeed. I wonder if anyone is testing minimal builds to catch issues like
>> this.
>
> Good
> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
> cleanup has been proposed before (and was done in the change). But there are
> a number of other places in the codebase where the import is done and still
> the unneeded fully qualified class name "java.util.Arrays"
> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
> cleanup has been proposed before (and was done in the change). But there are
> a number of other places in the codebase where the import is done and still
> the unneeded fully qualified class name "java.util.Arrays"
On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt wrote:
> The libinstrument library is linked against libjava and libjvm, twice. This
> is mostly harmless but Xcode 15.x generates a warning:
>
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12
> file(s)
> ld: warning:
On Wed, 3 Jan 2024 11:41:20 GMT, Matthias Baesken wrote:
> In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
> cleanup has been proposed before (and was done in the change). But there are
> a number of other places in the codebase where the import is done and still
>
On Wed, 3 Jan 2024 11:53:43 GMT, Alan Bateman wrote:
> It's been bumped to 1.5g in the loom repo for some time.
Ah, I misread that change previously as reducing it from `1g` to `150m`, while
infact this change is increasing it to `1500m`. Given your reference to
JDK-8303635, the change looks
On Wed, 3 Jan 2024 11:53:24 GMT, Jaikiran Pai wrote:
> Just one question - doesn't the use of a new native code in the test library
> (the `libVThreadPinner.c`) require any build changes (I'm not too familiar
> with that part)?
Magnus did some work in the make files some time ago to build
On Wed, 3 Jan 2024 11:39:01 GMT, Jaikiran Pai wrote:
> Are these heap sizing changes to reduce the resource usage of this test or is
> it to try and trigger any potential issue that this test verifies?
The heap usage for this one can vary quite a bit, some of the lower
optimization modes lead
On Tue, 2 Jan 2024 15:22:05 GMT, Alan Bateman wrote:
>> A lot of test changes have accumulated in the loom repo, this includes both
>> new tests and updates to existing tests. Some of these updates can be
>> brought to the main line. This update brings over:
>>
>> - The existing tests for
In [JDK-8322772](https://bugs.openjdk.org/browse/JDK-8322772) one similar
cleanup has been proposed before (and was done in the change). But there are a
number of other places in the codebase where the import is done and still the
unneeded fully qualified class name "java.util.Arrays" is used
On Tue, 2 Jan 2024 15:22:05 GMT, Alan Bateman wrote:
>> A lot of test changes have accumulated in the loom repo, this includes both
>> new tests and updates to existing tests. Some of these updates can be
>> brought to the main line. This update brings over:
>>
>> - The existing tests for
On Mon, 11 Dec 2023 09:15:50 GMT, Stefan Karlsson wrote:
> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename
> createJavaProcessBuilder' changed the name of the ProcessTools helper
> functions used to create `ProcessBuilder`s used to spawn new java test
> processes.
>
> We
On Tue, 2 Jan 2024 21:44:04 GMT, Mikael Vidstedt wrote:
> The libinstrument library is linked against libjava and libjvm, twice. This
> is mostly harmless but Xcode 15.x generates a warning:
>
> Creating support/modules_libs/java.instrument/libinstrument.dylib from 12
> file(s)
> ld: warning:
36 matches
Mail list logo
